เมื่ออุโมงค์เชื่อมต่อแล้ว ขั้นตอนสุดท้ายมักเป็นชื่อที่ใช้งานได้แทนที่อยู่ที่คุณวางในบุ๊กมาร์ก บันทึกโฮสต์ของ dnsmasq บวกที่อยู่ resolver ที่ไคลเอนต์เข้าถึงได้ทำสิ่งนั้นด้วยสองไฟล์และไม่ต้องใช้ multicast การตัดสินใจที่ต้องคิดจริงนั้นแคบกว่า: ไคลเอนต์จะส่ง DNS ทั้งหมดผ่าน resolver ที่บ้าน หรือเฉพาะชื่อภายใต้ home.arpa เท่านั้น ทุกอย่างด้านล่างถือว่ามีการตั้งค่า WireGuard ที่ได้รับอนุมัติพร้อมไคลเอนต์ Linux และ resolver ในห้องแล็บที่ผู้ดูแลบ้านจัดการอยู่แล้ว

สามวิธีในการมอบ resolver ให้ไคลเอนต์

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

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

เผยแพร่บันทึกที่ resolver ซึ่งเป็นเจ้าของโซน

แยกบทบาทให้ชัดก่อนเขียนการกำหนดค่า: ที่อยู่ไคลเอนต์ VPN, resolver และบริการเป็น สามโฮสต์ที่แตกต่างกันพร้อมสามหน้าที่ต่างกัน ในห้องแล็บนี้คือ 10.77.0.2 สำหรับไคลเอนต์ 192.168.50.53 สำหรับ dnsmasq และ 192.168.50.20 สำหรับ NAS โดยอุโมงค์เป็นตัวกำหนดเส้นทาง LAN ที่บ้าน

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

บรรทัด host-record ให้ที่อยู่ และบรรทัด local= เก็บคำถาม home.arpa ที่ไม่รู้จักไว้ใน resolver นี้แทนที่จะส่งต่อไปยังต้นทาง ให้อ่านการกำหนดค่าที่มีอยู่ก่อนและปรับให้สอดคล้องกับทุกสิ่งที่กำหนดเซิร์ฟเวอร์ อินเทอร์เฟซ หรือโดเมนภายในเดียวกันอยู่แล้ว การวางส่วนเพิ่มทับส่วนที่ขัดแย้งกันจะได้ resolver ที่โหลดได้อย่างราบรื่นแต่ตอบผิด คู่มือ dnsmasq กำหนดไดเรกทีฟทั้งสองและการควบคุมการรับฟัง

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

กำหนดเส้นทาง resolver ไม่ใช่แค่หน้าเว็บ

AllowedIPs ของ WireGuard ตัดสินใจว่าปลายทางใดเข้าสู่อุโมงค์ หากที่อยู่ resolver อยู่นอกเหนือจากนั้น แบบสอบถามจะออกผ่านเส้นทางปกติและไม่ถึง dnsmasq เลย แม้ตัว NAS จะเข้าถึงได้ก็ตาม ให้รวมที่อยู่ของ resolver หรือคำนำหน้า LAN ที่มีที่อยู่นั้น และตรวจสอบนโยบายการส่งต่อของเกตเวย์อีกฝั่งหนึ่ง

อนุญาต UDP และ TCP บนพอร์ต 53 จากช่วงอุโมงค์ที่ได้รับอนุญาต พร้อมเส้นทางกลับไปยังที่อยู่อุโมงค์ของไคลเอนต์ อย่าส่งต่อพอร์ต 53 จาก WAN เพื่อให้ทดสอบง่ายขึ้น เพราะ resolver แบบเรียกซ้ำที่เปิดอยู่บนการเชื่อมต่อที่บ้านจะถูกพบภายในไม่กี่ชั่วโมง การผูกกับอินเทอร์เฟซไม่ใช่นโยบายการเข้าถึงในตัวเอง

ตรวจสอบคำตอบก่อนแอปพลิเคชัน

ถาม resolver โดยตรงก่อน จากนั้นถามระบบ จากนั้นถามแอปพลิเคชัน แต่ละขั้นตอนแยกข้อต่อหนึ่งข้อในห่วงโซ่ และความแตกต่างระหว่างกันคือการวินิจฉัย

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

ควรเรียกใช้แบบสอบถาม TCP เพราะคำตอบ UDP ที่ถูกตัดทอนบังคับให้ลองใหม่ และนโยบายที่ทิ้ง TCP 53 ทำให้เกิดความล้มเหลวที่ดูเหมือนเกิดขึ้นเป็นครั้งคราว ขั้นตอน getent แสดงให้เห็นว่าการกำหนดค่า resolver ของเครื่องทำอะไรจริง ซึ่งไม่ใช่สิ่งที่คุณส่งออกไปเสมอ

ตัดสินใจว่าเกิดอะไรขึ้นเมื่ออุโมงค์ล่ม

หาก DNS ทั่วไปของไคลเอนต์ชี้ไปที่ 192.168.50.53 การแปลงชื่อทั้งหมดจะหยุดทำงานเมื่ออุโมงค์ไม่ได้เชื่อมต่อ สิ่งนี้ยอมรับได้บนเครื่องที่มีประโยชน์เฉพาะเมื่อมีอุโมงค์ และยอมรับไม่ได้บนแล็ปท็อปที่ใช้ Wi-Fi ของร้านกาแฟด้วย split-DNS เลี่ยงคำถามนี้ทั้งหมด เพราะเฉพาะการค้นหา home.arpa เท่านั้นที่พึ่งพา resolver ที่บ้าน

จำไว้ว่าชื่อนี้คืออะไร: home.arpa สงวนไว้สำหรับเครือข่ายที่อยู่อาศัยและไม่ซ้ำกันทั่วโลก เครือข่ายอื่นจึงใช้ชื่อเดียวกันได้อย่างชอบธรรม มันเป็นความสะดวกในท้องถิ่น ไม่ใช่ตัวระบุที่เชื่อถือได้ อัปเดตบันทึกเมื่อบริการย้ายที่ และลบนโยบาย resolver เมื่อเลิกใช้ห้องแล็บ แทนที่จะทิ้งแล็ปท็อปที่ชี้ไปยังที่อยู่ซึ่งเข้าถึงได้เฉพาะผ่านอุโมงค์ที่ไม่มีอยู่อีกต่อไป

บทความที่เกี่ยวข้อง