Windows 컨테이너와 VPN: 로컬 네트워킹이 끊기는 이유
Windows 컨테이너는 호스트의 라우팅 테이블을 빌려 쓰므로 로컬 서브넷을 막는 VPN은 컨테이너 프리픽스까지 함께 가져갑니다. Linux 모드는 다른 경로를 택합니다.
노트북 한 대에서 VPN 클라이언트 하나를 연결하면 Linux 컨테이너는 서로 계속 통신하지만 Windows 컨테이너는 멈춥니다. 변수는 이미지가 아니라 패킷이 호스트로 들어가는 경로입니다. 기본 네트워크의 Windows 컨테이너는 호스트의 라우팅 테이블과 변환을 빌려 쓰므로, 호스트 라우팅을 바꾸는 정책은 컨테이너에도 적용됩니다. 무엇이든 다시 설치하기 전에 경로 조회로 이를 확인하십시오.
Windows 컨테이너의 패킷이 호스트로 들어가는 지점
기본 nat 네트워크의 컨테이너는 Host Networking Service 프리픽스에서 주소를 받으며 보통 172.16.0.0/12 내부 어딘가에 있고, 가상 어댑터를 통해 호스트에 도달합니다. 호스트가 그 프리픽스의 경로를 소유하고 현재 활성인 어댑터 쪽으로 트래픽을 변환합니다. 그 경로 중간에 별도의 가상 머신은 없습니다.
이 설계가 고장을 기계적으로 만듭니다. 컨테이너가 패킷을 보내면 호스트는 컨테이너 프리픽스에 대해 경로 조회를 수행합니다. 이기는 경로가 패킷의 목적지가 되며, 컨테이너는 여기에 관여하지 않습니다.
VPN 클라이언트가 그 경로에서 바꾸는 것
기업용 클라이언트는 대개 광범위한 경로 집합과, 터널이 활성인 동안 로컬 서브넷 접근을 거부하는 필터를 설치합니다. 의도는 방어적입니다. 침해된 로컬 네트워크가 보호된 머신에 도달해서는 안 됩니다. 부작용은 호스트에서 컨테이너 프리픽스로 가는 경로가 더 이상 로컬 NAT 네트워크가 아니라는 점입니다.
대신 조회가 터널과 일치하고 패킷은 그 컨테이너 주소를 들어본 적 없는 게이트웨이로 전달됩니다. Ping이 실패하고 애플리케이션은 시간 초과되며 VPN 아이콘이 빛나는 동안 컨테이너는 고장 난 것처럼 보입니다. 연결된 상태에서 호스트 테이블을 보면 경쟁 경로가 보입니다.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Linux 컨테이너가 다르게 동작하는 이유
Linux 엔진은 컨테이너를 경량 가상 머신 안에서 실행하며, 그 머신에서 나가는 연결은 컨테이너를 대신해 호스트 측 프록시가 엽니다. 소켓을 여는 주체가 호스트이므로 컨테이너 프리픽스에 관한 VPN 규칙이 같은 방식으로 적용되지 않고, 워크로드는 계속 네트워크에 도달합니다.
이 차이는 Linux 레시피가 그대로 옮겨지지 않는 이유도 설명합니다. 자체 터널이 필요한 Linux 컨테이너에는 TUN 장치와 NET_ADMIN 권한이 주어집니다. Windows 컨테이너는 인터페이스를 장치로 노출하지 않으므로 그 패턴은 그쪽에 대응물이 없습니다.
경로를 증명한 다음 설계를 고르십시오
증거는 컨테이너가 아니라 호스트에서 수집하십시오. 조회를 수행하는 쪽이 호스트입니다:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"VPN이 연결되기 전에 한 번, 연결된 뒤에 한 번 경로 출력을 실행하십시오. 두 번째 출력에서 컨테이너 프리픽스가 터널 어댑터를 가리키면 진단은 끝난 것이며 컨테이너를 다시 시작해도 도움이 되지 않습니다.
첫 번째 선택지는 정책 결정입니다. 이 장치에 로컬 LAN 접근을 허용할 수 있는지 네트워크 소유자에게 물으십시오. 여러 기업용 클라이언트가 이를 설정으로 제공하지만, 이는 의도적으로 그은 경계를 약화합니다. 소유자와 검토 날짜가 있는 문서화된 예외로 요청하십시오. 아무도 다시 보지 않는 장치별 토글은 방어적 정책이 조용히 사라지는 방식입니다.
정책이 유지되어야 하는 곳에서는 경로와 싸우지 말고 워크로드를 옮기십시오. 명시적 서브넷과 게이트웨이를 갖춘 투명 네트워크는 컨테이너를 로컬 링크에 두고, Linux 워크로드는 가상 머신 프록시 뒤에서 실행되며, 자체 클라이언트를 가진 별도의 가상 머신 은 자체 정책을 유지합니다. 하나를 의도적으로 골라 컨테이너 내부에서 시험하십시오. 사용자의 요청이 바로 그곳에서 시작되기 때문입니다.