DNS แบบแยกส่วนผ่าน OpenVPN: โดเมนเส้นทางต้องทำอะไรบนแต่ละระบบปฏิบัติการ

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

ตั้งชื่อนโยบายก่อน แล้วจึงเลือกพื้นฐานของแพลตฟอร์มที่แสดงนโยบายนั้น

การตั้งค่าสามอย่างที่สับสนได้ง่าย

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

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

Linux: โดเมนสำหรับเส้นทางเท่านั้น ไม่ใช่คำต่อท้ายการค้นหา

บน systemd-resolved โดเมนที่ขึ้นต้นด้วยทิลดาเป็นโดเมนสำหรับเส้นทางเท่านั้น ซึ่งหมายความว่าคำถามสำหรับเนมสเปซนั้นไปยังรีโซลเวอร์ที่เชื่อมโยงอยู่ โดยไม่กลายเป็นคำต่อท้ายการค้นหาด้วย resolvectl domain tun0 '~corp.example' ตั้งค่านั้น และ resolvectl dns tun0 10.8.0.1 ระบุชื่อเซิร์ฟเวอร์ ทั้งสองการตั้งค่าเป็นของอินเทอร์เฟซ จึงหายไปพร้อมกับมัน ทิลดาคือส่วนที่คนมักละไว้ และหากไม่มีมัน ชื่อสั้นจะเริ่มถูกแก้ผ่านรีโซลเวอร์ของที่ทำงาน

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

Windows ต้องการนโยบายเนมสเปซ ไม่ใช่คำต่อท้าย

Windows เก็บนโยบาย DNS แบบแยกส่วนไว้ในตารางนโยบายการแปลงชื่อ ไม่ใช่ในคำต่อท้าย DNS ของอะแดปเตอร์ กฎหนึ่งข้อจับคู่เนมสเปซกับเซิร์ฟเวอร์ที่ระบุ: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. การตั้งคำต่อท้ายเพียงอย่างเดียวเปลี่ยนรูปร่างของชื่อสั้น แต่ไม่ได้ส่งคำถามไปยังเซิร์ฟเวอร์อื่น

ตรวจสอบนโยบายที่ใช้จริงด้วย Get-DnsClientNrptPolicy หลังเชื่อมต่อ เพราะกฎจากการเชื่อมต่อครั้งก่อนอาจอยู่ยาวกว่าทันเนล ลบกฎตามชื่อเมื่อทันเนลล่ม และรักษาชื่อที่แสดงให้คงที่เพื่อให้การล้างข้อมูลตรงรายการที่ถูกต้อง

ให้มีเจ้าของรีโซลเวอร์เพียงรายเดียวต่อแพลตฟอร์ม

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

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

ตรวจผลลัพธ์ ไม่ใช่ข้อความในโปรไฟล์

แก้ชื่อหนึ่งชื่อที่ควรผ่านทันเนลและอีกชื่อที่ไม่ควร บนแต่ละแพลตฟอร์ม และยืนยันว่าเซิร์ฟเวอร์ใดตอบ resolvectl query host.corp.example และ Resolve-DnsName host.corp.example ต่างรายงานเซิร์ฟเวอร์ที่ตอบกลับ ทำซ้ำหลังเชื่อมต่อใหม่ จากนั้นยืนยันว่ารีโซลเวอร์ของทันเนลเข้าถึงได้ที่แอดเดรสที่โปรไฟล์ส่งมา เพราะนโยบายที่ถูกต้องแต่ชี้ไปยังเซิร์ฟเวอร์ที่เข้าถึงไม่ได้ก็ล้มเหลวเหมือนไม่มีนโยบายเลย

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