2番目のルーティングテーブルのため、パケットは転送されませんでした。

私はドッカーコンテナがインターネットに接続できず、特にDNS名を解決できなかった理由を理解しようとして約1時間かかりました。これで解決策が見つかりましたが、まだ理解していません。

症状は、Wiresharkによると、パケットは仮想ドッカーネットワークを介して送信されますが、IPv4転送が有効になっても実際のネットワークカードを介して送信されないことです。iptablesパケットカウンタによると、テーブルチェーンルールにはMASQUERADE記録されますが、テーブルチェーンには記録されません。POSTROUTINGnatFORWARDfilter

これには、次のネットワークデバイスが含まれます。

• ネットワーク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結局、私はドッカーネットワークにパケットテーブルを使用する別のルールを追加するだけで、これをうまく実行するのに十分であることがわかりました。しかし、なぜ？特別なルーティングテーブルが私のルータから来る応答パケットにどのような影響を与えることができるかを確認できます。しかし、なぜこれが出てくるパケットに影響を与え、完全に消えるのでしょうか？新しい仮想ネットワークを設定するたびにルールを追加する必要がないように、すべての応答パケットが応答パケットが着信と同じ方法でルーティングされるようにするという事実を表すより柔軟な方法はありますか？