DNS แยกส่วนและ VPN: กฎโดเมนไม่ใช่เส้นทาง IP
DNS แยกส่วนเลือกตัวแก้ไขตามชื่อ และคำตอบยังต้องมีเส้นทาง ทดสอบกฎโดเมนและเส้นทางแยกกัน บนแพลตฟอร์มที่คุณใช้งานจริง
แล็ปท็อปของคุณแก้ไข intranet.corp ผ่านอุโมงค์ ขณะที่ gitlab.com ยังคงไปยังตัวแก้ไขของ ISP และนี่คือการจัดวางที่ทำงานตามที่ออกแบบไว้ การตัดสินใจสองอย่างที่แยกจากกันสร้างสิ่งนี้ขึ้นมา: กฎจับคู่ชื่อเลือกตัวแก้ไข และเส้นทางนำคำตอบกลับมา หักอย่างใดอย่างหนึ่งแล้วเบราว์เซอร์จะแสดงความล้มเหลวที่มองจากภายนอกดูเหมือนกัน รายงาน DNS แยกส่วนส่วนใหญ่บรรยายความล้มเหลวอย่างที่สองพร้อมอ้างหลักฐานเกี่ยวกับอย่างแรก
สองครึ่งอาศัยอยู่คนละที่และมักถูกแก้ไขโดยคนละคน อย่างหนึ่งคือนโยบาย DNS ที่ผูกกับโปรไฟล์ VPN อีกอย่างคือเส้นทางที่อุโมงค์ติดตั้งหรือกักไว้ การดีบักจะหยุดชะงักเมื่อไม่มีใครระบุว่าครึ่งไหนเคลื่อนจริง
สองการตัดสินใจที่ซ่อนอยู่ในคำขอเดียว
ครึ่งของชื่อเป็นอ็อบเจกต์นโยบาย ไม่ใช่เส้นทาง บน Windows เป็นนโยบายแก้ชื่อบนโปรไฟล์ VPN บนแพลตฟอร์ม Apple เป็นชุดโดเมนที่ตรงกันบนอ็อบเจกต์การตั้งค่า DNS บน Linux เป็นโดเมนเส้นทาง บรรทัดตัวแก้ไขแบบแยกส่วน หรือลำดับสวิตช์บริการชื่อ ครึ่งของเส้นทางคือการกำหนดเส้นทางธรรมดา ซึ่งติดตั้งโดยอุโมงค์หรือด้วยมือ และไม่รู้จักชื่อโฮสต์เลย โปรไฟล์ที่ยอมรับคำต่อท้ายเพียงตัดสินว่าใครตอบเท่านั้น ไม่เคยทำให้คำตอบเข้าถึงได้
การทดสอบอาการอย่างรวดเร็วแยกสองอย่างนี้ออก: แทนที่ชื่อด้วยที่อยู่ ถ้าที่อยู่ทำงาน เส้นทางก็ดีและกฎผิด ถ้าที่อยู่ล้มเหลวด้วย กฎอาจถูกและเส้นทางหายไป
แต่ละแพลตฟอร์มแสดงกฎชื่อเดียวกันอย่างไร
เจตนาเหมือนกันและชื่อฟิลด์ไม่เหมือนกัน ตัวอย่างที่คัดลอกจากไคลเอนต์หนึ่งไปยังอีกเครื่องหนึ่งแยกวิเคราะห์ได้สะอาดและไม่เคยตรงกัน สามรูปแบบมีลักษณะดังนี้
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
โดเมนจับคู่หรือเส้นทางคือการทดสอบคำต่อท้าย ดังนั้น intranet.corp ครอบคลุม git.intranet.corp และไม่ครอบคลุม corp.intranet และการกลับด้านคือข้อผิดพลาดที่พบบ่อยที่สุดในการตั้งค่าทั้งหมด Windows พาแมปปิ้งเป็นนโยบายแก้ชื่อที่ผูกกับโปรไฟล์ พร้อมลำดับความสำคัญของตัวเองเทียบกับรายการคำต่อท้ายใด ๆ ที่อินเทอร์เฟซมีอยู่แล้ว แพลตฟอร์ม Apple ผูกโดเมนที่ตรงกันเข้ากับอ็อบเจกต์การตั้งค่า DNS ของส่วนขยายเครือข่าย และระบบนำไปใช้กับตัวแก้ไขที่จำกัดขอบเขตแต่ละตัว รูปแบบเหล่านี้ไม่ใช่เส้นทางสักอย่าง และไม่มีอันใดทำให้ที่อยู่ที่เข้าถึงไม่ได้กลายเป็นเข้าถึงได้ นโยบายแก้ชื่อของ Windows แสดงรายชื่อฟิลด์และกฎความสำคัญสำหรับแพลตฟอร์มนั้น และไม่ใช่กฎที่เอกสารของ Apple หรือ systemd ใช้
คำตอบที่ถูกต้องยังต้องมีเส้นทาง
คำตอบของตัวแก้ไขเป็นเพียงที่อยู่ และแอปพลิเคชันยังต้องไปให้ถึง การออกแบบอุโมงค์แยกส่วนมักดัน 10.20.0.0/16 และกักเส้นทางเริ่มต้นไว้ ชื่อภายในจึงแก้ได้แล้วการเชื่อมต่อก็ค้าง กรณีตรงข้ามก็พบได้บ่อยพอ ๆ กัน: เส้นทางมีอยู่ ตัวแก้ไขสาธารณะตอบชื่อส่วนตัวด้วย NXDOMAIN และความล้มเหลวถูกบันทึกเป็นปัญหาการกำหนดเส้นทาง การทดสอบเส้นทางก่อนทำให้คุณจ้องเส้นทางสำหรับชื่อที่ไม่เคยจะแก้ได้เลย
ยังมีประตูที่สามที่ไม่มีครึ่งไหนครอบคลุม ACL บนเกตเวย์ กฎไฟร์วอลล์ หรือนโยบายฝั่งไคลเอนต์สามารถทิ้งการเชื่อมต่อได้หลังจากทั้งสองการตัดสินใจถูกต้อง เมื่อชื่อแก้ได้ เส้นทางมีอยู่ และการเชื่อมต่อยังหมดเวลา ให้หยุดทดสอบ DNS
ทดสอบชื่อและเส้นทางตามลำดับที่แน่นอน
เลือกลำดับหนึ่งและยึดไว้ ไม่อย่างนั้นคุณจะไล่ตามขั้นตอนที่ล้มเหลวล่าสุด แก้ชื่อภายในแบบเต็มที่เอกสารระบุ ยืนยันว่าคำตอบเป็นที่อยู่ที่ตารางเส้นทางพาไปได้ แล้วทำซ้ำด้วยชื่อสาธารณะเพื่อพิสูจน์ว่าอุโมงค์ไม่ได้จับทุกอย่าง บนโฮสต์ systemd คำถามกับโดเมนเส้นทางของตัวแก้ไขห่างกันหนึ่งคำสั่ง
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10ไคลเอนต์ Windows ถามสองคำถามเดียวกันด้วย cmdlet อื่น คำสั่งที่สองรายงานอินเทอร์เฟซที่ระบบจะใช้จริง
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10ถ้าการค้นหาคืนที่อยู่และการตรวจเส้นทางระบุอินเทอร์เฟซกายภาพ กฎชื่อก็ทำงานและเส้นทางไม่ทำงาน ถ้าชื่อสั้นล้มเหลวขณะที่ชื่อเต็มแก้ได้ แสดงว่ารายการคำต่อท้ายผิด ไม่ใช่ตัวแก้ไข
ที่ที่การเปรียบเทียบมักผิดพลาด
ข้อผิดพลาดแรกคือถามตัวแก้ไขสาธารณะที่ไม่เกี่ยวข้องเกี่ยวกับชื่อส่วนตัวและอ่านการปฏิเสธเป็นหลักฐานเกี่ยวกับ VPN ข้อที่สองคือสมมติว่าการค้นหาสาธารณะที่ทำงานได้พิสูจน์เส้นทางตัวแก้ไขของอุโมงค์ ข้อที่สามคือถือว่าอุโมงค์แยกส่วนและ DNS แยกส่วนเป็นการตัดสินใจออกแบบเดียว ขณะที่การติดตั้งอาจถูกในอย่างหนึ่งและพังในอีกอย่างหนึ่ง ทุกข้อผิดพลาดให้ข้อสรุปที่มั่นใจจากการทดสอบที่ไม่เคยฝึกส่วนที่ถูกกล่าวหา
เบราว์เซอร์ที่มี DNS ปลอดภัยของตัวเองก็ข้ามกฎของระบบได้เช่นกัน นี่คือเหตุที่เบราว์เซอร์หนึ่งล้มเหลวขณะที่อีกตัวสำเร็จไม่ใช่ความขัดแย้ง เปรียบเทียบตัวแก้ไขที่ตอบ ไม่ใช่เบราว์เซอร์ที่บ่น
เมื่อเห็นทั้งสองครึ่งแล้ว คำถามที่เหลือเป็นคำถามเชิงนโยบายไม่ใช่เชิงเทคนิค: เนมสเปซใดเป็นขององค์กร ใครเป็นเจ้าของคำตอบแต่ละข้อ และข้อใดควรออกจากเครื่องเลย เขียนสิ่งนั้นไว้ข้างโปรไฟล์ เพราะคนถัดไปที่แตะกฎจะต้องใช้มัน