ชี้ไคลเอนต์ OpenVPN ไปยังตัวแก้ไข Pi-hole บนโฮสต์อื่น

การใส่ที่อยู่ Pi-hole ลงในโปรไฟล์ OpenVPN ไม่ได้สร้างเส้นทางไปถึงมัน ไม่ได้ให้สิทธิ์ในการสอบถาม และไม่ได้รับประกันว่าไคลเอนต์จะใช้งานมัน เมื่อ 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 ตารางเส้นทางของมันเองอาจไม่รู้อะไรเกี่ยวกับพูลนี้ คำตอบจึงไปยังเกตเวย์เริ่มต้นและหายไป บันทึกการสอบถามแสดงคำขอที่ไม่มีการตอบกลับที่ตรงกัน ซึ่งตีความเป็นปัญหาของไฟร์วอลล์ได้ง่าย

กำหนดเส้นทางแบบคงที่สำหรับพูลให้เราเตอร์ 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 ด้วยเป็นปัญหาอื่นที่รอเกิดขึ้น