VPN 연결 후 Pi-hole이 광고를 차단하지 않을 때: 다섯 가지 점검

클라이언트에 광고가 계속 표시되고, Pi-hole은 자신이 건강하다고 보고하며, 터널은 올라와 있으므로 그 클라이언트의 트래픽을 Pi를 통해 보내고 싶어진다. 그것은 잘못된 방향이다. 필터링에는 패킷이 아니라 질문이 필요하며, 쿼리가 ISP 확인자로 가는 클라이언트는 트래픽이 어디로 흐르든 필터링되지 않은 채로 남는다. 이 목록을 순서대로 진행하고 실패하는 첫 단계에서 멈추라. 앞 단계가 깨져 있는 동안 뒤 단계는 아무것도 알려줄 수 없다.

1. 클라이언트가 실제로 사용하는 확인자를 읽어라

라우터가 아니라 클라이언트에게 물어라. Linux에서는 resolvectl status가 링크별 DNS 서버와 어느 링크가 이기는지 출력한다. /etc/resolv.conf만으로는 보통 127.0.0.53을 가리키는 스텁이다. Windows에서는 ipconfig /all이 어댑터별로 DHCP가 제공한 서버를 나열하고, macOS에서는 scutil --dns가 같은 내용을 범위별로 보여준다. 답이 Pi-hole의 주소가 아니라면 할당 문제가 있으며 단계 2가 그것이 있는 곳이다.

시스템 확인자가 올바르게 설정되어 있어도 두 가지가 그것을 이긴다. 자체 보안 DNS를 가진 브라우저(Chrome의 “Use secure DNS”, Firefox의 network.trr.mode)는 쿼리를 HTTPS로 공용 확인자에게 보내며 포트 53을 절대 열지 않는다. 그리고 클라이언트 자체의 VPN 클라이언트가 터널 인터페이스에 ~. 라우팅 도메인과 함께 DNS 서버를 설치할 수 있어, 그 링크가 모든 이름에 대해 권위를 갖게 된다.

애플리케이션이 지나는 경로를 시험하고, 디버그 도구가 지나는 경로를 시험하지 마라. resolvectl query example.com은 어느 링크가 답했는지 보여주고, getent hosts example.com은 애플리케이션과 같은 NSS 경로를 지난다. macOS에서는 dscacheutil -q host -a name example.com이 scutil --dns가 나열하는 범위별 확인자를 읽는다. 순수한 dig는 이렇게 하지 않는다. /etc/resolv.conf를 읽고 링크별 선택을 건너뛰므로, 모든 애플리케이션이 푸시된 확인자를 쓰는 동안에도 Pi-hole에서 답할 수 있으며, 이것이 바로 이 목록이 존재하는 이유인 실패다. 특정 서버를 시험하려면 dig @192.168.1.53을 남겨 두라.

2. 답을 누가 배포하는지 확인하라

할당은 DHCP에 응답하는 무엇이든에서 온다. dnsmasq에서는 한 줄, dhcp-option=6,192.168.1.53이다. 라우터의 웹 UI에서는 LAN DHCP 섹션의 DNS 필드다. 클라이언트는 그것을 보기 전에 갱신해야 한다. 며칠째 켜져 있는 기기는 여전히 이전 임대를 유지하고, 확인자를 수동으로 입력한 기기는 영원히 유지한다. 전파를 가정하지 말고 테스트 클라이언트에서 갱신하라.

IPv6는 놓치기 쉬운 절반이다. 라우터 광고는 자체 DNS 서버(RDNSS)를 실을 수 있고, OpenWrt에서는 odhcpd의 ra_dns 옵션이다. IPv6를 선호하는 클라이언트는 그 서버를 사용하는 반면 방금 설정한 DHCPv4 옵션은 사용되지 않은 채 남는다. IPv6 DNS를 제공할 준비가 되지 않았다면 DNS 광고만 지워라: odhcpd의 ra_dns, 또는 라우터 광고에 응답하는 무엇이든의 RDNSS 옵션이다. 광고 전체를 끄면 LAN에서 IPv6 주소 지정도 제거되어 의도한 것보다 훨씬 큰 변경이 된다. 반면 DNS 옵션만 지우면 주소 지정은 그대로 유지되고 빠진 RDNSS가 패킷 캡처에서 보이게 된다.

3. 쿼리가 Pi-hole에 도달함을 증명하라

Pi에서 보낸 쿼리는 네트워크 경로에 대해 아무것도 증명하지 않는다. 클라이언트에서 실행하고 응답 코드를 읽어라:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

시간 초과는 필터링이나 경로를, REFUSED는 접근 규칙을, SERVFAIL은 Pi-hole 뒤의 업스트림 확인자를 가리키며, 쿼리 로그에 절대 나타나지 않는 올바른 응답은 클라이언트가 다른 것을 물었다는 뜻이다. UDP와 TCP 53을 확인하라. 큰 응답과 일부 확인자는 TCP로 되돌아가며, Pi-hole이 컨테이너에서 실행될 때는 둘 다 게시해야 한다. UDP만 포괄하는 매핑은 패킷 손실처럼 보이는 간헐적 실패를 만든다.

다음으로 Pi-hole의 수신 모드가 애초에 응답하는지 결정한다. 로컬 전용 모드에서 dnsmasq는 직접 연결된 서브넷에 없는 소스의 쿼리를 무시하며, 다른 라우터 뒤에 있거나 터널로 들어오는 클라이언트가 정확히 그렇게 보인다. 클라이언트는 시간 초과되고 쿼리는 로그에 도달하지 않는다. 그래도 REFUSED로 나타나는 쿼리는 접근 목록이나 방화벽 규칙에 의해 거부된 것이다. 모든 소스를 허용하는 것이 일반적인 해결책이며, 포트 53을 자신의 서브넷으로 제한하는 방화벽 규칙과 짝을 이룬다.

4. 터널이 응답을 대체했는지 삼켰는지 확인하라

이것이 두 증상이 함께 숨어 있는 경우다. 라우터 자체가 VPN 클라이언트일 때, 푸시된 DNS 옵션이 터널이 올라오는 순간 LAN 설정을 덮어쓸 수 있다. OpenVPN 서버는 dhcp-option DNS를 푸시하고, WireGuard 프로필은 자체 DNS 항목을 갖는다. 터널이 올라온 상태에서 라우터의 실제 확인자를 읽고, 그 전에 읽지 말며, LAN 페이지의 주장은 무시하라.

다른 결함은 대체가 아니라 도달 가능성이다. 터널의 허용 접두사에 당신의 LAN 서브넷이 포함되어 있으면 라우터에는 192.168.1.53에 대한 쿼리를 터널 안으로 보내는 경로가 있고, 반대편에는 돌아오는 경로가 없다. 터널이 건강해도 쿼리는 시간 초과된다. Pi-hole이 터널이 나르지 않는 서브넷에 있을 때는 반대가 일어난다. DNS를 다시 건드리기 전에 주소를 터널의 허용 접두사와 라우터의 경로 테이블과 비교하라.

둘 다가 아니라 하나의 해결책을 골라라. 터널을 DNS에서 멀리 두거나 — OpenVPN에서 pull-filter ignore “dhcp-option DNS”, WireGuard에서 AllowedIPs에 LAN 접두사 없이 —, 푸시된 확인자를 받아들이고 그 라우터 뒤의 클라이언트에 대한 로컬 필터링을 포기하라. 무엇을 고르든 프로필 옆에 적어 두라. 그렇지 않으면 다음에 편집하는 사람이 실수로 결정을 뒤집을 것이다.

5. 재연결 후 테스트를 반복하라

클라이언트에서 쿼리하고, 그 클라이언트가 Pi-hole 로그에 나타나는지 확인한 다음, 차단되어야 할 도메인을 확인하여 실제 응답 대신 차단 응답을 받는지 점검하라. 터널을 다시 연결하고 같은 두 쿼리를 실행하라. 다음 연결까지만 유지되는 확인자 설정은 잘못된 계층에 적용한 수정의 흔한 결과다.

터널에 의존하지 않는 보조 확인자 경로를 남겨 두어, Pi-hole 중단이 브라우징 불가가 아니라 필터링 없는 브라우징으로 떨어지게 하라. 테스트가 두 번 통과할 때까지 이전 DHCP와 확인자 값을 유지하라. 저녁 식사 때 집 인터넷을 끊는 변경은 일 분 안에 되돌릴 수 있는 변경보다 디버그하기 훨씬 어렵다.