ลิงก์ใดตอบ: โดเมนเส้นทางสำหรับ DNS ของ VPN แบบแยกอุโมงค์

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

ขั้นแรก: แยกเส้นทางออกจากตัวแปลงชื่อ

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

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

ขั้นที่สอง: เพิ่มโดเมนเฉพาะเส้นทางลงในโปรไฟล์

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

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

ตัวหนอนนำหน้าหมายถึงโดเมนเฉพาะเส้นทาง คำถามที่ตรงกันจึงไปยังเซิร์ฟเวอร์ของลิงก์นี้และส่วนต่อท้ายไม่ถูกเติมให้ชื่อสั้น เอาตัวหนอนออกแล้วสตริงเดียวกันก็กลายเป็นส่วนต่อท้ายการค้นหาด้วย ซึ่งเป็นผลลัพธ์อีกแบบที่คนไม่ค่อยตั้งใจ การตั้งค่าทั้งสองข้างบนเป็น IPv4 โปรไฟล์แบบสองสแตกจึงต้องมี ipv6.never-default และโดเมนเส้นทางเดียวกันใน ipv6.dns-search มิฉะนั้นฝั่ง IPv6 จะยังใช้เส้นทางเริ่มต้นและชื่อภายในล้มเหลวที่นั่น

ขั้นที่สาม: ถาม resolvectl ว่าลิงก์ใดตอบ

เรียกใช้ resolvectl status และอ่านเซิร์ฟเวอร์ DNS กับโดเมนของแต่ละลิงก์ จากนั้นเรียกใช้ resolvectl query host.internal.example กับชื่อภายในจริงที่คุณได้รับอนุญาตให้ถาม คำสั่งที่สองเป็นหลักฐานโดยตรงเพียงอย่างเดียวว่าโดเมนเส้นทางทำงานของมัน เพราะ มันระบุชื่อลิงก์ที่ตอบ รายการสถานะอย่างเดียวพิสูจน์การตั้งค่า คำถามพิสูจน์การแปลงชื่อ

systemd-resolved เลือกโดเมนเส้นทางที่ตรงที่สุด ดังนั้นโดเมนที่เฉพาะเจาะจงกว่าบนลิงก์อื่นยังชนะการแข่งขันได้ ถ้าคำถามกลับมาจากลิงก์ที่คุณไม่ได้คาดไว้ ให้อ่านรายการโดเมนก่อนแตะเซิร์ฟเวอร์ DNS ของ VPN โดเมนราก ~. ตรงกับทุกสิ่ง และถ้ามีอยู่แล้ว โดเมนเฉพาะของคุณยังชนะสำหรับชื่อของมันเอง ขณะที่ลิงก์ตอบมากกว่าที่คุณขอมาก ลบหรือแคบรายการรากนั้นเมื่อเจตนาคือชื่อของบริษัทเท่านั้น

ถ้าลิงก์ VPN ไม่ระบุเซิร์ฟเวอร์ DNS เลย ไคลเอนต์ไม่เคยลงทะเบียนสักตัว โดเมนเส้นทางที่ไม่มีเซิร์ฟเวอร์อยู่ข้างหลังล้มเหลวต่างจากโดเมนที่หายไป ดังนั้นแก้การลงทะเบียนก่อน

ขั้นที่สี่: เมื่อชื่อแปลงได้แต่บริการไม่

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

การเปลี่ยนแปลงใน Samba ที่หมุนเวียนข้างคำถามนี้เกี่ยวกับชั้นการเข้าถึง ไม่ใช่การเลือก DNS การนำไปใช้กับความล้มเหลวในการแปลงชื่อคือวิธีที่ปัญหาเล็กได้ปัญหาที่สอง

ขั้นที่ห้า: อย่าเปลี่ยนตัวแปลงชื่อเพื่อซ่อมโดเมนที่หายไป

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

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