컨테이너 HTTPS가 기업 VPN에서 멈춘다? DTLS 구간을 시험하라

기업 VPN 뒤의 컨테이너 안에서는 DNS가 풀리고 로그인 페이지가 열리고 상태 엔드포인트가 응답한 다음, HTTPS 요청이 시간 초과까지 멈춘다. 이미지를 다시 빌드하고 프록시 변수를 바꿔도 달라지는 것이 없는 이유는, 고장 난 부분이 이미지 안에 없기 때문이다. 클라이언트는 한 전송로에서 인증하고 대용량 데이터는 다른 전송로로 옮기는데, 깨진 것은 뒤쪽 하나뿐이다.

두 전송로, 하나의 혼란스러운 증상

TLS 기반 기업 클라이언트는 보통 평범한 TLS 연결로 인증한 뒤 세션을 위해 UDP 기반의 두 번째 데이터 채널을 협상한다. 그 두 번째 구간이 동작하면 처리량과 지연이 나아진다. 그것이 걸러지거나 경로에 들어가지 못하면 대용량 전송 직전까지는 모두 성공하고 전송 자체가 멈추는데, 이것이 바로 위의 패턴이다.

컨테이너는 그 협상을 바꾸지 않는다. 바뀌는 것은 바깥 패킷이 지나는 경로다. 호스트가 컨테이너 흐름을 변환하므로 UDP 데이터그램은 클라이언트의 로컬 소켓과 다른 출발 포트로 나가고, 확립된 TCP 흐름보다 훨씬 짧은 타이머로 만료되는 변환 항목을 거쳐 돌아온다. 호스트에서는 터널이 되는데 컨테이너에서 실패한다면 애플리케이션을 탓하기 전에 그 두 흐름을 비교하라. 그 비교가 어떤 이미지 재빌드보다 많은 것을 가른다.

직관이 아니라 실험으로 결정하라

가장 값싼 실험은 UDP 데이터 채널을 끄고 요청을 되풀이하는 것이다. 데스크톱 래퍼 대신 명령줄 클라이언트를 써서 플래그가 실제로 적용되게 하라: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. 멈추던 요청이 이제 끝난다면 DTLS 구간이 문제였고 나머지는 잡음이었다.

같은 컨테이너에서 양방향으로 결과를 확인하라. 플래그를 준 대용량 요청 하나와 주지 않은 요청 하나면 된다. 플래그를 따라가는 동작 변화는 증거이고, 결국 열린 페이지는 증거가 아니다.

플래그가 고친다면 이유를 정하라

같은 증상을 만드는 조건은 셋이고 대응도 각각 다르다. 경로가 UDP를 완전히 걸러낼 수 있고, 그러면 그 네트워크에서는 플래그가 옳은 영구 답이 된다. 경로가 UDP는 허용하되 큰 데이터그램을 버릴 수 있고, 이는 필터링이 아니라 MTU를 가리킨다. 또는 경로의 손실이 커서 UDP 구간이 TCP보다 못할 수 있는데, 이는 도달 가능성의 문제가 아니라 용량의 결정이다.

우회책을 문서화하기 전에 이들을 구분하라. 필터링은 어떤 패킷 크기에서도 유지되고, MTU 문제는 임계값 위에서만 나타나며, 손실은 깔끔한 멈춤이 아니라 재전송과 변동하는 지연으로 드러난다. 각 시험은 클라이언트 설정을 바꾸지 않고 원인을 좁힌다.

우회책을 남기기 전에 패킷 크기를 확인하라

원인이 크기라면 터널 인터페이스는 경로가 나를 수 없는 패킷을 받아들이고, 페이로드가 커지는 순간 어느 전송로에서든 문제가 돌아온다. 인터페이스를 비교하라. 호스트에서 ip link show tun0, 다음으로 네트워크 옵션에 기록된 MTU를 읽으려면 docker network inspect bridge. 적게 나르는 터널 아래에서 컨테이너 브리지가 아직 1500바이트에 있는 것이 흔한 발견이다.

터널 안에서 단편화 금지 시험으로 알려진 좋은 크기에서 위로 탐색하고, 그다음 컨테이너 네트워크의 MTU를 낮추거나 터널에서 TCP MSS를 죄어라. 어느 수정이든 UDP 경로를 다시 쓸 수 있게 만들고 플래그의 필요를 없애는 경우가 많은데, 필터링이 원인이 아닐 때는 이것이 더 나은 결과다.

무엇을 맞바꿀지 정하라

데이터 채널을 끄면 터널은 페이로드를 TCP 연결 안에 실어 나른다. 깨끗한 경로에서는 그저 더 느릴 뿐이지만, 손실이 있는 경로에서는 세그먼트 하나가 잃히면 뒤의 모든 것이 늦어지고 바깥 재전송이 안쪽과 경쟁한다. 이 거래는 대화형 개발과 작은 API 호출에는 맞고, 대용량 전송이나 모바일 링크에서의 긴 세션에는 잘 맞지 않는다.

어떤 선택을 하든, 터널이 결국 어느 전송로를 썼는지와 그 이유를 기록하라. 몇 달 전 누군가 더한 플래그에 조용히 의존하는 컨테이너가 다음 장애이며, 그것을 디버깅하는 사람은 그 플래그가 필터링 우회책이었는지 MTU 실험의 잔재였는지 알 수 없다.