WireGuard는 DNS를 밀어 넣지 않는다: 사설 BIND 존 서비스하기

핸드셰이크는 키와 허용된 IP만 나르며 리졸버는 결코 나르지 않습니다. 여기에는 완성된 사설 BIND 9 존과 이를 해석하게 만드는 링크별 클라이언트 정책이 있습니다.

WireGuard를 올렸고 터널은 트래픽을 통과시키는데 내부 이름은 여전히 해석되지 않습니다. 다음 수순은 보통 WireGuard 설정에서 DNS 항목을 찾는 것인데, 마치 다른 VPN처럼 상대가 리졸버를 밀어 넣을 수 있다고 여기기 때문입니다. 그럴 수 없습니다. 핸드셰이크는 키, 인터페이스 주소, 허용된 IP만 나르며 DNS 서버나 검색 도메인을 위한 필드가 없습니다. 리졸버 정책은 클라이언트에 살고, 고칠 곳도 거기입니다.

터널과 리졸버는 별개의 계약

WireGuard는 의도적으로 작습니다. 지정한 주소에 대한 패킷을 옮기고 피어를 인증합니다. 그 계층 위의 모든 것은 당신의 설계입니다. OpenVPN 은 제어 채널이 설정을 나르기 때문에 dhcp-option DNS 를 밀어 넣을 수 있고, 이 차이가 둘 사이를 오가는 사람을 넘어뜨립니다.

그래서 동작하는 터널은 이름 해석에 대해 아무것도 말해 주지 않습니다. 클라이언트는 10.90.0.1 로 가는 완벽한 경로를 갖고도 질의를 공용 리졸버로 보낼 수 있고, 그래서 증상이 “VPN이 DNS를 망가뜨렸다”처럼 보입니다. 실제로 DNS는 VPN을 향한 적이 없습니다.

재귀 리졸버가 되지 않고 존을 서비스하기

서버 쪽은 작은 권한 존이며, 일반 리졸버가 아닙니다. 이 예에서 게이트웨이는 10.90.0.1, 클라이언트는 10.90.0.0/24, 관심 있는 애플리케이션은 10.60.0.20 에서 응답합니다.

이 설정들을 두 번째 블록을 만드는 대신 기존 options 블록에 병합하십시오:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

그다음 존과 그 파일을 선언합니다:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

읽는 시점의 구문 오류는 그 서버가 서비스하는 모든 존을 통째로 내리므로 다시 읽기 전에 검증하십시오:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP와 TCP 53 은 VPN 인터페이스에서만 여십시오. 공용 인터페이스에 사설 권한을 게시하면 질의와 열거를 모두 초대하며, allow-transfer 는 보조 서버가 정말 필요로 하지 않는 한 닫아 두어야 합니다.

클라이언트를 그쪽으로 향하게 하기, 링크마다

연결은 NetworkManager가 소유하고 리졸버는 systemd-resolved라고 가정합니다. 먼저 기존 정책, 특히 루트 라우팅 도메인을 읽으십시오. ~. 항목이 당신이 추가하려는 것보다 우선합니다.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

틸데가 중요한 문자입니다. 도메인을 경로 전용으로 표시합니다. corp.example 아래의 이름은 이 링크의 DNS 서버로 가며, 도메인은 짧은 이름 검색 접미사로 붙지 않습니다. 이것이 없으면 portal 를 입력할 때 portal.corp.example 해석이 시작되어 당신에게는 편하고 나머지 모두에게는 뜻밖입니다. 틸데를 따옴표 안에 두십시오. 따옴표가 없으면 홈 디렉터리를 가리키려고 기다리는 셸 확장이 됩니다.

인터페이스를 소유한 관리 도구로 변경을 적용한 뒤 연결을 다시 맺으십시오. 같은 인터페이스에 두 번째 wg-quick 인스턴스를 시작하지 마십시오. 소유자가 둘이면 경로를 두고 다투고, 둘 중 하나가 최악의 순간에 이깁니다.

이름보다 경로를 먼저 검증하기

클라이언트에서 이름을 질의하고 응답과 그것을 만든 서버를 모두 확인하십시오:

resolvectl query portal.corp.example

10.60.0.20 이 돌아오면 DNS 계약은 끝났습니다. 시간 초과라면 먼저 10.90.0.1 로 가는 경로, 다음 방화벽 규칙, 다음 서버의 allow-query 를 확인하십시오. 이 구성에서 이름 해석 실패는 거의 항상 도달 가능성이나 ACL이며 존 파일이 아닙니다. 클라이언트에서 바깥으로 조사하십시오. 서버는 질의가 왜 오지 않았는지 알려 줄 수 없습니다.

애플리케이션에는 여전히 자체 경로와 자체 서비스 권한이 필요합니다. 해석된 이름이 도달할 수 없는 주소를 가리키는 것은 같은 옷을 입은 다른 고장입니다.

아직 자동이 아닌 것

자체 리졸버 로직을 가진 애플리케이션은 시스템 리졸버를 완전히 무시하며, nmcli 를 아무리 써도 바뀌지 않습니다. DNSSEC 를 검증하는 배포에는 사설 존을 위한 명시적 신뢰 앵커 설계가 필요합니다. 검증을 끄라는 일괄 지시가 답이 아닙니다. 사용자가 실제로 쓰는 클라이언트 소프트웨어로 시험하고, 우연히 시스템 리졸버를 쓰는 도구로 대신하지 마십시오. 그 둘의 차이가 곧 버그 리포트 전체입니다.

플리트는 프로비저닝 시스템으로 이 클라이언트 정책을 자동화할 수 있지만, 정책은 소유자를 가진 별도 객체로 남습니다. BIND 9 참조 는 위에서 사용한 수신과 질의 제어를 다루며, 설치한 버전의 동작을 확인하기에 맞는 곳입니다.

다음 단계: 존의 일련번호 증가와 확인 명령을 변경 절차에 넣어, 레코드 편집이 검증 없이 운영에 도달하지 않게 하십시오.

관련 글