홈 VPN에 nas.home.arpa용 자체 DNS 레코드를 부여하세요
dnsmasq에서 이름 하나를 게시하고, 리졸버를 WireGuard로 라우팅한 다음, 클라이언트 전체에 DNS를 푸시할지 home.arpa만을 위한 split-DNS를 쓸지 선택하세요.
터널이 올라오면 마지막 단계는 보통 북마크에 붙여 넣는 주소 대신 동작하는 이름입니다. dnsmasq 호스트 레코드와 클라이언트가 도달할 수 있는 리졸버 주소가 있으면 두 개의 파일과 멀티캐스트 없이 그것을 해냅니다. 정말 고민이 필요한 결정은 더 좁습니다: 클라이언트가 모든 DNS를 집 리졸버로 보낼지, home.arpa 아래의 이름만 보낼지입니다. 아래의 모든 내용은 Linux 클라이언트와 집 관리자가 이미 운영하는 실습용 리졸버를 갖춘 승인된 WireGuard 구성을 전제로 합니다.
클라이언트에 리졸버를 넘기는 세 가지 방법
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
터널에 가끔 접속하는 노트북에는 일반 인터넷 이름을 기계가 이미 신뢰하는 리졸버에 그대로 두기 때문에 split-DNS가 더 나은 기본값입니다. 집 서비스에 도달하기 위해 존재하는 기계에는 리졸버를 푸시하는 편이 더 간단하고 범위 비용은 문제가 되지 않습니다.
영역을 소유한 리졸버에서 레코드를 게시하세요
구성을 쓰기 전에 역할을 분리하세요: VPN 클라이언트 주소, 리졸버, 서비스는 세 가지 다른 일을 하는 세 개의 다른 호스트입니다. 이 실습에서는 클라이언트가 10.77.0.2, dnsmasq가 192.168.50.53, NAS가 192.168.50.20이며 터널이 집 LAN을 라우팅합니다.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20host-record 줄이 주소를 제공하고 local= 줄은 알 수 없는 home.arpa 질의를 상위로 전달하지 않고 이 리졸버 안에 붙잡아 둡니다. 먼저 기존 구성을 읽고 서버, 인터페이스 또는 같은 로컬 도메인을 이미 정의하는 모든 것을 조정하세요(충돌하는 설정 위에 조각을 겹치면 기꺼이 로드되고 잘못 응답하는 리졸버가 됩니다). dnsmasq 설명서가 두 지시문과 수신 제어를 정의합니다.
그다음 파일이 아니라 실행 중인 서비스를 검증하세요. 구성 테스트와 재시작이 최소이며, 실효 응답은 질의가 돌려주는 것입니다.
리졸버를 라우팅하세요, 웹 페이지만이 아니라
WireGuard의 AllowedIPs는 어떤 목적지가 터널로 들어가는지 결정합니다. 리졸버 주소가 그 밖에 있으면 질의는 일반 경로로 나가 dnsmasq에 결코 도달하지 못합니다(NAS 자체에 도달할 수 있어도 마찬가지입니다). 리졸버 주소나 그것을 포함하는 LAN 접두사를 넣고, 반대편 게이트웨이의 전달 정책을 확인하세요.
권한이 부여된 터널 범위에서 포트 53의 UDP와 TCP를 허용하고, 클라이언트의 터널 주소로 돌아오는 경로를 마련하세요. 테스트를 쉽게 하려고 WAN에서 포트 53을 전달하지 마세요: 집 연결의 열린 재귀 리졸버는 몇 시간 안에 발견됩니다. 인터페이스에 바인딩하는 것 자체는 접근 정책이 아닙니다.
애플리케이션보다 먼저 응답을 확인하세요
먼저 리졸버에 직접 묻고, 다음 시스템에, 다음 애플리케이션에 물으세요. 각 단계가 사슬의 고리 하나를 분리하며, 그 차이가 진단입니다.
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'TCP 질의를 실행할 가치가 있는데, 잘린 UDP 응답이 재시도를 강제하고 TCP 53을 버리는 정책이 간헐적으로 보이는 장애를 만들기 때문입니다. getent 단계는 기계의 리졸버 구성이 실제로 무엇을 하는지 보여 주며, 그것은 푸시한 내용과 항상 같지는 않습니다.
터널이 내려가 있을 때 무슨 일이 일어나는지 정하세요
클라이언트의 일반 DNS가 192.168.50.53을 가리키면 터널이 올라와 있지 않을 때 모든 이름 해석이 멈춥니다. 그것은 터널과 함께여야만 쓸모 있는 기계에서는 받아들일 수 있고, 카페 Wi-Fi도 쓰는 노트북에서는 받아들일 수 없습니다. split-DNS는 home.arpa 조회만 집 리졸버에 의존하므로 이 질문을 완전히 피합니다.
그 이름이 무엇인지 기억하세요: home.arpa는 주거용 네트워크용으로 예약되어 있고 전 세계적으로 고유하지 않으므로 다른 네트워크가 같은 이름을 정당하게 사용할 수 있습니다. 그것은 지역적 편의일 뿐 신뢰할 수 있는 식별자가 아닙니다. 서비스가 이전하면 레코드를 최신으로 유지하고, 실습을 폐기할 때는 더 이상 존재하지 않는 터널로만 도달할 수 있는 주소를 가리키는 노트북을 남겨 두지 말고 리졸버 정책을 제거하세요.