Docker 포트 게시와 VPN 소스: 놓치는 두 가지 일치

규칙은 VPN 서버 주소를 게시된 서비스로 허용하라고 하는데도 연결은 끊깁니다. 이 결과는 흔하며 Docker 버그가 아닙니다. 서로 다른 두 일치가 틀렸습니다. 적은 소스가 호스트가 받는 소스가 아닐 수 있고, 적은 포트가 필터가 보는 포트가 아닐 수 있습니다. 둘 다 고치려면 서비스 다이어그램이 아니라 패킷 경로를 봐야 합니다.

신화: VPN 서버를 허용하면 끝

라우팅 VPN은 클라이언트 터널 주소를 Docker 호스트까지 유지할 수 있습니다. 소스 변환을 하는 게이트웨이는 그 주소를 자신의 주소로 바꿀 수 있습니다. 두 설계 모두 정당하며, 같은 사용자 동작에 서로 다른 소스를 만듭니다.

따라서 VPN 서버 IP라는 표현은 관측이 아니라 가정을 기술합니다. 두 설계 중 어느 것이 앞에 있는지 알기 전까지 그 규칙은 추측입니다.

소스: 클라이언트 풀인가 변환된 게이트웨이인가

네 가지를 차례로 확인하십시오. 첫째, 클라이언트 주소 풀, 예를 들어 10.90.0.0/24입니다. 둘째, 게이트웨이가 그 풀을 호스트에 도달하기 전에 변환하는지 여부입니다. 셋째, 새 연결 하나에 대해 호스트가 실제로 관측하는 소스입니다. 넷째, 애플리케이션 인증이 개별 사용자를 구분하는지 여부입니다. 공유 변환 주소로는 구분할 수 없습니다.

풀이 유지되면 게이트웨이 공인 주소만 일치하는 규칙은 모든 클라이언트를 놓칩니다. 게이트웨이가 의도적으로 변환하면 변환된 주소를 허용하는 것이 그 뒤의 모든 사용자를 들여보내게 됩니다. 자체 로그인이 있는 서비스에는 받아들일 수 있지만 그 밖의 무엇에도 받아들일 수 없습니다.

포트: DNAT가 일치시키는 번호를 바꾼다

Docker iptables를 쓰는 일반적인 Linux 브리지 게시에서 호스트의 8443에서 컨테이너 포트 443으로의 매핑은 전달 필터가 실행되기 전에 변환됩니다. 패킷은 목적지 포트 443으로 필터에 도착합니다. 그 시점에 8443과 일치하는 규칙은 결코 발동하지 않습니다. 클라이언트가 입력한 것이 8443이더라도 그렇습니다.

게시된 포트는 연결 추적에 여전히 존재하므로, 정말 필요할 때 원래 목적지를 거기에서 일치시킬 수 있습니다.

어느 번호가 의도를 표현하는지 결정하십시오. 규칙이 컨테이너 내부의 서비스를 보호한다면 DNAT 후의 컨테이너 포트와 일치시키십시오. 규칙이 클라이언트가 요청한 것을 기술해야 한다면 conntrack 옵션으로 원래 목적지와 일치시키고, 그에 따르는 추가 일치 비용과 규칙 순서에 대한 주의를 받아들이십시오.

체인: INPUT이 아니라 DOCKER-USER

Docker의 iptables 안내서는 사용자 전달 정책을 DOCKER-USER 체인에 둡니다. 이 체인은 Docker 자체의 전달 규칙보다 먼저 평가됩니다. 호스트 서비스에서 INPUT 체인으로 복사한 규칙은 호스트로 향하는 트래픽을 필터링하며, 컨테이너로 전달되는 트래픽에는 효과가 없습니다. 이 실수는 올바르게 보이지만 컨테이너 경로에 아무 효과도 없는 규칙을 만듭니다.

소스 범위, 실효 목적지 포트, 프로토콜, 인바운드 인터페이스를 같은 규칙에 함께 두십시오. 전달되는 모든 목적지에 대해 소스만으로 허용하는 것은 게시된 서비스 하나를 허용하는 것보다 넓습니다.

새 연결로 검증하십시오

새 연결로 양방향을 시험하십시오. 허용된 VPN 클라이언트 하나와 거부된 채로 남아야 할 소스 하나입니다. 기존 연결 상태는 정책이 바뀐 뒤에도 세션을 살려 둘 수 있으므로, 오래된 연결은 새 규칙에 대해 아무것도 증명하지 못합니다. 그다음 응답 경로를 확인하십시오. 컨테이너는 여전히 자기가 보는 소스로 되돌아가는 경로가 필요하기 때문입니다.

이 점검들의 배후에 있는 체인 순서와 포트 변환 동작은 Docker의 iptables 안내서에 문서화되어 있습니다. 조리법을 복사하기 전에 그것을 읽고, 설치된 Docker가 어느 백엔드를 쓰는지 확인하십시오. nftables 백엔드는 정책을 다르게 통합합니다.