OpenVPN이 푸시한 DNS가 무시됨: 어느 구성 요소가 적용하는가

로그에는 서버가 푸시한 옵션이 보이고 터널은 올라가 있는데 내부 이름은 여전히 실패합니다. 리졸버에 직접 질의하면 응답하므로 서버는 정상이지만, 모든 애플리케이션이 계속 로컬 라우터에 묻고 있습니다. 클라이언트에 도착한 것은 제안이며 리졸버의 변경이 아니고, 이름 확인을 소유하는 구성 요소는 Linux, Windows, macOS에서 다릅니다. 옵션과 소유자를 분리하면 거의 모든 보고가 네 가지 결함으로 정리됩니다. 훅이 없거나, 두 훅이 경쟁하거나, 분할 DNS가 설계대로 동작하거나, 짧은 이름에 서버가 아니라 접미사가 필요한 경우입니다.

푸시된 옵션은 제안이며 설치가 아닙니다

서버에서는 두 지시문이 효과가 아니라 의도를 설명합니다:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

클라이언트는 구성된 리졸버를 받지 않습니다. 환경 변수를 받으며, foreign_option_1 그 이후 것들까지 푸시된 줄마다 하나씩이고, 로컬의 무언가가 이를 읽어 운영체제의 리졸버 상태를 다시 써야 합니다. Linux에서는 기본적으로 아무것도 하지 않으므로 올바른 서버와 연결된 클라이언트도 여전히 LAN을 통해 이름을 확인합니다.

양 끝 사이에 세 단계가 있습니다: 푸시가 도달해야 하고, 클라이언트가 이를 노출해야 하며, 훅이 이를 적용해야 합니다. 중간 단계는 클라이언트 로그에서, 마지막 단계는 리졸버 상태에서 읽되 결코 반대로 하지 마십시오. 로그 한 줄은 앞의 두 가지만 증명하기 때문입니다.

푸시가 도착했는지 확인하고 소유자를 찾으십시오

먼저 실행기를 특정하십시오. 맨 openvpn 명령인지, systemd 인스턴스인지, NetworkManager인지, 공급업체 클라이언트인지입니다. 이것이 훅이 살 수 있는 위치를 정합니다. systemd-resolved가 있는 호스트에서 resolvectl status 는 실제로 사용하는 DNS 서버와 검색 도메인과 함께 각 링크를 나열하며, 터널 링크의 이름이 항상 tun0 은 아닙니다.

푸시된 주소가 로그에는 있지만 어느 링크에도 없으면 통합이 빠진 것입니다. 링크에는 있는데 질의가 여전히 다른 곳으로 나가면 문제는 어느 질의가 그 링크를 선택하는가입니다. NetworkManager는 dns=dnsmasq 을 /etc/NetworkManager/NetworkManager.conf 에 두면 로컬 포워더를 실행해 분할 DNS를 의도적으로 구현하며 VPN 도메인 안의 이름은 VPN 리졸버로 가고 나머지는 이전 경로를 유지합니다. 모든 트래픽이 옮겨지리라 기대할 때 이 동작은 결함처럼 보이지만, 연결별 설정을 nmcli connection show "My VPN"로 확인하고 ipv4.dns 와 ipv4.dns-search 가 장치가 보고하는 값의 배후에 있음을 확인한 뒤 고장이라고 부르십시오. 정말 모든 질의가 VPN 리졸버에 도달해야 한다면 dns=dnsmasq 을 NetworkManager.conf 에서 제거하고 NetworkManager를 다시 시작하십시오. 그러면 이름 확인이 연결 설정으로 돌아갑니다. 그렇지 않으면 분할 DNS를 유지하고 푸시된 도메인 목록을 고치십시오.

Linux: 옵션을 리졸버에 넘기십시오

배포판 패키지는 이를 위한 훅을 제공하며, 클라이언트가 실행할 수 있도록 허용해야 합니다. systemd-resolved가 없는 호스트의 전형적인 구성은 다음과 같습니다:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved가 있으면 오래된 resolv.conf 스크립트는 중요한 것을 바꾸지 못할 수 있습니다. stub 리졸버가 링크별 상태를 유지하기 때문입니다. update-systemd-resolved 도우미는 up-restart 와 down-pre를 사용하는 훅 형태를 문서화하며, 이는 인터페이스가 한 번의 연결 시도보다 오래 살아남을 때 중요합니다. 무엇을 고르든 상태를 소유하는 구성 요소는 하나여야 합니다. NetworkManager 옆에 무관한 훅을 더하면 같은 링크에 작성자가 둘이 되고, 결과는 설정이 아니라 순서에 좌우됩니다.

NetworkManager가 푸시된 옵션을 전혀 무시하다가 연결의 IPv4 설정에 서버 주소를 입력한 뒤에야 리졸버 상태에 나타난 사례도 있습니다. 스크립트를 다시 쓰기 전에 시험할 가치가 있습니다. 문제가 셸 훅에서 터널을 이미 나르는 연결 프로필로 옮겨가기 때문입니다.

Windows와 macOS는 다른 부분을 적용합니다

Windows 클라이언트는 VPN 어댑터의 DNS 서버를 실제로 설정하지만, Windows는 여전히 메트릭으로 인터페이스를 고르고 짧은 이름을 확장하려면 접미사가 필요하며, 프로필이 아니라 어댑터 상태를 확인하십시오.

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

주소가 없으면 다음으로 설정하고, Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1 그다음 어댑터의 IPv4 속성에 접미사를 추가해 fileserver 가 되게 fileserver.corp.example 시스템 전체의 SearchList 값은 Tcpip\Parameters 아래에서도 같은 역할을 합니다. 긴 이름은 확인되고 맨 이름은 안 될 때 리졸버는 이미 올바르고 검색 목록이 원인이므로 수정 순서는 이렇습니다. DOMAIN 를 푸시해 클라이언트가 접미사를 배우게 하고, 그 접미사를 어댑터나 연결의 검색 목록에 넣고, 임시 조치로 이름을 hosts 에 고정하십시오. Windows에서는 LMHOSTS 도 됩니다. NetBIOS 탐색은 라우터를 넘지 않으므로 사무실 LAN에서 짧은 이름을 찾는 브로드캐스트는 터널 클라이언트에 결코 도달하지 않습니다.

block-outside-dns block-outside-dns는 Windows 클라이언트의 동작이며 이식 가능한 프로필 줄이 아닙니다. Linux나 macOS 프로필로 복사해도 그곳에서 재현되지 않습니다. Windows에서 공용 이름은 되고 내부 이름이 실패하면 고급 설정의 어댑터 순서를 ipconfig /all 와 비교하십시오. macOS에서는 서비스별 리졸버 순서가 시스템에 속하므로 scutil --dns 를 사용해 어느 도메인에 어느 리졸버가 질의되는지 보고, 보고된 단일 프로필 수정은 일반적이 아니라 클라이언트 의존으로 취급하십시오.

같은 노트북의 가상 머신은 이것을 물려받지 않습니다. 게스트에 내부 도메인용 자체 리졸버 항목을 주거나, 하이퍼바이저의 NAT가 그 질의를 호스트를 통해 전달하게 하십시오. 후자는 호스트 터널이 올라가 있는 동안만 옳습니다.

이력이 세 번째 원인입니다. 이전 프로필의 DNS 서버나 접미사 설정은 재연결을 견딜 수 있습니다. 어댑터가 올바로 보이는데 조회가 실패하면 살아 있는 어댑터를 Get-VpnConnection 와 비교하고, 서버를 건드리기 전에 오래된 항목을 지우거나 덮어쓰십시오.

질의가 어디로 갔는지 증명하십시오

한 번의 조회 중 캡처가 논쟁을 끝냅니다: tcpdump -ni eth0 port 53 는 물리 인터페이스에서 질의를 보여 주며, 이는 터널 밖으로 나가고 리졸버가 전혀 바뀌지 않았음을 뜻합니다. dig @10.8.0.1 name.corp.example 는 남은 두 경우를 가릅니다. 직접 질의가 응답하면 리졸버는 동작하고 클라이언트가 쓰지 않는 것이며, 시간이 초과되면 리졸버가 터널로 도달 불가하여 로컬 변경으로는 해결되지 않습니다.

아직 쓰이는 리졸버가 공급자가 나눠 준 것이라면 터널은 트래픽을 암호화하지만 이름은 그 공급자에게 보입니다. 이것은 기능이 아니라 누출 문제이며 같은 캡처가 답합니다. 물리 인터페이스의 질의는 터널 밖의 누군가에게 갑니다.

도달성에는 VPN 호스트의 방화벽도 포함되며, 풀에서 오는 UDP와 TCP 53을 허용해야 합니다. 막힌 포트는 고장 난 푸시와 똑같이 보이고, 터널 네트워크 안에서만 응답하는 리졸버도 마찬가지입니다. 한 번 연결을 끊고 다시 연결한 뒤 캡처를 반복하십시오. 첫 연결에서 나타나고 두 번째에서 사라지는 설정은 빠진 옵션이 아니라 훅의 수명 주기 결함입니다.

소유자를 하나로 유지하고 순서대로 검증하십시오

추정한 터널 상태로 어댑터 DNS를 다시 쓰는 스크립트는 프로필이 이미 지닌 설정을 중복시키고, 추측이 처음 틀릴 때 조용히 실패합니다. 연결 자체의 DNS 설정이나 문서화된 훅 하나를 선호하고, 어느 것을 골랐는지 기록해 다음 사람이 두 번째를 더하지 않게 하십시오.

네 가지 확인으로 고리를 닫으십시오. 푸시된 주소가 터널 링크에 있음, 내부 이름이 정규화된 이름으로 확인됨, 같은 이름이 접미사 없이 확인됨, 그리고 한 번 재연결한 뒤에도 둘 다 참임입니다. 캡처 하나로 넷 중 어느 것이 실패했는지 알 수 있습니다. OpenVPN 2.6 설명서 는 dhcp-option 와 스크립트 지시문을 플랫폼 주석과 함께 나열합니다.