DNS ของ VPN รับทุกการค้นหา: แก้ dns-priority ใน NetworkManager

เชื่อมต่อ VPN ของออฟฟิศ แล้วทันใดนั้นการค้นหาชื่อทุกครั้งก็ไปยังรีโซลเวอร์ขององค์กร ชื่อสาธารณะยังคงแก้ได้ จึงไม่มีอะไรดูเสียหายจนกว่าชื่อเครื่องพิมพ์ในเครื่องจะล้มเหลว หรือระเบียน split-horizon จะคืนที่อยู่ของออฟฟิศ ในการตั้งค่า Fedora บางแบบเกิดตรงกันข้าม: รีโซลเวอร์ของผู้ให้บริการยังตอบต่อไปแม้ทันเนลจะขึ้นแล้ว ทั้งสองเป็นคำถามเดียวกัน — รีโซลเวอร์ใดเป็นเจ้าของคำค้นนี้ — และในระบบ NetworkManager คำตอบอยู่ในพร็อพเพอร์ตี DNS ของแต่ละการเชื่อมต่อ

สองการเชื่อมต่อ หนึ่งรีโซลเวอร์ที่ชนะ

แต่ละการเชื่อมต่อประกาศลำดับความสำคัญ DNS การเชื่อมต่อทั่วไปมีค่าเริ่มต้น 50 และการเชื่อมต่อ VPN มีค่า 0 และค่าที่ต่ำกว่าชนะ ค่าเริ่มต้นนั้นเองคือเหตุผลที่การเชื่อมต่อ VPN แซงการเชื่อมต่อแบบสายอย่างเงียบ ๆ สำหรับทุกโดเมนที่อ้างสิทธิ์ ศูนย์ชนะห้าสิบโดยไม่มีใครเลือก

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

ลำดับความสำคัญกำหนดลำดับ รายการค้นหากำหนดความเป็นเจ้าของ

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

รายการค้นหาคือคำประกาศความเป็นเจ้าของ โดเมนเปล่าเช่น corp.example กลายเป็นส่วนต่อท้ายการค้นหาและโดเมนเส้นทาง รูปแบบเฉพาะเส้นทาง ~corp.example ส่งการค้นหาใต้ส่วนต่อท้ายนั้นไปยังการเชื่อมต่อนี้โดยไม่ต่อโดเมนเข้ากับชื่อสั้น ตัวทิลดานั้นคือความต่างระหว่าง «ถามเซิร์ฟเวอร์นี้» กับ «ถามเซิร์ฟเวอร์นี้แล้วพิมพ์ต่อให้ฉัน»

ใช้ทั้งสองรูปแบบเมื่อผู้ใช้พิมพ์ชื่อโฮสต์สั้นและระเบียนถูกระบุที่อยู่ด้วยชื่อเต็มที่ผ่านการรับรองด้วย ใช้เฉพาะรูปแบบเส้นทางเมื่อต้องการแยกโดยไม่เปลี่ยนวิธีที่รีโซลเวอร์เติมชื่อเปล่าให้สมบูรณ์

จากนั้นทำให้การเลือกชัดเจนและเปิดใช้งานใหม่:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

ลำดับความสำคัญติดลบคือวิธีที่เอกสารระบุไว้สำหรับการบอกว่า «ให้ความสำคัญกับการเชื่อมต่อนี้» และการตั้งค่าทั้งสองตระกูลที่อยู่ทำให้พฤติกรรมสอดคล้องกันบนโฮสต์ที่มีการเชื่อมต่อ IPv6 การเปลี่ยนพร็อพเพอร์ตีโดยไม่เปิดใช้งานการเชื่อมต่อใหม่ไม่เปลี่ยนสิ่งที่กำลังทำงานอยู่ จึงจบลำดับด้วยคำสั่ง up ที่ชัดเจน

ให้ systemd-resolved เป็นผู้ถือการแยกส่วน

ปลั๊กอิน dnsmasq ค่าเริ่มต้นรวบคำค้นไว้ในรีโซลเวอร์ภายในเครื่องเดียว การแยกตามลิงก์จึงยังหยาบ systemd-resolved เปิดเผยการแยกตามลิงก์ และ resolvectl query ระบุชื่อลิงก์ที่ตอบ

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

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

ปรับดีไซน์ DNS ให้เข้ากับชนิดของทันเนล

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

จากนั้นมี kill switch ที่บล็อก DNS นอกทันเนล ชื่อต่าง ๆ แก้ได้สำหรับโซนของทันเนลและล้มเหลวทุกที่อื่นในขณะที่การเชื่อมต่อสมบูรณ์ดี คำตอบที่ใช้ได้คือการอนุญาตอย่างชัดเจนสำหรับรีโซลเวอร์ใน LAN หรือแคชภายในที่ส่งต่อเฉพาะโซนองค์กร และทั้งสองเป็นข้อยกเว้นที่มีเจ้าของ ไม่ใช่ข้อบกพร่องในทันเนล

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

ตรวจสอบทีละลิงก์ แล้วตรวจอีกครั้งหลังเชื่อมต่อใหม่

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

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