AdGuard Home ตอบคำถามลูกค้า WireGuard จากที่อยู่ LAN ของคุณ

อุโมงค์ทำงานแล้ว ไฟร์วอลล์อนุญาตพอร์ต 53 AdGuard Home กำลังทำงานอยู่ แต่ชื่อยังไม่สามารถแก้ไขได้สำหรับไคลเอนต์ WireGuard การสอบถามมักจะมาถึงและคำตอบมักจะออกไป ดังนั้นตัวนับแพ็กเก็ตบนตัวแก้ไข DNS ดูเหมือนปกติและบริการดูเหมือนไร้เดียงสา สิ่งที่ผิดพลาดคือที่อยู่ต้นทางในคำตอบนั้น: มันออกจากที่อยู่ในเครื่องที่ไคลเอนต์ไม่เคยถาม และตัวแก้ไขแบบสตับของไคลเอนต์ก็ทิ้งมัน รายการหนึ่งในการตั้งค่า AdGuard Home ตัดสินใจเรื่องนี้ และค่าเริ่มต้นทั่วไปมอบการตัดสินใจให้เคอร์เนล

การสอบถามมาถึง คำตอบออกไปจากที่อื่น

ลูกค้าที่ตั้งค่า 10.6.0.1 เป็นตัวแก้ไขของมันส่งคำถาม UDP ไปยังพอร์ต 53 ของ 10.6.0.1 แพ็กเกจนั้นข้ามอุโมงค์และไปถึงโฮสต์ และ AdGuard Home ตอบกลับมัน แต่บนสายการสื่อสาร การตอบกลับเป็นแพ็กเกจใหม่ที่ที่อยู่ต้นทางถูกเลือกโดยสแต็คของโฮสต์ ไม่ใช่โดยความคาดหวังของลูกค้า

เมื่อ resolver ของลูกค้าเป็นซ็อกเก็ตที่เชื่อมต่อ ซึ่งเป็นสิ่งที่ systemd-resolved, dnsmasq และ resolver แบบ stub ส่วนใหญ่ใช้ มันยอมรับเฉพาะคำตอบจากที่อยู่ตรงที่มันส่งไปเท่านั้น คำตอบที่มีแหล่งที่มาจาก 192.168.1.10 สำหรับคำถามที่ส่งไปยัง 10.6.0.1 จะถูกทิ้งก่อนที่จะมีการวิเคราะห์ใด ๆ resolver บันทึกคำตอบที่สำเร็จ ลูกค้าบันทึกการหมดเวลา และทั้งสองฝ่ายต่างพูดความจริง

ดังนั้นตัวนับไม่ได้โกหก และลูกค้าก็ไม่ได้โกหกเช่นกัน หลักฐานที่คุณต้องการอยู่ในสามที่ ตามลำดับนี้: ที่อยู่ที่ผู้ฟังถูกผูกไว้, เส้นทางที่เคอร์เนลใช้กลับไปยังลูกค้า, และที่อยู่ต้นทางบนแพ็กเก็ตตอบกลับจริง

วิธีที่เคอร์เนลเลือกแหล่งที่มาของการตอบกลับ

ซ็อกเก็ต UDP ที่ถูกผูกไว้กับ0.0.0.0ไม่มีที่อยู่ต้นทางของตัวเอง ดังนั้นแต่ละการตอบกลับที่ส่งออกจะกระตุ้นการค้นหาเส้นทางไปยังปลายทาง เคอร์เนลจะใช้ที่อยู่จากเส้นทางนั้น: ที่อยู่ที่ถูกกำหนดโดยเส้นทาง หรือที่อยู่หลักของอินเทอร์เฟซที่ส่งออก ไม่มีสิ่งใดเกี่ยวกับที่อยู่ปลายทางของคำขอที่ถูกจดจำ

บนโฮสต์ที่มีโฮมเดียว สิ่งนี้จะมองไม่เห็น เพราะมีคำตอบที่เป็นไปได้เพียงคำตอบเดียว บนเครื่องที่ถือที่อยู่ LAN ที่อยู่ WireGuard และที่อยู่การจัดการ หลายคำตอบเป็นไปได้ และผู้ชนะขึ้นอยู่กับตารางการกำหนดเส้นทางในขณะนั้น เพิ่มเส้นทางเพิ่มเติม ที่อยู่ที่สองบนอินเทอร์เฟซเดียวกัน การเปลี่ยนเส้นทาง NAT ก่อนตัวแก้ไข หรือรัน AdGuard ในคอนเทนเนอร์พร้อมเนมสเปซของตัวเอง และแหล่งที่ถูกเลือกอาจแตกต่างจากที่ไคลเอนต์สอบถาม

ss -lunp | grep :53แสดงว่าคุณอยู่ในเกมใด ผู้รับฟังบน0.0.0.0:53เป็นกรณีไวด์การ์ด; ผู้รับฟังบน10.6.0.1:53ได้กำหนดคำตอบแล้ว การอ่านซ็อกเก็ตเร็วกว่าการอ่าน YAML และสะท้อนสิ่งที่กำลังทำงานอยู่จริงมากกว่าสิ่งที่บันทึกล่าสุด

สิ่งที่ bind_hosts ควบคุมจริง ๆ

AdGuard Homedns.bind_hostsคือรายการที่อยู่ภายในเครื่องที่ตัวฟัง DNS ใช้ ค่าตั้งต้นที่ติดมาพร้อมตัวโปรแกรมคือเครื่องหมาย * ซึ่งหมายถึงยอมรับทุกที่อยู่ภายในเครื่องและให้เคอร์เนลเลือกที่อยู่ต้นทางตามการตอบกลับ การแทนที่เครื่องหมาย * ด้วยที่อยู่ที่ลูกค้าสอบถามนั้นจะเปลี่ยนซ็อกเก็ต และด้วยมันที่อยู่ต้นทางในทุกคำตอบจะเปลี่ยนไป

รายการนี้สามารถมีหลายรายการได้ ซึ่งมีความสำคัญสำหรับตัวแก้ปัญหาที่ให้บริการสองเครือข่าย การระบุ10.6.0.1และ192.168.1.10จะสร้างซ็อกเก็ตสองตัวที่ผูกอยู่ และคำถามที่มาในแต่ละซ็อกเก็ตจะได้รับคำตอบจากที่อยู่ที่มันเข้ามา นั่นคือพฤติกรรมที่คนส่วนใหญ่สมมติว่าเครื่องหมาย * ให้ไว้แล้ว

ไฟล์ YAML เป็นแบบเรียบง่าย และที่อยู่ในนั้นคือที่อยู่ที่ลูกค้าอุโมงค์ของคุณได้รับแจ้งให้ใช้ ไม่ใช่ที่อยู่หลักของโฮสต์:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

ทำไมการติดตั้งตัวแก้ปัญหาหนึ่งถึงมีความเห็นต่างกันสองครั้ง

การจัดการโดยปลั๊กอิน ในบริบทนี้ หมายความว่าตัวแก้ไขถูกติดตั้งและถูกควบคุมโดยแพ็กเกจอื่น: แพ็กเกจเฟิร์มแวร์เราเตอร์ แพ็กเกจ NAS หรือส่วนเสริมระบบอัตโนมัติภายในบ้าน แพ็กเกจนั้นมักจะมาพร้อมกับสำเนาไฟล์ YAML ของ AdGuard Home ของตัวเองและรีสตาร์ทกระบวนการตามตารางของมันเอง ในขณะที่อินสแตนซ์แบบสแตนด์อโลนอาจเป็นไบนารีของผู้ขายหรือคอนเทนเนอร์ที่คุณกำหนดค่าเอง ไม่ว่าจะเป็นวิธีใด คุณกำลังดูสองกระบวนการที่เป็นอิสระซึ่งมีไฟล์กำหนดค่าที่แยกกันและตัวเลือกการผูกที่แยกกัน แม้ว่าทั้งคู่จะอ่านรายการต้นน้ำเดียวกันและรายการตัวกรองเดียวกัน หนึ่งสามารถผูกที่อยู่ท่อเฉพาะได้ ในขณะที่อีกตัวสืบทอดสัญลักษณ์ตัวแทน และส่วนติดต่อเว็บดูเหมือนกันทั้งสองด้าน

นั่นคือเหตุผลที่ว่า "การแก้ปัญหาเดียวกันใช้งานได้ก่อนการย้ายระบบ" ไม่ได้พิสูจน์อะไรเกี่ยวกับการเชื่อมโยงปัจจุบัน ตรวจสอบซ็อกเก็ต จากนั้นตรวจสอบไฟล์การกำหนดค่าที่โปรเซสที่กำลังทำงานโหลดจริง ๆ สำเนาเก่าในไดเรกทอรีอื่นเป็นเหตุผลที่พบบ่อยที่ทำให้การแก้ไขดูเหมือนไม่มีผล

ปักหมุดไว้ จากนั้นทดสอบจากฝั่งท่อ

เปลี่ยนbind_hostsเป็นที่อยู่ของท่อ รีสตาร์ทบริการ และยืนยันว่าซ็อกเก็ตย้ายแล้ว:ss -lunp | grep :53ตอนนี้ควรจะแสดง10.6.0.1:53และไม่มีรายการ wildcard หากยังคงแสดง0.0.0.0,โปรเซสที่กำลังทำงานไม่ได้อ่านไฟล์ที่คุณแก้ไข.

จากนั้นทดสอบจากฝั่งลูกค้า เพราะนั่นคือฝั่งเดียวที่สำคัญ การสอบถามด้วยdig @10.6.0.1 example.comจะใช้เส้นทางที่ผู้ใช้ใช้งาน และการจับข้อมูลบนโฮสต์ด้วยtcpdump -ni wg0 udp port 53แสดงที่อยู่ต้นทางของคำตอบบนสาย เปรียบเทียบกับที่อยู่ในการตั้งค่า resolver ของไคลเอนต์; เมื่อพวกมันเท่ากัน เวลาในการหมดเขตจะไม่เป็นปริศนาอีกต่อไป

ip route get 10.6.0.2อธิบายความผิดปกติที่เหลืออยู่ เพราะมันพิมพ์อินเทอร์เฟซและต้นทางที่โฮสต์จะใช้ส่งกลับไปยังไคลเอนต์ หากผลลัพธ์นั้นระบุชื่ออินเทอร์เฟซ LAN การเปลี่ยน bind ไม่ใช่การแก้ไขทั้งหมด และตารางการกำหนดเส้นทางคือสิ่งต่อไปที่ต้องอ่าน

สิ่งที่การตั้งค่า bind ไม่สามารถแก้ไขได้

การปักหมุด listener ไม่สามารถซ่อมแซมรายการการเข้าถึงที่ละเว้นซับเน็ตของท่อ, กฎไฟร์วอลล์ที่อนุญาตให้มีการสอบถามแต่ไม่ยอมให้มีคำตอบ, หรือเส้นทางที่ขาดหายไปกลับไปยังพูล WireGuard เหล่านั้นล้มเหลวก่อนหรือหลังที่อยู่ต้นทาง และแต่ละรายการมีเจ้าของแตกต่างกัน

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