私はドッカーコンテナがインターネットに接続できず、特にDNS名を解決できなかった理由を理解しようとして約1時間かかりました。これで解決策が見つかりましたが、まだ理解していません。
症状は、Wiresharkによると、パケットは仮想ドッカーネットワークを介して送信されますが、IPv4転送が有効になっても実際のネットワークカードを介して送信されないことです。iptables
パケットカウンタによると、テーブルチェーンルールにはMASQUERADE
記録されますが、テーブルチェーンには記録されません。POSTROUTING
nat
FORWARD
filter
これには、次のネットワークデバイスが含まれます。
- ネットワーク0192.168.1.1のDSLルーターの背後にあるIP 192.168.1.5の物理LANデバイス。
- 火1私のオフィスネットワークへのVPNリンクです
- ドッカー0ドッカーによって自動的に設定される仮想ブリッジデバイスです。 Dockerコンテナは172.17.0.0/16ネットワークを使用し、ブリッジは172.17.42.1にあります。
鍵はVPNです。オフィスにいるときは、DSLルーターに設定されているDynDNSレコードを介してコンピューターに接続できるようにしたいです。したがって、私のオフィスからマイコンピュータに送信されるパケットは、VPNを通過せずにルータのNATを通過します。これは、接続を確立するには、応答パケットがVPNを通過せず、逆方向パスに従う必要があることを意味します。これを達成するために、LANから発信するパケットのための特別なルーティングテーブルを確立した。
# ip rule list
0: from all lookup local
50: from all to 127.0.0.0/8 lookup main
51: from all to 192.168.1.0/24 lookup main
100: from 192.168.1.0/24 lookup net0
32766: from all lookup main
32767: from all lookup default
# ip route list table net0
default via 192.168.1.1 dev net0
192.168.1.0/24 dev net0 scope link
# ip route list table main
default via 192.168.1.1 dev net0 metric 3
10.0.0.0/8 dev tun1 scope link
127.0.0.0/8 dev lo scope host
127.0.0.0/8 via 127.0.0.1 dev lo
<VPN gateway> via 192.168.1.1 dev net0 src 192.168.1.5
<VPN network> dev tun1 scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.42.1
192.168.1.0/24 dev net0 proto kernel scope link src 192.168.1.5 metric 3
main
結局、私はドッカーネットワークにパケットテーブルを使用する別のルールを追加するだけで、これをうまく実行するのに十分であることがわかりました。しかし、なぜ?特別なルーティングテーブルが私のルータから来る応答パケットにどのような影響を与えることができるかを確認できます。しかし、なぜこれが出てくるパケットに影響を与え、完全に消えるのでしょうか?新しい仮想ネットワークを設定するたびにルールを追加する必要がないように、すべての応答パケットが応答パケットが着信と同じ方法でルーティングされるようにするという事実を表すより柔軟な方法はありますか?
答え1
VPNリンクが迂回されないようにして問題の根本原因を解決したくないですか?それでは、VPNに接続するときに使用する別のDNSエントリセットを作成するのはどうでしょうか? 192.168と入力してください。そして172.17。パブリック DNS の A レコードにあるので、オフィス DNS サーバーで確認を続けることができます。