The Social Dork가 ZimaBoard 2로 Pi-hole 광고 차단기를 만드는 방법

집과 외부에서 휴대폰을 사용할 때 DNS 요청을 필터링하는 Pi-hole 및 Tailscale 프로젝트를 공유해 주신 The Social Dork | 사이버 보안에 감사드립니다. ZimaBoard 2에서 서비스를 실행하고 Pi-hole이 요청된 도메인을 확인하며, Tailscale이 서버로 돌아가는 비공개 연결을 제공합니다. 전체 시연은 원본 YouTube 가이드에서 확인하세요.

읽기 전에 시청하세요: 가정의 DNS 설정을 바꾸기 전에 네트워크 수준 광고 필터링이 어떤 역할을 하는지 알고 싶다면 이 8분짜리 영상이 유용합니다. 제작자는 ZimaOS에 Pi-hole을 설치하고 Windows 클라이언트에서 테스트한 뒤 차단 목록을 추가하고, 이어서 Tailscale을 통해 휴대폰을 연결합니다.

유용한 결과는 재사용할 수 있는 DNS 필터링 서비스입니다. 제작자는 예시 웹사이트에서 눈에 띄는 광고가 줄어든 모습과 원격 휴대폰의 조회 활동을 보여 줍니다. 이러한 관찰은 해당 설정에서 필터링 경로가 작동한다는 점을 보여 주지만, 모든 광고, 트래커 또는 악성 연결이 차단된다는 뜻은 아닙니다.

하드웨어를 선택하기 전에 Pi-hole이 무엇을 필터링하는지 알아보세요

설명은 여러 도메인에서 콘텐츠를 불러오는 웹사이트에서 시작합니다. Pi-hole은 클라이언트의 DNS 요청을 받아 요청된 이름을 설정된 정책에 따라 확인합니다. 허용된 이름은 업스트림 리졸버를 통해 확인할 수 있고, 차단된 이름에는 차단 응답을 보냅니다. 중요한 제어 지점은 클라이언트가 해당 도메인에서 콘텐츠를 가져오려 하기 전의 DNS 조회 요청입니다.

이 범위에는 한계도 있습니다. 광고와 원하는 콘텐츠가 같은 호스트 이름을 사용하는 경우 DNS 필터는 둘을 구분할 수 없습니다. 다른 리졸버를 사용하는 클라이언트는 선택한 경로를 우회할 수 있습니다. 영상 제목의 “모든 광고 차단”은 보편적으로 달성되는 결과가 아니라 프로젝트의 목표로 이해하세요. 브라우저 콘텐츠 필터링과 DNS 필터링은 서로 다른 계층에서 작동하며 함께 사용할 수 있습니다.

네트워크 전체를 바꾸기 전에 하나의 조회 요청이 시스템을 통과하는 과정을 따라가 보세요. 클라이언트가 호스트 이름을 요청하면 Pi-hole이 정책을 적용하고, 허용된 요청은 업스트림 리졸버로 전달될 수 있습니다. 응답은 클라이언트로 돌아옵니다. 이후의 웹 연결은 별도의 흐름입니다. 따라서 차단된 도메인 카운터는 DNS 활동을 보여 주는 유용한 근거이지만, 애플리케이션이 만드는 모든 연결을 측정하는 것은 아닙니다.

홈 네트워크에서 DNS 서비스에 안정적인 위치를 마련하세요

The Social Dork는 ZimaBoard 2를 사용하며 영상에 나온 ZimaOS 앱 스토어를 통해 Pi-hole을 설치합니다. 제작자는 기존 노트북을 대체 호스트로 사용할 수도 있다고 언급합니다. 중요한 것은 클라이언트가 DNS에 의존하는 동안 계속 사용할 수 있는 기기입니다. 이 시연만으로는 필터링을 위해 가장 큰 메모리 옵션을 구매해야 할 이유가 확인되지 않습니다.

호스트를 연결하고 DNS 엔드포인트에 안정적인 주소를 지정하거나 DHCP 예약을 설정한 다음, 테스트 클라이언트에서 서비스에 연결할 수 있는지 확인하세요. 컨테이너 네트워킹과 포트 매핑에 따라 클라이언트가 사용해야 할 주소가 달라집니다. 관리 페이지에 접속된다고 DNS 서비스도 준비되었다고 가정하지 말고, 해당 엔드포인트에서 실제로 DNS 쿼리에 응답하는지 확인하세요.

클라이언트 설정을 변경하기 전에 주소를 기록하세요

컨테이너 설치에서는 TCP와 UDP DNS 서비스에 모두 연결할 수 있는지 확인하세요. Pi-hole의 공식 Docker 예시는 포트 53에서 두 프로토콜을 모두 노출하고 설정 디렉터리를 영구 저장합니다. 앱 스토어에서 컨테이너 설정을 설치 버튼 뒤에 숨겨 두더라도 이런 세부 사항은 중요합니다. 같은 포트를 이미 사용하는 호스트 서비스를 변경하기 전에 실제 앱 설정을 확인하세요.

영상에는 제작자의 ZimaOS 앱 스토어에서 설치하는 모습이 나옵니다. 현재 앱 버전과 네트워크 모드는 다를 수 있습니다. 앱이 네트워크에 연결되는 방식을 설명하는 설정, 즉 주소, 공개 포트, 저장 위치, 업스트림 리졸버, 재시작 동작을 기록해 두세요. 이 간단한 기록은 나중에 마이그레이션하거나 재설치할 때 확인하는 데 도움이 됩니다.

가정용 네트워크의 DNS를 변경하기 전에 클라이언트 한 대에서 테스트하세요

안내 영상에서는 Windows 노트북을 집 Wi-Fi에 연결한 상태로 IPv4 DNS 설정을 Pi-hole 주소로 변경합니다. 그런 다음 제작자는 질의 활동을 확인합니다. 처음 테스트하기에 부담이 적은 방법입니다. 웹 탐색이 중단되더라도 해당 클라이언트의 설정만 복구하면 되고, 집 안의 다른 기기는 기존 설정을 계속 사용할 수 있습니다.

더 많은 기기에 적용하려면 Pi-hole 설치 후 가이드에서 DHCP를 통해 클라이언트에 Pi-hole DNS 주소를 알리는 방법을 확인하세요. 클라이언트의 임대를 갱신하거나 다시 연결한 다음, 실제로 어떤 리졸버를 사용하는지 확인하세요. IPv6 DNS와 브라우저 또는 운영체제의 암호화 DNS 설정도 살펴보세요. IPv4 필드 하나를 변경했다고 해서 모든 조회가 해당 경로를 따른다는 뜻은 아닙니다.

필터링되지 않은 보조 리졸버가 있으면 예상한 결과가 나오지 않을 수도 있습니다. 클라이언트가 다른 설정된 리졸버를 엄격한 비상용으로만 두지 않고 사용할 수 있습니다. 연결 유지와 일관된 필터링 중 어느 쪽을 우선할지 정하고, Pi-hole 호스트를 사용할 수 없을 때 동작을 테스트하세요. DNS 실험을 쉽게 되돌릴 수 있도록 기존 설정을 기록해 두세요.

반복 가능한 로컬 테스트 사용

1. 노트북의 현재 DNS 설정과 사용할 Pi-hole 엔드포인트를 기록하세요.
2. 허용되는 조회를 Pi-hole에 명시적으로 보내고 로그에서 해당 질의를 찾으세요.
3. 현재 사용 중인 차단 목록에 있는 도메인을 테스트하고 차단 결과를 확인하세요.
4. 클라이언트의 일반 DNS 기본 설정을 Pi-hole로 지정하고 리졸버를 명시적으로 선택하지 않은 상태에서 테스트를 반복하세요.
5. DHCP를 통해 변경 사항을 적용하기 전에 로그인 절차를 포함한 일반 서비스를 몇 가지 이용해 보세요.

예를 들어, nslookup example.com PIHOLE_LAN_IP는 지정된 리졸버를 테스트합니다. PIHOLE_LAN_IP를 서버 주소로 바꾸세요. 이렇게 명시적으로 질의하면 해당 엔드포인트 자체를 확인할 수 있습니다. 이어서 nslookup example.com을 실행하면 시스템의 일반적인 리졸버 경로를 확인할 수 있습니다. 어느 테스트도 브라우저가 자체 DNS 설정으로 동일한 경로를 사용하는지 단독으로 증명하지는 못하므로, 해당 애플리케이션에서 새 요청도 확인하세요.

문제 원인을 찾을 때는 주소 연결 가능 여부와 이름 확인을 따로 점검하세요. 기기가 Wi-Fi에 계속 연결되어 있어도 DNS 엔드포인트가 오프라인이면 사이트를 열지 못할 수 있습니다. 새 리졸버가 안정적으로 작동할 때까지 기존 클라이언트 설정을 사용할 수 있도록 보관하세요. DHCP를 변경한 뒤에는 임대를 갱신하거나 다시 연결하고, 클라이언트가 실제로 받은 설정을 확인하세요.

문제 해결이 쉽도록 차단 목록을 추가하세요.

이어서 제작자는 차단 목록을 추가로 가져오고 차단된 도메인 수가 늘어나는 모습을 보여줍니다. 이 수치는 브라우징 경험의 품질이 아니라 정책 데이터베이스의 규모를 나타냅니다. 목록이 커지면 원치 않는 도메인을 더 많이 포함할 수 있지만, 공유 서비스에 의존하는 로그인 절차, 미디어 플레이어 또는 기타 기능이 제대로 작동하지 않을 수도 있습니다.

관리되는 목록을 한 번에 하나씩 추가하고, 필터링 데이터베이스를 새로고침한 다음 실제로 사용하는 서비스를 다시 테스트하세요. 문제가 발생하면 쿼리 로그에서 영향을 받은 이름을 확인하고 범위를 좁힌 허용 목록 항목을 테스트하세요. Pi-hole의 도메인 데이터베이스 문서에서 허용 및 차단 항목이 서로 어떻게 적용되는지 확인할 수 있습니다. 로그인 문제 하나를 해결하려고 관련 없는 도메인 모음을 광범위하게 허용하지 마세요.

새 목록이나 예외를 추가한 이유를 변경 사항과 함께 기록하세요. 합리적인 정책은 성공적인 스크린샷 한 장에 그치지 않고, 일주일간의 일반적인 사용에도 문제없이 유지되어야 합니다. 다른 사람들을 위해 필터를 관리한다면, 서비스가 작동하지 않을 때 대략 몇 시에 문제가 발생했는지 알릴 방법을 마련하세요. 이는 “인터넷이 안 돼요”라는 막연한 신고보다 문제 해결에 훨씬 유용합니다.

Tailscale을 사용해 외출 중에도 같은 필터에 접속하세요

후반부에서는 서버와 휴대폰에 Tailscale을 추가합니다. 테일넷 DNS 설정에서 The Social Dork는 서버의 Tailscale 주소를 네임서버로 입력한 다음 휴대폰을 연결하고 Pi-hole 활동을 다시 확인합니다. DNS 엔드포인트는 집에 그대로 있고, 권한이 있는 휴대폰은 사설 네트워크를 통해 해당 엔드포인트에 연결할 수 있습니다.

Tailscale의 Pi-hole 공식 연동 안내에서 최신 설정 정보를 확인하세요. Pi-hole이 의도한 사설 인터페이스를 통해 들어오는 쿼리를 수락하고 테일넷 액세스 정책이 DNS 트래픽을 허용하는지 확인하세요. 지원되는 클라이언트에서 구성된 테일넷 네임서버를 우선 사용하게 하려면 Tailscale의 DNS 재정의 동작을 검토하고 실제 클라이언트에서 해당 설정을 확인하세요.

Tailscale을 통해 가정용 DNS 리졸버를 사용해도 모든 웹 트래픽이 자동으로 집의 인터넷 연결을 통과하는 것은 아닙니다. 홈 엑시트 노드를 통한 전체 인터넷 송신은 별도의 구성입니다. 이 프로젝트에는 DNS 서비스로 연결되는 사설 경로만 필요하며, 공용 DNS 리졸버나 관리 페이지를 인터넷에 공개할 필요는 없습니다.

사설 DNS 경로를 단계별로 검증하세요

1. 서버와 휴대폰이 의도한 테일넷에 등록되어 있고 서로 연결할 수 있는지 확인하세요.
2. 접속 가능한 Pi-hole 엔드포인트를 의도한 테일넷 네임서버로 추가하세요.
3. 원하는 동작에 맞게 클라이언트의 Tailscale DNS 사용 여부와 네임서버 재정의 설정을 검토하세요.
4. Pi-hole 리스너와 액세스 정책이 해당 사설 경로에서 오는 DNS 요청을 허용하는지 확인하세요.
5. 휴대폰의 홈 Wi-Fi 연결을 끊고 허용된 조회와 차단된 조회를 다시 시도하세요.

특정 로컬 네트워크에서만 요청을 수락하도록 구성된 리스너는 집에 있는 클라이언트에서는 작동하지만 Tailscale 클라이언트에서는 실패하는 이유일 수 있습니다. Pi-hole의 DNS 리스너 구성 참고 자료에서 사용 가능한 모드를 확인하세요. 컨테이너 및 사설 네트워크와 호환되는 모드를 선택하되, 인바운드 액세스는 의도한 클라이언트로 제한하세요. 리스너 설정을 넓게 허용한다면 그에 맞게 방화벽 경계도 명확히 설정해야 합니다.

DNS 설정과 인터넷 이그레스도 구분하세요. 네임서버는 조회를 필터링할 수 있지만 이그레스 노드가 되는 것은 아닙니다. 이그레스 노드를 별도로 활성화했다면 DNS 동작을 다시 확인하세요. Tailscale의 DNS 및 네임서버 참고 자료에서 이러한 상호작용을 설명합니다. 집 Wi-Fi에서 테스트가 성공했다고 해서 같은 휴대전화를 모바일 데이터로 테스트하는 것을 대신할 수는 없습니다.

단순한 카운터가 아니라 경로를 대상으로 최종 테스트하기

Wi-Fi를 끈 상태에서 모바일 데이터로 연결하는 등 다른 연결을 통해 테스트를 반복하세요. 휴대전화에서 새로 실행한 조회가 Pi-hole에 표시되는지, 허용된 사이트가 계속 열리는지, 선택한 차단 대상 이름에 필터링 응답이 돌아오는지 확인하세요. 총계가 늘어나는 것만으로는 다른 기기의 요청도 포함될 수 있으므로, 테스트 결과와 연결하려면 해당 클라이언트와 타임스탬프를 확인하세요.

이 크리에이터 시리즈의 다음 단계는 무선 클라이언트용 Pi-hole DNS가 적용된 OPNsense 방화벽입니다. 애플리케이션과 원격 액세스를 구성하는 더 폭넓은 예로, kabuto의 모듈형 홈랩 구축에서는 이러한 서비스가 어떻게 관리되는 물리적 환경에 들어맞는지 보여 줍니다. 작동하는 클라이언트 하나로 시작한 다음, 로컬 및 원격 경로를 확인한 뒤 필터링 정책을 확장하세요. 원래 순서를 보려면 The Social Dork의 Pi-hole 및 Tailscale 시연을 다시 확인하세요.

처음 실패한 계층부터 문제 해결

다른 기기가 이 서비스에 의존하게 되면 가정의 필수 서비스로 관리하세요. 구성을 백업하고, 작동하는 정책 소스 목록을 보관하며, 먼저 클라이언트 하나로 업데이트를 테스트하세요. 호스트를 재시작한 뒤에는 허용된 조회와 차단된 조회를 다시 확인하세요. 앱 아이콘이 대시보드에 다시 표시되는 것은 확인 작업의 시작일 뿐입니다.

Pi-hole의 컨테이너 구성 문서에서는 영구 저장 및 네트워킹 옵션을 설명합니다. 다른 사람의 주소가 나온 스크린샷에 의존하지 말고, 해당 운영 기록을 직접 선택한 구성과 함께 보관하세요.

자주 묻는 질문

Pi-hole이 YouTube 광고를 모두 차단하나요?

원하는 동영상과 광고가 같은 호스트 이름을 공유하면 DNS 필터링만으로 안정적으로 구분할 수 없습니다. 이 프로젝트는 도메인 필터링으로 이해하고, 모든 광고가 제거된다고 기대하기보다 사용하는 앱에서 직접 확인하세요.

가정의 모든 기기에 Tailscale이 필요한가요?

집 안의 기기는 DNS 설정에서 연결 가능한 LAN Pi-hole 엔드포인트를 사용할 수 있습니다. 이 프로젝트에서는 집을 떠나 있는 동안에도 같은 리졸버를 사용해야 하는 기기에 사설 연결을 제공하기 위해 Tailscale을 사용합니다.

이 설정에 Tailscale Exit 노드가 필요한가요?

단순히 사설 DNS 서비스에 연결하기 위한 것은 아닙니다. Exit 노드는 인터넷 트래픽 경로를 변경하며, 자체 DNS 동작을 설정하는 별도의 구성입니다.

Pi-hole 페이지는 열리는데 DNS는 작동하지 않는 이유가 무엇인가요?

웹 인터페이스와 DNS 서비스는 서로 다른 포트를 사용하며, 컨테이너 매핑이나 액세스 규칙도 다를 수 있습니다. 지정한 주소로 DNS 쿼리를 직접 보내고, 일치하는 로그 항목이 있는지 확인하세요.

다른 DNS 서버가 필터를 우회할 수 있는 이유는 무엇인가요?

클라이언트는 두 번째로 설정된 네임서버를 반드시 비상용 대체 서버로만 사용하지는 않습니다. 일관된 필터링이 중요하다면 알림에 포함된 모든 리졸버와 클라이언트의 실제 동작을 확인하세요.

앱을 업데이트하기 전에 무엇을 저장해야 하나요?

정상 작동이 확인된 테스트에 사용한 앱 설정, 영구 데이터 위치, 정책 소스, 클라이언트 설정을 저장하세요. 업데이트 후 같은 테스트를 반복해 설정이 유지되었는지 확인하세요.

결론

The Social Dork의 프로젝트는 세 가지 결정을 연결합니다. DNS를 어디서 실행할지, 어떤 클라이언트가 이를 사용할지, 그리고 권한이 부여된 휴대전화가 다른 네트워크에서 어떻게 연결할지입니다. 유용한 배포 방식은 이러한 결정을 확인하고 테스트할 수 있게 합니다. 가장 확실한 근거는 클라이언트의 일치하는 조회 기록, 예상한 정책 응답, 그리고 정상적으로 작동하는 일반적인 웹 탐색입니다.

클라이언트 하나로 시작하고, 로컬 테스트가 성공하면 DHCP로 확대하세요. 그런 다음 실제로 별도의 네트워크에서 Tailscale이 작동하는지 확인하세요. 이후에는 가정에서 의존하는 서비스로 필터를 유지 관리하세요. 제작자의 진행 순서에 맞춰 원본 Pi-hole 및 Tailscale 동영상을 확인할 수 있도록 제공하고, 설치된 버전에 맞는 최신 공식 문서도 함께 참고하세요.