VPN DNS가 모든 조회를 가져갑니다: NetworkManager의 dns-priority 수정

사무실 VPN에 연결하면 갑자기 모든 이름 조회가 회사 리졸버로 갑니다. 공용 이름은 여전히 해석되므로, 로컬 프린터 이름이 실패하거나 split-horizon 레코드가 사무실 주소를 반환할 때까지는 아무것도 고장 난 것처럼 보이지 않습니다. 일부 Fedora 구성에서는 반대 일이 벌어집니다: 터널이 올라간 뒤에도 ISP 리졸버가 계속 응답하는 것입니다. 둘 다 하나의 질문입니다 — 이 조회를 소유한 리졸버는 어느 것인가 — 그리고 NetworkManager 시스템에서는 답이 연결별 DNS 속성에 있습니다.

두 연결, 하나의 승리하는 리졸버

각 연결은 DNS 우선순위를 선언합니다. 일반 연결은 기본값이 50이고 VPN 연결은 0이며, 더 낮은 값이 이깁니다. 바로 이 기본값 때문에 VPN 연결이 요구하는 모든 도메인에서 유선 연결을 조용히 앞지릅니다: 아무도 선택하지 않았는데 영이 오십을 이기는 셈입니다.

우선순위는 후보의 순서를 정합니다. 승자에게 무엇을 물을지를 제한하지는 않습니다. 검색 도메인이 없는 VPN 연결은 모든 것을 요구하므로, 그것을 우선하면 공용 조회도 터널로 들어가고 분할 터널 설계에서는 회사 리졸버가 전달하는 곳으로도 들어갑니다.

우선순위는 순서를, 검색 목록은 소유권을 정합니다

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

검색 목록은 소유권 선언입니다. corp.example 같은 맨 도메인은 검색 접미사이자 라우팅 도메인이 됩니다. 라우팅 전용 형식인 ~corp.example은 짧은 이름에 도메인을 붙이지 않고 그 접미사 아래의 조회를 이 연결로 보냅니다. 그 물결표가 «이 서버에 물어보라»와 «이 서버에 물어보고 내 입력까지 끝내라»의 차이입니다.

사용자가 짧은 호스트 이름을 입력하고 레코드가 정규화된 이름으로도 지정될 때는 두 형식을 모두 쓰십시오. 리졸버가 맨 이름을 완성하는 방식을 바꾸지 않고 분할만 원할 때는 라우팅 형식만 쓰십시오.

그다음 선호를 명시하고 다시 활성화하십시오:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

음수 우선순위는 «이 연결을 선호하라»고 말하는 문서화된 방법이며, 두 주소 체계를 모두 설정하면 IPv6 연결이 있는 호스트에서 동작이 일관되게 유지됩니다. 연결을 다시 활성화하지 않고 속성만 바꾸면 지금 실행 중인 것은 아무것도 바뀌지 않으므로, 이 순서는 명시적인 up으로 끝납니다.

분할은 systemd-resolved가 맡게 하십시오

기본 dnsmasq 플러그인은 조회를 하나의 로컬 리졸버로 몰아넣으므로 링크별 분리는 거칠게 남습니다. systemd-resolved는 링크별 분할을 드러내며, resolvectl query는 응답한 링크를 지목합니다.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

그 뒤에는 회사 링크가 corp.example을 담당하고 공용 리졸버가 나머지를 처리합니다. 조회가 잘못된 링크에 닿으면 명령은 그 조회에 응답한 링크를 지목하며, 그것을 아는 편이 주소만 아는 것보다 낫습니다.

DNS 설계를 터널 유형에 맞추십시오

모든 것을 터널로 보내는 프라이버시 설계는 공용 이름을 로컬 리졸버로 돌려주어 의도를 무효화하므로 분할 목록을 가져서는 안 됩니다. 분할 터널 설계에는 그것이 필요하고, 없으면 회사 리졸버가 모든 공용 조회를 보게 되며, 터널이 끊기는 순간 설정이 깨집니다.

다음으로 터널 밖 DNS를 막는 kill switch가 있습니다. 터널의 영역은 해석되고 나머지 모든 곳에서는 실패하지만, 연결 자체는 완전히 정상입니다. 실용적인 답은 LAN 리졸버에 대한 명시적 허용이나 회사 영역만 전달하는 로컬 캐시이며, 둘 다 터널의 결함이 아니라 소유자가 있는 예외입니다.

인터페이스가 시작될 때 리졸버 구성을 다시 쓰는 프로필도 거의 같은 방식으로 동작합니다: 로컬 리졸버에 닿을 수 없게 되면 터널이 아는 이름만 해석됩니다. 어떤 메커니즘이 적용되든 각 상태에서 어떤 이름이 동작해야 하는지 적어 두고, 그 목록을 보고를 처리하는 사람에게 주십시오.

링크별로 확인하고, 재연결 후에 다시 확인하십시오

내부 이름 하나와 공용 이름 하나를 물어보고 조회가 실제로 어디로 가는지 보십시오. 유출 검사 페이지는 어느 리졸버가 응답했는지 알려 줄 뿐 시스템이 어느 링크를 골랐는지는 알려 주지 않으므로, 방금 구성한 순서에 대해서는 아무 말도 하지 않습니다.

연결을 끊었다가 다시 연결한 뒤 두 조회를 다시 실행하십시오. 연결이 활성화될 때 우선순위가 다시 적용되며, 오래된 심볼릭 링크는 아무도 기억하지 못하는 업그레이드를 견딜 수 있습니다. 마지막에 적어 두고 싶은 것은 어느 리졸버가 어느 접미사를 소유하는지, 그리고 내일도 유효한 점검입니다.