Byłem w stanie skonfigurować sieciową przestrzeń nazw, założyć tunel z openvpn i uruchomić aplikację, która korzysta z tego tunelu w przestrzeni nazw. Do tej pory było dobrze, ale do tej aplikacji można uzyskać dostęp za pośrednictwem interfejsu sieciowego i nie mam pojęcia, jak kierować żądania do interfejsu internetowego w mojej sieci LAN.
Postępowałem zgodnie z instrukcjami z @schnouki wyjaśniającymi, jak skonfigurować sieć nazw i uruchomić w niej OpenVPN
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
Następnie mogę sprawdzić mój zewnętrzny adres IP i uzyskać różne wyniki wewnątrz i na zewnątrz przestrzeni nazw, zgodnie z przeznaczeniem:
curl -s ipv4.icanhazip.com
<my-isp-ip>
ip netns exec myvpn curl -s ipv4.icanhazip.com
<my-vpn-ip>
Aplikacja została uruchomiona, używam potopu w tym przykładzie. Wypróbowałem kilka aplikacji z interfejsem internetowym, aby upewnić się, że nie jest to problem specyficzny dla potopu.
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
Jestem w stanie uzyskać dostęp do interfejsu sieciowego na porcie 8112 z przestrzeni nazw i z zewnątrz, jeśli podam ip veth vpn1.
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
Ale chcę przekierować port 8112 z mojego serwera do aplikacji w przestrzeni nazw. Celem jest otwarcie przeglądarki na komputerze w mojej sieci LAN i uzyskanie interfejsu sieciowego z adresem http: // my-server-ip: 8112 (my-server-ip jest statycznym ip serwera, który utworzył instancję interfejsu sieciowego)
EDYCJA: Usunąłem moje próby tworzenia reguł iptables. To, co próbuję zrobić, zostało wyjaśnione powyżej, a następujące polecenia powinny wypisać HTTP 200:
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
Wypróbowałem reguły DNAT i SNAT i rzuciłem MASQUERADE na dobrą miarę, ale ponieważ nie wiem, co robię, moje próby są daremne. Być może ktoś może mi pomóc zmontować ten konstrukt.
EDYCJA: Wyjście tcpdump z tcpdump -nn -q tcp port 8112. Nic dziwnego, że pierwsze polecenie zwraca HTTP 200, a drugie polecenie kończy się odrzuconym połączeniem.
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
EDYCJA: Sam @schnouki wskazał mi artykuł na temat administracji Debiana, wyjaśniający ogólne proxy TCP iptables . W przypadku danego problemu ich skrypt wyglądałby następująco:
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
Niestety ruch między interfejsami veth został przejęty i nic więcej się nie wydarzyło. Jednak @schnouki również zasugerowało użycie socatjako proxy TCP i działa to doskonale.
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
Muszę jeszcze zrozumieć dziwne tasowanie portów podczas ruchu przez interfejsy veth, ale mój problem został rozwiązany.
vethurządzeniami (uważam to za bardzo interesujące ... ;-)). Czytcpdumpsprawdziłeś, jak daleko docierają pakiety przychodzące? Jeślitcpdump -i veth0nic nie pokazuje,tcpdumo -i lomoże być konieczne.