
ipv6를 통해 VPN(openvpn)의 장치와 통신해야 하는 도커 컨테이너가 있는 설정이 있습니다. 이는 docker 네트워크와 호스트의 tap0 인터페이스 사이에 브리지를 구성하여 수행됩니다.
최종 장치는 메시지를 도커 컨테이너에 푸시하고 승인 메시지를 다시 받을 것으로 예상합니다. 그러나 컨테이너와 호스트는 서브넷에 있고 bbbb::/64
장치는 abcd::/64
(설명을 위해) 서브넷에 있는 서로 다른 서브넷에 있습니다. bbbb::abcd:2
한 서브넷에서 다른 서브넷으로 트래픽을 라우팅 하는 게이트웨이가 있으며 Docker 호스트에는 이를 위한 게이트웨이 구성이 있습니다.
확실하게:
bbbb::4001 <--> bbbb::2105 <--> bbbb::abcd:2 <--> abcd::/64
bbbb::4001
컨테이너의 주소는 어디에 있습니까? bbbb::2105
호스트의 주소입니다. bbbb::abcd2
게이트웨이 장치의 주소입니다. abcd::/64
최종 장치가 있는 서브넷입니다.
tshark
호스트와 게이트웨이를 사용하여 다음을 관찰합니다.
- 호스트는 abcd 서브넷의 최종 장치와 직접 통신할 수 있습니다(traraceroute로 확인하면 호스트와 게이트웨이의 패킷을 볼 수 있습니다).
- 도커 컨테이너는 게이트웨이와 통신할 수 있습니다(ping으로 확인하면 호스트와 게이트웨이의 패킷을 볼 수 있음).
- 도커 컨테이너할 수 없었다abcd 서브넷의 최종 장치와 직접 통신합니다. 호스트 통신에서 본 것과 동일한 방식으로 호스트에서 패킷을 볼 수 있지만 게이트웨이에 도착하는 것은 아무것도 볼 수 없습니다.
전달된 패킷을 허용하도록 규칙을 수정하려고 시도했지만 (예: 체인 iptables
의 기본 정책을 로 설정 ) 소용이 없었습니다.FORWARD
ACCEPT
이 문제를 어디에서 찾아야 할지 불분명합니다. 왜냐하면 해당 컨테이너가 위치하지 않는 서브넷으로 향하는 도커 컨테이너의 패킷이 삭제되는 것 같기 때문입니다.어딘가에호스트에서 또는 잘못된 장소로 전송될 수도 있지만 호스트 br0
인터페이스에서는 볼 수 있지만 게이트웨이에는 도착하지 않습니다. 도커 컨테이너가 동일한 서브넷에 있는 항목과 통신하려고 하면 작동합니다.
이것을 찾으려면 어디서부터 시작해야 합니까?
답변1
문제는 도커의 네트워킹과 관련이 있었습니다. VPN에 연결하기 위해 네트워크 브리지를 사용하도록 도커 네트워크 설정이 있었습니다. 해당 브리지는 /etc/network/interfaces.d/br0.cfg
게이트웨이 주소로 (을 통해) 설정되었으며 bbbb::2105
브리지 인터페이스 이후에 도커 네트워크가 생성되었습니다. docker 네트워크가 생성될 때 게이트웨이 주소가 지정되지 않았으며 docker는 기본적으로 bbbb::1
게이트웨이 주소를 사용하도록 설정되어 강제로 br0
사용되었습니다. 해당 주소는 VPN 서버와 동일한 주소입니다. 그 결과 패킷은 실제로 호스트에서 삭제되지 않고 대신 VPN 서버의 tap
인터페이스로 전달되었으며 VPN 서버에는 해당 패킷으로 무엇을 해야할지 알 수 있도록 라우팅 테이블이 설정되어 있지 않았습니다. VPN 서버에 도달하면 블랙홀이 발생합니다.
tap
이는 tshark를 사용하여 VPN 서버의 인터페이스는 물론 tap
게이트웨이 및 Docker 호스트 시스템의 인터페이스를 모니터링함으로써 명확해졌습니다 . 그런 다음 도커 컨테이너 내부에서 최종 장치에 대해 ping을 시도했고 도커 호스트와 VPN 서버에서는 패킷이 확인되었지만 게이트웨이에서는 확인되지 않았습니다. 도커 호스트에서 동일한 작업을 시도한 경우 도커 호스트와 게이트웨이에서는 패킷이 보였지만 VPN 서버에서는 보이지 않았습니다. 따라서 도커 컨테이너가 호스트 네트워킹 인터페이스가 아닌 VPN 서버로 트래픽을 보내도록 구성되었음을 보여줍니다. .
--gateway
Docker 네트워크 생성에 옵션을 도입하여 문제가 해결되었습니다 .
이에 대해 해결되지 않은 부분은왜설정이 2016년부터 작동했고 2022년 6월 어느 날 무작위로 작동을 멈췄다는 점을 고려하면 갑자기 이런 식으로 동작하기 시작했습니다.