두 번째 라우팅 테이블로 인해 패킷이 전달되지 않았습니다.

내 도커 컨테이너가 인터넷에 연결할 수 없고 특히 DNS 이름을 확인할 수 없는 이유를 이해하려고 약 한 시간을 보냈습니다. 이제 해결책을 찾았지만 여전히 이해가 되지 않습니다.

증상은 Wireshark에 따르면 패킷이 가상 도커 네트워크를 통해 전송되지만 IPv4 전달이 활성화되어 있어도 실제 네트워크 카드를 통해서는 전송되지 않는다는 것입니다. iptables패킷 카운터 에 따르면 테이블 체인 MASQUERADE규칙에는 기록되지만 테이블 체인에는 기록되지 않습니다.POSTROUTINGnatFORWARDfilter

여기에는 다음 네트워크 장치가 관련됩니다.

• 네트워크 0192.168.1.1의 DSL 라우터 뒤에 있는 IP 192.168.1.5의 물리적 LAN 장치입니다.
• 화 1내 사무실 네트워크에 대한 VPN 링크입니다
• 도커 0도커에 의해 자동으로 설정되는 가상 브리지 장치입니다. 도커 컨테이너는 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결국 나는 도커 네트워크에 패킷 테이블을 사용하는 또 다른 규칙을 추가하는 것만으로도 이 작업을 성공적으로 수행하기에 충분하다는 것을 발견했습니다 . 그런데 왜? 특수 라우팅 테이블이 내 라우터에서 오는 응답 패킷에 어떤 영향을 미칠 수 있는지 확인할 수 있습니다. 그런데 왜 이것이 나가는 패킷에 영향을 주어 완전히 사라지게 만드는 걸까요? 새로운 가상 네트워크를 설정할 때마다 규칙을 추가할 필요가 없도록 모든 응답 패킷이 응답 패킷이 들어오는 것과 동일한 방식으로 라우팅되기를 원한다는 사실을 표현하는 보다 유연한 방법이 있습니까?