Мені вдалося налаштувати мережевий простір імен, встановити тунель з openvpn та запустити програму, яка використовує цей тунель всередині простору імен. Поки що добре, але доступ до цієї програми можна отримати через веб-інтерфейс, і я не можу зрозуміти, як направляти запити до веб-інтерфейсу всередині моєї локальної мережі.
Я дотримувався довідника @schnouki, в якому пояснював, як налаштувати мережевий простір імен та запустити 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
Після цього я можу перевірити свій зовнішній ip та отримати різні результати всередині та зовні простору імен, як задумано:
curl -s ipv4.icanhazip.com
<my-isp-ip>
ip netns exec myvpn curl -s ipv4.icanhazip.com
<my-vpn-ip>
Додаток запущено, я використовую deluge для цього прикладу. Я спробував кілька додатків з веб-інтерфейсом, щоб переконатися, що це не проблема специфічного потоку.
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
Я можу отримати доступ до веб-інтерфейсу порту 8112 як з простору імен, так і ззовні, якщо я вкажу 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
Але я хочу перенаправити порт 8112 зі свого сервера на додаток у просторі імен. Мета - відкрити браузер на комп’ютері всередині моєї локальної мережі та отримати веб-інтерфейс з http: // my-server-ip: 8112 (my-server-ip є статичним ip сервера, який інстанціював мережевий інтерфейс)
EDIT: Я видалив свої спроби створити правила iptables. Що я намагаюся зробити, пояснено вище, і наступні команди повинні вивести 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
Я спробував правила DNAT і SNAT і на добру міру кинув МАСКВЕРАДУ, але оскільки я не знаю, що роблю, мої спроби марні. Можливо, хтось може допомогти мені зібрати цю конструкцію.
EDIT: вихід tcpdump tcpdump -nn -q tcp port 8112. Не дивно, що перша команда повертає HTTP 200, а друга команда припиняється з відмовленим з'єднанням.
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 вказав на статтю в адміністрації Debian, що пояснює загальний проксі-сервер iptables TCP . Як застосовано до проблеми, їх сценарій виглядатиме так:
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
На жаль, трафік між veth-інтерфейсами захоплений, і більше нічого не сталося. Однак @schnouki також запропонував використовувати socatяк проксі-сервер TCP, і це працює чудово.
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
Я ще не зрозумів, як дивно пересувається порт, поки трафік проходить через інтерфейси veth, але зараз моя проблема вирішена.
vethпристроями (вважаю це дуже цікавим, хоча ... ;-)). Ви використовувалиtcpdumpдля перевірки, наскільки далеко потрапляють вхідні пакети? Якщоtcpdump -i veth0нічого не показує, тоtcpdumo -i loможе знадобитися.