ネットワーク名前空間を設定し、openvpnでトンネルを確立し、名前空間内でこのトンネルを使用するアプリケーションを起動することができました。これまでのところは良いですが、このアプリケーションはWebインターフェースを介してアクセスでき、LAN内のWebインターフェースにリクエストをルーティングする方法がわかりません。
@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>
アプリケーションが開始されました。この例では大洪水を使用しています。Webインターフェイスを備えたいくつかのアプリケーションを試してみて、それが特定の問題ではないことを確認しました。
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のipを指定すると、ネームスペース内および外部からポート8112のWebインターフェイスにアクセスできます。
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をサーバーからネームスペースのアプリケーションにリダイレクトしたいのです。目標は、LAN内のコンピューターでブラウザーを開き、http:// my-server-ip:8112で Webインターフェースを取得することです(my-server-ipは、ネットワークインターフェースをインスタンス化したサーバーの静的IPです)
編集: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のルールを試し、適切な手段でマスカレードを投入しましたが、自分が何をしているかわからないので、私の試みは無駄です。おそらく誰かが私がこの構成をまとめるのを手伝うことができるでしょう。
編集:のtcpdump出力tcpdump -nn -q tcp port 8112
。当然のことながら、最初のコマンドはHTTP 200を返し、2番目のコマンドは拒否された接続で終了します。
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
編集:@schnouki自身が、一般的なiptables TCPプロキシについて説明しているDebian管理記事を指摘してくれました。当面の問題に適用すると、スクリプトは次のようになります。
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
、必要な場合があります。