Pritunl 사설 DNS가 실패하나요? 좁은 resolver 경로를 추가하세요

사설 이름은 사내 네트워크에서는 모두에게 확인되지만 VPN에서는 모두에게 시간 초과됩니다. Resolver는 게이트웨이에 응답하고 그곳으로 가는 경로도 있는데, 질의는 여전히 응답을 받지 못합니다. 빠진 것은 또 다른 공용 resolver나 더 넓은 경로가 아니라, 사설 DNS 서버가 응답하려는 소스 주소입니다.

Resolver가 클라이언트 풀을 거부하는지 확인하세요

실패가 연결 가능성이 아니라 소스의 문제임을 먼저 증명하세요. 연결된 클라이언트에서 사설 resolver에 직접 질의하고 요청이 시간 초과되는지 거부로 돌아오는지 관찰하세요. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 이 시간 초과되는데 같은 질의가 게이트웨이에서는 성공한다면 resolver의 접근 정책을 가리킵니다. SERVFAIL 응답은 전혀 다른 곳, 보통 영역이나 상위 포워더를 가리킵니다.

테스트 전에 클라이언트 주소를 기록하세요. 클라이언트의 ip -4 addr show tun0 또는 콘솔에 표시된 임대는 resolver가 어떤 풀을 보는지 알려줍니다.

그다음 경로가 실제로 존재하는지 확인하세요. Resolver 주소를 터널로 보내는 경로는 전제 조건이지 해결책이 아닙니다. 패킷이 도착하지 않으면 소스 정책은 검토되지 않습니다. 클라이언트에서 ip route get 10.40.0.53 로 확인하세요.

모두 변환하는 대신 호스트 경로 하나를 추가하세요

Pritunl의 사설 DNS 지침은 좁은 해법을 설명합니다. Resolver 주소에 대해 NAT를 켠 /32 경로를 만들고 그 주소를 클라이언트의 DNS 서버로 선택합니다. 경로는 DNS 트래픽에 대해서만 resolver가 보는 소스를 바꿉니다. 애플리케이션 트래픽은 그에 맞게 선택한 소스 보존 설계를 유지합니다.

기존 경로의 중복을 검토한 뒤 서버가 지원하는 경로 소유자를 통해 설정하세요. 위 예에서 목적지는 NAT가 켜진 10.40.0.53/32 이고 클라이언트 풀은 10.90.0.0/24 로 유지됩니다. 하나의 서비스를 고치려고 사설 범위 전체를 변환하지 마세요. 클라이언트의 실제 주소에 의존하는 모든 하위 정책이 대신 게이트웨이를 보게 됩니다. 테스트 조회 중 resolver의 질의 로그를 보아 실제로 받는 주소를 확인하세요. 호스트 경로만으로는 변환이나 허용에 대해 아무것도 증명하지 못합니다.

Resolver는 여전히 변환된 소스를 UDP와 TCP에서 허용해야 하고, 그 응답이 돌아올 수 있어야 합니다. 소스를 바꿔도 없는 영역이나 레코드를 만들 수는 없습니다.

질의를 서버가 보내는지 클라이언트가 보내는지 결정하세요

Pritunl은 VPN Client DNS Mapping과 연결된 DNS 프록시 구성도 문서화합니다. 여기서 서버는 클라이언트를 대신해 상위 질의를 전달합니다. 그 모델에서 상위 소스는 서버 자체의 네트워크 컨텍스트에 속하며, 클라이언트 측 예외는 잘못된 수정입니다.

무엇이든 추가하기 전에 어떤 모델이 활성인지 파악하세요. 세 가지 중복된 수정, 프록시, 클라이언트 resolver 덮어쓰기, 수동 NAT 스크립트는 보통 아무도 다음을 확정하지 않았다는 뜻입니다: 어느 구성 요소가 질의를 보내야 하는지. bootstrap도 확인하세요. 사설 전용 resolver만이 터널이 존재하기 전에 엔드포인트를 찾는 유일한 방법일 수는 없으며, 영구적인 resolver 수정이 연결보다 오래 남아서는 안 됩니다.

공용 웹 페이지가 아니라 사설 조회를 테스트하세요

변경을 적용하고 다시 연결한 뒤 클라이언트의 실제 resolver 구성을 확인하고, 사설 영역에만 있다고 아는 이름을 확인하세요. 서버를 명시하지 않은 dig intranet.example.net 는 클라이언트가 실제로 무엇을 쓰는지 보여줍니다. 이어서 그 조회가 반환한 주소로 요청을 보내세요. 확인과 서비스 접근은 별개의 단계이기 때문입니다. DNS-over-HTTPS로 공용 사이트를 불러오는 브라우저는 운영 체제의 사설 resolver 경로에 대해 아무것도 증명하지 못합니다. 공용 보조 resolver도 내부 영역의 권한이 아닙니다.

Resolver 주소, /32 경로, 클라이언트 DNS 설정을 함께 서버 메모에 기록하세요. 그 구성의 절반만 복원하면 원래 실패가 재현됩니다.

마지막으로 DNS가 성공한 뒤에도 터널이 애플리케이션 목적지로 라우팅하는지 확인하세요. 경로, 서비스 접근, 인증은 이름 확인과 무관하게 유지되며, 작동하는 조회는 처리량에 대해 아무것도 말해주지 않습니다. 사설 페이지가 느리지만 확인된다면 resolver는 제 역할을 했고 문제는 경로로 옮겨간 것입니다.