포트 53의 OpenVPN: 사람들이 혼동하는 세 가지 대화
엔드포인트 조회, 암호화된 전송, 터널 이후의 DNS는 서로 다른 세 가지 대화입니다. 포트나 리졸버를 바꾸기 전에 어느 단계가 실패했는지 파악하세요.
VPN이 포트 53에서 차단되었다고 말하는 보고서는 서로 다른 이유로 실패하는 세 가지 관찰을 섞어 놓습니다. 엔드포인트 이름 조회는 터널이 존재하기 전에 일어나고, 암호화된 전송은 별개의 대화이며, 그 뒤에 이루어지는 DNS 쿼리는 세 번째입니다. 각각 고유한 실패 징후가 있으며, 그중 DNS와 관련된 것은 하나뿐입니다.
수정은 단계를 따르므로 무엇이든 바꾸기 전에 패킷을 목적별로 분류하세요.
세 가지 대화, 하나의 포트 번호
첫 번째 대화는 엔드포인트에 대한 이름 조회로, 여러분의 컴퓨터는 설정된 리졸버에 vpn.example.com 가 어디 있는지 묻고, 그 응답은 클라이언트가 터널 패킷을 하나도 보내기 전에 일반 DNS를 통해 도착합니다. 두 번째는 OpenVPN 전송 자체로, 조회가 산출한 주소로 프로필이 지정한 프로토콜과 포트에서 연결합니다. 세 번째는 터널이 올라온 뒤에 일어나며, 애플리케이션이 이름을 요청하고 푸시된 리졸버 설정이 누가 응답할지 결정합니다.
이 셋은 각각 독립적으로 성공하거나 실패할 수 있습니다. 클라이언트는 엔드포인트를 완벽하게 조회하고도 리스너에 도달하지 못할 수 있고, DNS 설정이 도착하지 않아 모든 내부 이름 조회가 실패하는 동안 터널을 세울 수도 있습니다.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
표를 설명이 아니라 점검 목록으로 읽으세요. 엔드포인트 이름이 조회되지 않으면 그 뒤의 어떤 것도 작동할 수 없고, 터널은 시작되지 않습니다.
포트 번호는 애플리케이션의 이름이 아니다
포트 53이 DNS를 나르는 것은 관례일 뿐이고 OpenVPN 운영자는 그곳에 리스너를 공개할 수도 있으므로, 이 번호는 식별자로서 부적절합니다. UDP 53의 OpenVPN 세션은 여전히 OpenVPN 세션이고, 포트 53의 서버로 보내는 DNS 쿼리는 터널이 허용되는지에 대해 아무것도 말해 주지 않습니다. 프로필의 proto 와 remote 줄이 바깥 엔드포인트를 정의하며, 포트 번호 자체는 아무것도 정의하지 않습니다.
진단할 때 이 점은 양방향으로 작용하는데, 포트 53으로 보내는 일반적인 UDP 프로브는 어떤 포트가 응답한다는 것만 증명하고 VPN 서비스가 응답한다는 것은 증명하지 않습니다. 서비스가 기대하는 핸드셰이크를 연습하는 것은 실제 클라이언트와 실제 프로필뿐이므로 그것으로 시험하세요.
네트워크를 탓하기 전에 리스너를 증명하라
서버에서는 ss -lunp | grep 53 로 무엇이 바인딩되었는지 확인하고 프로필의 프로토콜 및 포트와 비교하세요. 클라이언트의 네트워크에서는 더 자세한 로그로 클라이언트를 실행해 어떤 주소와 전송을 시도했는지 기록에서 확인하세요. 서버가 듣고 있는데 클라이언트 패킷이 도착하지 않는다면 경로나 정책이 이를 거부하는 것이며, 그것은 네트워크 소유자와의 대화이지 포트를 바꿀 이유가 아닙니다.
다른 포트가 도움이 되는 경우는 서비스가 실제로 그곳에서 듣고 배포가 이를 허용할 때뿐입니다. 관리되는 네트워크의 필터링을 피하려고 리스너를 옮기는 것은 정책 결정이지 문제 해결 단계가 아닙니다. 서비스를 바꾸기 전에 네트워크 소유자에게 무엇이 허용되는지 물어보세요. 정책을 위반하는 우회는 나중에 어차피 닫히므로, 그 답을 프로필 옆에 적어 두어 다음 사람이 같은 요청을 반복하지 않게 하세요.
터널 이후의 DNS를 따로 확인하라
터널이 올라오면 VPN 인터페이스의 리졸버 상태를 살피고 내부 이름 하나와 공개 이름 하나를 조회하세요. 터널이 트래픽을 나르는 동안 내부 이름이 실패한다면 푸시된 DNS 설정이 적용되지 않은 것이고, 이는 전송이 아니라 클라이언트 통합의 문제입니다. 공개 이름이 실패하고 내부 이름이 작동한다면 분할 터널 정책이 설정된 대로 동작하는 것입니다.
DNS 변경은 리졸버 소유자에게 맡기세요. 한 번의 시험을 통과시키려고 관리되는 리졸버 설정을 덮어쓰면 머신의 다른 모든 것에 대해 사설 이름이 깨질 수 있습니다. 터널이 리졸버를 푸시하는데 클라이언트가 무시한다면 다른 곳에 정적 항목을 추가하는 대신 클라이언트 통합을 고치세요. 정적 항목은 누군가 네트워크를 바꿀 때까지 실패를 숨깁니다. 어떤 리졸버가 어떤 네임스페이스에 응답해야 하는지 적어 두세요.