OpenVPN 클라이언트를 다른 호스트의 Pi-hole 리졸버로 연결하기

OpenVPN 프로필에 Pi-hole 주소를 넣는 것만으로는 그곳으로 가는 경로가 생기지 않고, 조회 권한이 생기지 않으며, 클라이언트가 그것을 사용한다는 보장도 없습니다. Pi-hole이 별도 LAN 머신에 있을 때는 네 가지가 맞아야 합니다: 클라이언트에서 오는 경로, 게이트웨이의 전달, 풀 쪽으로 돌아오는 경로, 그리고 Pi-hole 자체의 수신 정책입니다. 각 실패는 로그에서 다르게 보입니다. 그 순서대로 처리하는 편이 마지막 문제를 먼저 고치는 것보다 빠릅니다. 흔한 지름길인 모든 출처에 대한 재귀 허용은 작은 문제를 영구적인 문제로 바꿉니다.

푸시된 DNS 옵션이 하는 일과 하지 않는 일

서버는 192.168.50.53이 Pi-hole 호스트라고 가정하고 아래 지시문으로 리졸버를 알립니다. 클라이언트는 옵션을 받고, 플랫폼과 리졸버 통합 방식에 따라, 터널 인터페이스에 적용하거나 로컬 스텁을 위해 무시합니다. 경로 줄은 DNS 줄만큼 중요합니다. 클라이언트가 닿지 못하는 리졸버는 리졸버가 아니기 때문입니다. 이 중 어느 것도 서버 쪽에서는 보이지 않습니다.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

옵션을 받는 것과 사용하는 것은 다릅니다. 리졸버 관리자가 있는 Linux 클라이언트는 푸시된 서버를 받아들여 특정 도메인만 보낼 수 있고, DNS를 직접 관리하는 클라이언트는 설정을 완전히 덮어쓸 수 있습니다. 푸시된 경로도 일부 플랫폼에서는 제한되어, 옵션이 수락되었더라도 리졸버에 닿지 못합니다. 서버에서 무엇을 보냈는지가 아니라 클라이언트에서 어느 서버가 응답하는지 확인하십시오.

옵션은 서버 쪽에 대해서도 아무것도 말하지 않습니다. DNS 트래픽은 어떤 옵션이 의미를 갖기 전에 여전히 클라이언트에서 게이트웨이로, 게이트웨이에서 Pi-hole로 이동해야 합니다. 빠진 경로와 거부된 질의는 클라이언트 입장에서 똑같이 보이므로 먼저 게이트웨이의 전달을 확인하십시오.

Pi-hole에서 풀로 돌아오는 경로

클라이언트의 출발지 주소가 보존되면 Pi-hole은 VPN 풀 내부 주소로 응답합니다. Pi-hole의 라우팅 테이블은 그 풀에 대해 아무것도 모를 가능성이 높으므로 응답은 기본 게이트웨이로 가서 사라집니다. 질의 로그에는 일치하는 응답이 없는 요청이 남는데, 이를 방화벽 문제로 오해하기 쉽습니다.

LAN 라우터에 OpenVPN 게이트웨이를 다음 홉으로 하는 풀 정적 경로를 주거나, Pi-hole로 전달하기 전에 게이트웨이에서 출발지를 변환하십시오. 전자는 각 클라이언트 주소를 Pi-hole 질의 로그에 그대로 보이게 합니다. 후자는 반환 경로 요구를 없애지만 모든 질의가 게이트웨이에서 온 것처럼 보이게 합니다. 어느 쪽도 틀리지 않으며, 서로 다른 질문에 답합니다.

클라이언트별 보고나 정책이 중요하다면 정적 경로가 더 나은 거래입니다. LAN을 다른 사람이 관리하고 경로를 쓸 수 없다면 변환이 현실적인 선택이며, 클라이언트 신원이 사라진다는 점을 기록해야 합니다. 어느 쪽을 골랐는지 적어 두십시오. 이후의 모든 로그 질문이 그것에 달려 있습니다.

라우팅된 클라이언트를 위한 Pi-hole의 수신 모드

DNS 아래 설정 페이지의 인터페이스 수신 동작 드롭다운은 Pi-hole이 어느 출처에 응답할지 결정합니다. 가장 엄격한 옵션은 직접 연결된 네트워크의 클라이언트만 받습니다. 장치를 최대 한 홉 거리까지 허용하는 옵션은 이를 인접 라우터 뒤의 서브넷까지 확장하며, 라우팅된 VPN 클라이언트가 바로 그렇게 보입니다. 패킷은 실제로 LAN 인터페이스에 도착하지만 출발지 주소는 다른 서브넷에 속합니다. 이것은 라우팅 실패가 아니라 정책 거부이며, 로그를 읽을 때 그 차이가 중요합니다.

Pi-hole의 수신 가이드 는 로컬로 연결된 출처와 라우팅된 출처를 구분하며, 도착 인터페이스가 기준이 아닙니다. 전체 인터넷을 허용하지 않으면서 VPN 풀은 허용하는 모드를 고르고, 풀에서만 DNS를 받는 방화벽 규칙과 짝지으십시오.

첫 질의가 동작하도록 모든 출처에 재귀를 여는 것은 잘못된 수리입니다. 사설 리졸버를 공개 리졸버로 만들며, 해결책은 전역 허용이 아니라 범위가 한정된 허용입니다.

응답을 질의 로그와 맞추기

클라이언트에 물어보고, 그다음 서버를 확인하고 둘을 비교하십시오. systemd-resolved 클라이언트에서 아래 명령은 어느 리졸버가 응답을 만들었고 링크별로 어떤 서버가 구성되어 있는지 알려 줍니다. Pi-hole만 아는 이름을 사용하십시오. Pi-hole 주소로 직접 질의하는 것은 구성이 아니라 도달 가능성을 증명하기 때문입니다.

resolvectl query intranet.example.lan
resolvectl dns

예상되는 응답은 192.168.50.53을 서버로 지목하고 그 리졸버만 알 수 있는 주소를 반환합니다. 그다음 Pi-hole 자체의 보기를 보십시오: pihole -t 는 질의 로그를 실시간으로 따르며 모든 줄에 출발지 주소가 있습니다. 출처가 클라이언트의 터널 주소라면 풀 경로가 온전합니다. 게이트웨이의 LAN 주소라면 출발지 변환이 작동 중이며 클라이언트 자신의 주소는 결코 나타나지 않습니다.

로그에 아무것도 나타나지 않으면 질의가 Pi-hole에 도달한 적이 없고 다음에 확인할 것은 게이트웨이의 전달입니다. 질의가 나타나는데 응답이 돌아오지 않으면 문제는 반환 경로, 즉 앞 절의 문제입니다. 실패를 이렇게 나누면 라우팅 오류를 방화벽 규칙으로 착각하지 않게 됩니다.

게이트웨이의 전달 규칙 확인

게이트웨이는 클라이언트의 DNS 패킷을 Pi-hole 쪽으로 전달해야 하며, 그 일을 하는 규칙은 가정하지 말고 읽어 볼 가치가 있습니다. 아래 명령은 포트 53을 건드리는 규칙을 카운터와 함께 나열하며, nftables 호스트와 iptables 호스트에서 각각 실행합니다. 존재하지만 일치가 영으로 표시되는 규칙은 트래픽이 변환되기 전에 버려진다는 신호입니다.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

규칙만이 아니라 카운터를 읽으십시오. 절대 일치하지 않는 규칙은 패킷이 다른 인터페이스로 나가거나 클라이언트가 애초에 보내지 않았다는 뜻입니다. 모든 질의에서 일치하는 규칙은 전달이 동작하고 문제가 경로 더 앞에 있다는 뜻입니다.

호스트가 어떤 도구를 쓰든 검사를 좁게 유지하십시오. 풀을 출발지로, 포트 53을 목적지로, Pi-hole을 유일한 허용 대상으로 두십시오. 포트 80까지 허용하는 넓은 전달 규칙은 발생하기를 기다리는 또 다른 문제입니다.