Docker VPN 포트 매핑이 OpenVPN에 도달하지 못하는 이유
호스트 포트, 컨테이너 포트, 전송 방식은 세 가지 별개의 결정입니다. 인증서를 건드리기 전에 UDP 시도 하나를 각 경계마다 추적하세요.
컨테이너가 UDP 1195에서 수신하고 호스트가 1194를 공개해도, 매핑이 그렇게 말한다면 올바릅니다. 숫자들은 번역표를 이룹니다. 클라이언트가 호스트 포트로 접속하면 Docker가 목적지를 컨테이너 포트로 다시 쓰고, OpenVPN은 자체 설정이 지정한 포트에서 응답합니다. 이 연결 고리 중 하나라도 어긋나면 방화벽처럼 보이는 조용한 실패가 생깁니다. 인증서와 암호는 그 하류에 있어 이 문제를 고칠 수 없습니다.
인증에 관해 무엇이든 바꾸기 전에 패킷 하나를 클라이언트에서 프로세스까지 따라가 보세요.
세 개의 숫자, 하나의 연결
세 숫자는 클라이언트가 사용하는 원격 목적지, 호스트에 공개된 매핑, 컨테이너 내부의 리스너입니다. 같을 필요는 없지만 사슬을 이뤄야 합니다. 숫자가 같은 것은 우연히 가장 흔한 특수한 경우이므로, 불일치는 한 번 적기 쉽고 나중에 보기 어렵습니다.
디버깅 전에 사슬을 한 줄로 적으세요. 클라이언트 주소와 포트, 호스트 매핑, 컨테이너 리스너, 전송 방식입니다. 사슬의 결함은 서로 다른 값으로 두 번 나타나는 숫자로 드러납니다.
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN on UDP 1195 |
짧은 표기가 실제로 말하는 것
짧은 형식에서 왼쪽은 호스트 포트, 오른쪽은 컨테이너 포트이며, 슬래시 접미사가 전송 방식을 고릅니다. 접미사를 빼면 Docker가 매핑을 TCP로 처리하므로, 프로토콜이 없는 매핑 뒤의 UDP 리스너는 아무도 도달할 수 없는 리스너가 됩니다. 이 기본값은 문서화되어 있지만 숫자를 맞추고 끝냈다고 생각한 사람들을 여전히 놀라게 합니다.
긴 형식은 바인드 주소와 프로토콜을 명시적으로 고정하므로, 네트워크에 노출된 무엇이든 추가 줄의 값을 합니다. 매핑을 만든 파일을 믿는 대신 공개된 매핑을 다시 읽으세요.
ports:
- 1194:1195/udp패킷이 멈출 수 있는 곳
요청은 Docker 앞에서, Docker 안에서, 또는 리스너에서 버려질 수 있습니다. Docker 앞에는 클라우드 방화벽이나 자체 전달을 하는 라우터가 있을 수 있고, 그 장치에는 호스트 쪽 포트와 올바른 전송 방식이 필요합니다. Docker 안에서는 잘못된 컨테이너 포트로 가는 매핑이 닫힌 소켓으로 전달합니다.
다음은 리스너입니다. OpenVPN 설정은 포트와 프로토콜을 지정하고, 컨테이너 안에서 다른 포트로 도착한 클라이언트는 아무것에도 도달하지 못합니다. UDP 서비스를 TCP로 시험하는 것은 어느 단계에서도 아무것도 증명하지 못하므로, 클라이언트가 쓸 전송 방식을 쓰세요.
바인드 주소가 도달 가능성을 결정한다
loopback에 바인드된 공개 매핑은 호스트에서만 도달할 수 있고, 모든 인터페이스에 바인드된 매핑은 방화벽이 허용하는 어디서든 도달할 수 있습니다. 주소를 생략한 Compose 파일에서는 둘이 똑같아 보이며, Docker 기본값은 넓은 쪽입니다.
배포가 어떤 노출을 의도하는지 결정하고, 그것을 명시적으로 쓰세요. loopback으로 연결하는 내부 시험과 연결할 수 없는 원격 클라이언트는 둘 다 같은 컨테이너에 대한 정확한 설명일 수 있습니다.
실행 중인 상태를 읽으세요
실행 중인 컨테이너의 실제 매핑과 그 네트워크 네임스페이스의 리스너를 확인하세요. 컨테이너가 시작된 뒤 Compose 파일이 편집되었을 수 있고, 이미지 메타데이터가 포트를 공개하지 않고 선언할 수 있으며, 두 번째 컨테이너가 이미 호스트 포트를 차지하고 있을 수 있습니다. 이미지에서 포트를 선언하는 것은 공개하는 것이 아니며, 둘 다 수신과 같지 않습니다.
세 가지 다른 상태, 세 가지 다른 명령, 그리고 마지막 것만 OpenVPN과 관련됩니다.
매핑이 올바른 뒤
패킷이 OpenVPN에 도달하면 그 로그가 TLS와 인증에 관해 읽을 곳입니다. 도착하지 않은 패킷을 고치려고 인증서를 다시 만드는 것은 두 번째 변수를 더하는 헛된 일입니다. 매핑 메모를 클라이언트 프로필 옆에 두어 다음 사람이 세 숫자를 다시 알아내는 대신 한 줄을 읽게 하세요. 호스트 쪽에서 패킷을 한 번 캡처하면 세 고리 중 어느 것이 틀렸는지 판정되며, 인증서를 다시 만드는 것보다 비용이 적습니다.
여기서 설명한 사례는 브리지 공개입니다. 호스트 네트워킹과 라우팅된 컨테이너 주소는 변환을 건너뛰므로, 그 설계에서는 같은 숫자가 다른 의미를 가집니다.