Pi-hole ไม่บล็อกโฆษณาหลังเชื่อมต่อ VPN: ห้าจุดตรวจ

โฆษณายังแสดงอยู่บนไคลเอนต์ Pi-hole รายงานว่าตัวเองแข็งแรง และอุโมงค์ทำงานอยู่ ดังนั้นสัญชาตญาณคือการส่งทราฟฟิกของไคลเอนต์นั้นผ่าน Pi นั่นคือทางเลี้ยวที่ผิด การกรองต้องอาศัยคำถาม ไม่ใช่แพ็กเก็ต และไคลเอนต์ที่คำค้นไปยังตัวแก้ชื่อของผู้ให้บริการจะยังไม่ถูกกรองไม่ว่าทราฟฟิกจะไหลไปทางไหน ทำตามรายการนี้ตามลำดับและหยุดที่ขั้นตอนแรกที่ล้มเหลว เพราะขั้นตอนถัดไปบอกอะไรคุณไม่ได้เลยตราบใดที่ขั้นตอนก่อนหน้ายังพังอยู่

1. อ่านตัวแก้ชื่อที่ไคลเอนต์ใช้จริง

ถามไคลเอนต์ ไม่ใช่เราเตอร์ บน Linux resolvectl status พิมพ์เซิร์ฟเวอร์ DNS ต่อลิงก์และลิงก์ใดชนะ /etc/resolv.conf เดี่ยว ๆ มักเป็น stub ที่ชี้ไปที่ 127.0.0.53 บน Windows ipconfig /all แสดงเซิร์ฟเวอร์ที่ DHCP มอบให้ต่ออะแดปเตอร์ และบน macOS scutil --dns แสดงสิ่งเดียวกันตามขอบเขต หากคำตอบไม่ใช่ที่อยู่ของ Pi-hole คุณมีปัญหาการกำหนด และขั้นตอนที่ 2 คือที่ที่มันอยู่

สองสิ่งเอาชนะตัวแก้ชื่อของระบบได้แม้ตั้งค่าไว้ถูกต้อง เบราว์เซอร์ที่มี DNS ปลอดภัยของตัวเอง (ตัวเลือก “Use secure DNS” ของ Chrome, network.trr.mode ของ Firefox) ส่งคำค้นผ่าน 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 ในหน้าเว็บของเราเตอร์นั่นคือช่อง DNS ในส่วน DHCP ของ LAN ไคลเอนต์ต้องต่ออายุสัญญาก่อนจึงจะเห็น อุปกรณ์ที่เปิดมานานหลายวันยังถือสัญญาเช่าเก่า และอุปกรณ์ที่พิมพ์ตัวแก้ชื่อเองจะถือไว้ตลอดไป ต่ออายุบนไคลเอนต์ทดสอบแทนที่จะสันนิษฐานว่ามันแพร่กระจายไปแล้ว

IPv6 คือครึ่งที่ถูกลืม การประกาศของเราเตอร์อาจพาเซิร์ฟเวอร์ DNS ของตัวเองมา (RDNSS) และบน OpenWrt นั่นคือตัวเลือก ra_dns ของ odhcpd ไคลเอนต์ที่ชอบ IPv6 จะใช้เซิร์ฟเวอร์นั้นขณะที่ตัวเลือก DHCPv4 ที่คุณเพิ่งตั้งไว้ไม่ถูกใช้ หากคุณยังไม่พร้อมให้บริการ DNS ผ่าน IPv6 ให้ล้างเฉพาะการประกาศ DNS คือ ra_dns ใน odhcpd หรือตัวเลือก RDNSS ในสิ่งที่ตอบการประกาศของเราเตอร์ การปิดการประกาศทั้งหมดยังถอดที่อยู่ IPv6 ออกจาก LAN ด้วย ซึ่งเป็นการเปลี่ยนแปลงที่ใหญ่กว่าที่คุณตั้งใจไว้มาก ขณะที่การล้างเฉพาะตัวเลือก 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 ด้วย pull-filter ignore “dhcp-option DNS” บน OpenVPN และไม่มีคำนำหน้า LAN ใน AllowedIPs บน WireGuard หรือยอมรับตัวแก้ชื่อที่ถูกดันและเลิกกรองในเครื่องสำหรับไคลเอนต์ที่อยู่หลังเราเตอร์นั้น ไม่ว่าคุณจะเลือกอะไร ให้เขียนไว้ข้างโปรไฟล์ เพราะคนถัดไปที่แก้ไขจะกลับการตัดสินใจนั้นโดยไม่ตั้งใจ

5. ทำการทดสอบซ้ำหลังเชื่อมต่อใหม่

สอบถามจากไคลเอนต์ ยืนยันว่าไคลเอนต์นั้นปรากฏในบันทึกของ Pi-hole จากนั้นแก้ชื่อโดเมนที่ควรถูกบล็อกและตรวจสอบว่าคุณได้คำตอบแบบบล็อกแทนคำตอบจริง เชื่อมต่ออุโมงค์ใหม่และรันสองคำค้นเดิม เพราะการตั้งค่าตัวแก้ชื่อที่อยู่ได้เพียงถึงการเชื่อมต่อครั้งถัดไปคือผลลัพธ์ปกติของการแก้ไขที่ใช้ในชั้นที่ผิด

เหลือเส้นทางตัวแก้ชื่อสำรองที่ไม่ขึ้นกับอุโมงค์ เพื่อให้การขัดข้องของ Pi-hole ลดลงเป็นการท่องเว็บแบบไม่กรองแทนที่จะไม่ท่องเว็บเลย เก็บค่าก่อนหน้าของ DHCP และตัวแก้ชื่อไว้จนกว่าการทดสอบจะผ่านสองครั้ง การเปลี่ยนแปลงที่ทำให้อินเทอร์เน็ตของบ้านล่มตอนมื้อเย็นนั้นดีบักยากกว่าการเปลี่ยนแปลงที่คุณย้อนกลับได้ในหนึ่งนาทีมาก