ทำไม Pi-hole v6 จึงเพิกเฉยต่อคำถาม DNS จากไคลเอนต์ WireGuard

Pi-hole v6 รับคำถาม DNS บนพอร์ต 53 แล้วตัดสินว่าแพ็กเก็ตที่มาถึงได้รับอนุญาตให้ตอบหรือไม่ บนโฮสต์ WireGuard การตัดสินครั้งที่สองนี้มักเป็นสาเหตุที่ไคลเอนต์หมดเวลา ขณะที่ตัวแก้ชื่อดูปกติจาก LAN พอร์ตเปิดอยู่ FTL ทำงานอยู่ แต่ก็ไม่มีอะไรส่งกลับมาจาก 10.90.0.1 มีสามสิ่งทำงานร่วมกันก่อนคำตอบจะออกไป: dns.interface, dns.listeningMode และไฟร์วอลล์ที่อยู่หน้าทั้งสอง

ซ็อกเก็ตที่ฟังอยู่ไม่ได้ตัดสินว่าใครจะได้รับคำตอบ

FTL เปิดตัวฟัง UDP และ TCP บนพอร์ต 53 ในการกำหนดค่าเริ่มต้น ซ็อกเก็ตมักเป็น wildcard ดังนั้น ss -lunp | grep :53 จะแสดง 0.0.0.0:53 และ [::]:53 ไม่ว่าจะให้บริการไคลเอนต์ VPN หรือไม่ก็ตาม ซ็อกเก็ต wildcard ยอมรับแพ็กเก็ต แล้ว FTL จึงใช้กฎอินเทอร์เฟซและแหล่งที่มาของตนก่อนตอบ นี่คือเหตุผลที่คำว่า "พอร์ตกำลังฟังอยู่" พิสูจน์เรื่องไคลเอนต์อุโมงค์ได้น้อยมาก

อ่านการกำหนดค่าที่กำลังทำงาน ไม่ใช่ไฟล์ที่คุณคิดว่าใช้งานอยู่ pihole-FTL --config dns.interface และ pihole-FTL --config dns.listeningMode พิมพ์ค่าที่มีผลจริง และค่าเหล่านี้อาจต่างจากไฟล์ของโฮสต์เมื่อคอนเทนเนอร์ ตัวแปรสภาพแวดล้อม หรือตัวจัดการการปรับใช้เป็นเจ้าของการตั้งค่านั้น เอกสารอ้างอิงการกำหนดค่า Pi-hole FTL แสดงรายการโหมดและโหมดใดที่อิงกับอินเทอร์เฟซ

LOCAL ถามว่าซับเน็ตใด SINGLE ถามว่าอินเทอร์เฟซใด

LOCAL ซึ่งเป็นค่าเริ่มต้น ตอบคำถามที่ที่อยู่ต้นทางอยู่ในซับเน็ตที่กำหนดค่าไว้บนอินเทอร์เฟซใดอินเทอร์เฟซหนึ่งของโฮสต์ wg0 ธรรมดาที่มี 10.90.0.1/24 ผ่านการทดสอบนี้ เพราะไคลเอนต์ที่ 10.90.0.2 อยู่ภายในซับเน็ตของอุโมงค์ ไคลเอนต์ที่ถูกกำหนดเส้นทางอยู่อีกด้านของพีร์ หรือไคลเอนต์ที่ซ่อนอยู่หลัง NAT ในคำนำหน้าอื่น จะไม่ผ่าน แม้แพ็กเก็ตจะมาถึง wg0 และไม่มีคำถามใดปรากฏในบันทึก

SINGLE เปลี่ยนคำถาม มันยอมรับคำถามที่มาถึงอินเทอร์เฟซที่ระบุไว้ใน dns.interface รวมถึง loopback และเพิกเฉยต่อซับเน็ตต้นทาง นี่คือโหมดที่อยู่รอดในโครงสร้าง VPN แบบต่อเนื่องหรือแบบกำหนดเส้นทาง ตั้งค่าทั้งสองคีย์พร้อมกัน เพราะโหมดที่ไม่มีอินเทอร์เฟซระบุไม่ใช่คำสั่งที่สมบูรณ์:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND เปลี่ยนซ็อกเก็ต และนั่นมีค่าใช้จ่าย

BIND ไม่กรองซ็อกเก็ต wildcard มันผูกพอร์ต 53 กับที่อยู่ที่มีอยู่บนอินเทอร์เฟซที่ระบุเท่านั้น เคอร์เนลจึงปฏิเสธแพ็กเก็ตที่มาจากที่อื่น มันเข้มงวดกว่า SINGLE และไม่ใช่คำพ้องของกัน ค่าใช้จ่ายปรากฏตอนบูต หาก wg0 ไม่ได้ขึ้นเมื่อ FTL เริ่ม อาจไม่มีที่อยู่ให้ผูก และตัวแก้ชื่ออาจทำงานโดยไม่มีตัวฟังจนกว่าอินเทอร์เฟซจะปรากฏและ FTL เริ่มใหม่

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

ไฟร์วอลล์คือประตูที่สอง

โหมด FTL ที่ถูกต้องก็ยังล้มเหลวหากไฟร์วอลล์ของโฮสต์ทิ้งพอร์ต 53 บน wg0 อนุญาตช่วงต้นทางของ VPN สำหรับทั้งสองโปรโตคอลและปิดฝั่งอินเทอร์เน็ตไว้ ใน nftables ด้วยเชน input ที่มีอยู่ในตาราง inet filter กฎจะมีลักษณะดังนี้:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

เพิ่มกฎ IPv6 ที่ตรงกันหากอุโมงค์พา IPv6 และวางไว้ก่อนนโยบาย drop ของเชน หากโฮสต์ใช้ ufw หรือ firewalld ให้แสดงการจับคู่เดียวกันในตัวจัดการนั้นแทนการผสมเครื่องมือ อย่าส่งต่อพอร์ต 53 จากเราเตอร์อินเทอร์เน็ต ไคลเอนต์ควรเข้าถึงที่อยู่ VPN ของตัวแก้ชื่อผ่านอุโมงค์

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

ตรวจสอบคำตอบและการปฏิเสธ

จากไคลเอนต์ VPN ให้ถามที่อยู่ของตัวแก้ชื่อผ่านทั้งสองโปรโตคอล: dig @10.90.0.1 example.com และ dig +tcp @10.90.0.1 example.com จากนั้นตรวจดูบันทึกคำถามในอินเทอร์เฟซผู้ดูแลเพื่อยืนยันว่า FTL บันทึกคำถามแล้ว การที่ไคลเอนต์หมดเวลาโดยไม่มีรายการในบันทึกชี้ไปที่ไฟร์วอลล์หรือตัวกรองอินเทอร์เฟซ รายการในบันทึกที่ไม่มีคำตอบชี้ไปที่การแก้ชื่อขึ้นต้น

ทดสอบเส้นทางเชิงลบจากโฮสต์นอก VPN dig @10.90.0.1 example.com ควรหมดเวลา และ ss -lunp บนตัวแก้ชื่อไม่ควรแสดงพอร์ต 53 ผูกกับที่อยู่สาธารณะ รีสตาร์ตบริการหนึ่งครั้ง จากนั้นรีบูตโฮสต์และยืนยันว่าตัวแก้ชื้อยังตอบอยู่เมื่อ wg0 ปรากฏขึ้นอีกครั้ง คำถามที่ใช้ได้เพียงถึงการรีบูตครั้งถัดไปยังไม่ใช่การเปลี่ยนแปลงที่เสร็จสมบูรณ์