Bir ağ ad alanı oluşturabiliyor, openvpn ile bir tünel kurabiliyor ve bu tüneli ad alanı içinde kullanan bir uygulama başlatabiliyordum. Şimdiye kadar iyi, ancak bu uygulamaya bir web arayüzü üzerinden erişilebilir ve istekleri LAN'ımdaki web arayüzüne nasıl yönlendireceğimizi anlayamıyorum.
@Schnouki'den bir ağ ad alanının nasıl kurulacağını ve içinde OpenVPN'in nasıl çalıştırılacağını açıklayan bir rehber izledim
ip netns add myvpn
ip netns exec myvpn ip addr add 127.0.0.1/8 dev lo
ip netns exec myvpn ip link set lo up
ip link add vpn0 type veth peer name vpn1
ip link set vpn0 up
ip link set vpn1 netns myvpn up
ip addr add 10.200.200.1/24 dev vpn0
ip netns exec myvpn ip addr add 10.200.200.2/24 dev vpn1
ip netns exec myvpn ip route add default via 10.200.200.1 dev vpn1
iptables -A INPUT \! -i vpn0 -s 10.200.200.0/24 -j DROP
iptables -t nat -A POSTROUTING -s 10.200.200.0/24 -o en+ -j MASQUERADE
sysctl -q net.ipv4.ip_forward=1
mkdir -p /etc/netns/myvpn
echo 'nameserver 8.8.8.8' > /etc/netns/myvpn/resolv.conf
Bundan sonra, harici ipimi kontrol edebilir ve ad alanının içinde ve dışında farklı sonuçlar elde edebilirim, tıpkı amaçlandığı gibi:
curl -s ipv4.icanhazip.com
<my-isp-ip>
ip netns exec myvpn curl -s ipv4.icanhazip.com
<my-vpn-ip>
Uygulama başlatıldı, bu örnek için tufan kullanıyorum. Tufanla ilgili bir sorun olmadığından emin olmak için bir web arayüzü ile birkaç uygulama denedim.
ip netns exec myvpn sudo -u <my-user> /usr/bin/deluged
ip netns exec myvpn sudo -u <my-user> /usr/bin/deluge-web -f
ps $(ip netns pids myvpn)
PID TTY STAT TIME COMMAND
1468 ? Ss 0:13 openvpn --config /etc/openvpn/myvpn/myvpn.conf
9302 ? Sl 10:10 /usr/bin/python /usr/bin/deluged
9707 ? S 0:37 /usr/bin/python /usr/bin/deluge-web -f
Veth vpn1'in ipini belirtirsem, 8112 numaralı bağlantı noktasındaki web arabirimine ad alanından ve dışarıdan erişebiliyorum.
ip netns exec myvpn curl -Is localhost:8112 | head -1
HTTP/1.1 200 OK
ip netns exec myvpn curl -Is 10.200.200.2:8112 | head -1
HTTP/1.1 200 OK
curl -Is 10.200.200.2:8112 | head -1
HTTP/1.1 200 OK
Ancak, 8112 numaralı bağlantı noktasını sunucumdan ad alanındaki uygulamaya yeniden yönlendirmek istiyorum. Amaç, LAN'ımın içindeki bir bilgisayarda bir tarayıcı açmak ve web arayüzünü http: // sunucum-ip: 8112 (ağ sunucumun somutlaştırılmış sunucunun statik ipi olmak) ile elde etmektir.
EDIT: iptables kuralları oluşturma girişimlerimi kaldırdım. Ne yapmaya çalışıyorum yukarıda açıklanmıştır ve aşağıdaki komutlar bir HTTP 200 çıktısı vermelidir:
curl -I localhost:8112
curl: (7) Failed to connect to localhost port 8112: Connection refused
curl -I <my-server-ip>:8112
curl: (7) Failed to connect to <my-server-ip> port 8112: Connection refused
DNAT ve SNAT kurallarını denedim ve bir MASQUERADE'e iyi bir ölçü için attım, ama ne yaptığımı bilmediğim için girişimlerim boşuna. Belki birisi bu yapıyı bir araya getirmeme yardımcı olabilir.
EDIT: tcpdump çıktı tcpdump -nn -q tcp port 8112. Şaşırtıcı olmayan bir şekilde, ilk komut bir HTTP 200 döndürür ve ikinci komut reddedilen bir bağlantıyla sona erer.
curl -Is 10.200.200.2:8112 | head -1
listening on vpn0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 10.200.200.1.36208 > 10.200.200.2.8112: tcp 82
IP 10.200.200.2.8112 > 10.200.200.1.36208: tcp 145
curl -Is <my-server-ip>:8112 | head -1
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
IP <my-server-ip>.58228 > <my-server-ip>.8112: tcp 0
IP <my-server-ip>.8112 > <my-server-ip>.58228: tcp 0
EDIT: @schnouki kendisi genel bir iptables TCP proxy açıklayan bir Debian Yönetimi makalesine işaret etti . Eldeki probleme uygulandığında, senaryoları şöyle görünecektir:
YourIP=<my-server-ip>
YourPort=8112
TargetIP=10.200.200.2
TargetPort=8112
iptables -t nat -A PREROUTING --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
iptables -t nat -A POSTROUTING -p tcp --dst $TargetIP --dport $TargetPort -j SNAT \
--to-source $YourIP
iptables -t nat -A OUTPUT --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
Maalesef, veth arayüzleri arasındaki trafik ele geçirildi ve başka bir şey olmadı. Bununla birlikte, @schnouki ayrıca socatbir TCP proxy olarak kullanılmasını önerdi ve bu mükemmel çalışıyor.
curl -Is <my-server-ip>:8112 | head -1
IP 10.200.200.1.43384 > 10.200.200.2.8112: tcp 913
IP 10.200.200.2.8112 > 10.200.200.1.43384: tcp 1495
Trafik veth arabirimleri arasında geçiş yaparken garip bağlantı noktası karıştırmayı henüz anlamadım, ama şimdi sorunum çözüldü.
vethCihazlarla hiç tecrübem yok (bunu çok ilginç buluyorum, ama ... ;-)).tcpdumpGelen paketlerin ne kadar uzağa gittiğini kontrol etmek için kullandınız mı ? Eğertcpdump -i veth0bir şey görünmüyor sonratcpdumo -i logerekli olabilir.