호스트가 VPN에 연결되면 VirtualBox 게스트의 DNS가 깨진다

VPN이 연결되는 순간 Windows 호스트에서는 내부 애플리케이션이 확인되지만, VirtualBox NAT 뒤의 Ubuntu 게스트는 여전히 그것을 찾지 못한다. 게스트에는 자체 리졸버가 있고 NAT 어댑터는 DNS를 한 가지 이상의 방식으로 처리할 수 있다. 게스트의 리졸버를 공용 서버로 바꾸면 일반 웹사이트는 동작하고 사설 이름은 실패하는데, 이는 문제를 해결하는 대신 다른 곳으로 옮기는 것이다. 네 가지 점검을 순서대로 수행하고 맞지 않는 첫 지점에서 멈춘다.

어떤 어댑터 모드를 디버깅하는지 확인한다

이 문서가 설명하는 동작을 하는 것은 일반 NAT 모드의 어댑터뿐이다. 브리지 어댑터는 자체 식별 정보를 가지고 물리 네트워크에 있고, NAT 네트워크는 자체 DHCP와 DNS 설정을 가진 이름 있는 가상 스위치이며, 게스트 내부의 VPN 클라이언트는 완전히 두 번째 리졸버를 추가한다. 더 읽기 전에 모드를 확인해야 하는데, 이는 각 경우에 수리가 다르기 때문이다.

한 가상 머신이 서로 다른 모드의 어댑터 두 개를 가질 수 있고, 영향을 받는 것이 항상 첫 번째는 아니다.

호스트가 그 이름을 아예 확인하는지도 확인한다. 터널을 올린 상태에서 호스트에서 같은 애플리케이션을 열고, 게스트가 사용할 것과 같은 정규화된 이름을 쓴다. 호스트도 실패하면 원인은 게스트가 아니며 어떤 가상 네트워크 변경으로도 고칠 수 없다.

게스트 리졸버를 통해 이름 하나를 추적한다

내부 이름 하나와 공용 대조 이름 하나를 골라 두 곳에서 모두 시험한다. 공용 이름은 확인되는데 사설 이름이 확인되지 않으면 결함은 이름 확인 전반이 아니라 사설 경로에 있다. 사설 이름만 시험하면 고장 난 리졸버와 고장 난 경로를 구분할 수 없다.

게스트 내부에서 리졸버가 실제로 무엇을 쓰도록 설정되었는지 본다. systemd-resolved를 실행하는 Ubuntu 게스트에서는 링크별 상태가 도착한 서버를 보여 주고, resolv.conf 파일에는 스텁 주소만 있을 수 있는데 이는 의심스러운 것이 아니라 올바른 상태다. 손으로 편집한 파일이나 별도의 암호화 DNS 클라이언트가 조회를 완전히 다른 곳으로 보낼 수 있다. 바꾸기 전에 찾은 내용을 적어 둔다.

resolvectl status
resolvectl query app.internal.example

여기서는 이름 확인과 도달성을 분리한다. 서비스가 도달 불가능한 채로 주소만 도착한다면 이는 DNS가 아니라 라우팅이나 정책의 문제다.

그 어댑터에서 호스트 리졸버 모드를 시험한다

VirtualBox의 NAT DNS 옵션은 서로 다른 메커니즘을 설명하며, 호스트 자체 리졸버가 터널과 함께 바뀌면 그 차이가 중요해진다. DNS 프록시는 게스트 요청을 넘겨받은 서버로 전달한다. 호스트 리졸버 모드는 요청을 가로채 호스트의 DNS API를 호출하며, VPN 클라이언트로 재구성된 Windows 리졸버를 따라가는 방식이 이것이다.

잘못된 메커니즘을 켜면 동작이 바뀌지 않은 채 명령만 성공하는데, 오후를 날리는 혼란스러운 방법이다.

VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on

가상 머신의 현재 설정을 기록하고 전원을 끈 뒤 앞서 확인한 어댑터를 대상으로 한다. 옵션의 마지막 숫자는 상수가 아니라 어댑터 번호이므로, 영향을 받는 어댑터가 두 번째인 머신에 적용하면 조용히 아무 일도 일어나지 않는다. 게스트를 시작해 실제로 받은 리졸버 구성을 확인한다(게스트 쪽 수동 설정은 NAT 계층이 제공하는 모든 것을 덮어쓰기 때문이다). 호스트 리졸버 모드는 공유하려는 것이 호스트 자체의 DNS 경로라는 점도 전제한다는 것을 기억한다.

VPN 재연결에 걸쳐 같은 시험을 반복한다

게스트에서 두 조회를 모두 반복한 뒤 실제 애플리케이션을 열어 인증서를 스스로 검증하게 한다. 주소만 보는 시험은 이름 확인을 분리하는 데 유용하고 동작하는 TLS 세션과 같지 않으므로 ping에서 멈추지 않는다. 그다음 승인된 시간에 호스트 터널을 끊었다가 다시 연결하고 한 번 더 반복한다. 부팅 후 첫 연결에서만 유지되는 동작은 보고해야 할 수명 주기 문제이지, 다른 리졸버로 쫓아야 할 DNS 수수께끼가 아니다.

공용 확인이 동작한다고 해서 사설 질의가 정책이 요구하는 경로에 머물렀다는 증거는 아니다.

호스트 리졸버 모드가 아무것도 바꾸지 않으면 기록한 구성을 되돌리고 네 가지 관찰, 즉 호스트가 반환한 것, 게스트가 반환한 것, 어댑터 모드, 리졸버 상태를 남긴다. 도달할 수 없는 내부 서버, 하이퍼바이저 트래픽을 제외하는 필터, 게스트 쪽 재정의는 각각 다른 수정이 필요하다. 어댑터를 브리지로 바꾸는 것은 네트워크 설계를 바꾸는 일이며 DNS 재설정이 아니다.