ชื่อภายในใช้ไม่ได้บน VPN ขณะที่เว็บไซต์สาธารณะยังใช้งานได้ปกติ

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

สองอาการที่ไม่ใช่ความผิดพลาดเดียว

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

กับดักคือการเพิ่มตัวแปลงชื่อของสำนักงานไว้ทุกที่แก้อาการแรกและรับประกันอาการที่สอง การเพิ่มตัวแปลงชื่อสาธารณะไว้ทุกที่ทำตรงกันข้าม

จดข้อสังเกตทั้งสองพร้อมเวลา แล้วไล่ตรวจทั้งสี่ข้อด้านล่างตามลำดับ

ตัวแปลงชื่อของอะแดปเตอร์ตัวไหนได้รับคำถาม

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

ลำดับการผูกเป็นเพียงครึ่งแรก ไคลเอนต์ยังต้องรู้ว่าชื่อใดเป็นของอะแดปเตอร์นั้น และนั่นเป็นคำถามเรื่องคำต่อท้ายไม่ใช่เรื่องลำดับ

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

ชื่อสั้นต้องมีคำต่อท้ายก่อนที่จะต้องการเส้นทาง

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

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

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

ถามตัวแปลงชื่อโดยตรง แล้วจึงถามชื่อ

คำถามตรงถึงตัวแปลงชื่อของสำนักงาน แยกปัญหาชื่อออกจากปัญหาเส้นทาง เพราะมันข้ามการเลือกตัวแปลงชื่อของไคลเอนต์ไปทั้งหมด

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

บน Linux ไคลเอนต์ VPN ที่เขียนทับ /etc/resolv.conf จะแทนที่ตัวแปลงชื่อภายในทั้งหมด vpnc เปิดให้ใช้ DNSUpdate no เพื่อหยุดสิ่งนั้น และ systemd-resolved สามารถส่งเฉพาะโดเมนที่ระบุไปยังลิงก์ของอุโมงค์ได้ ทั้งสองวิธีเก็บชื่อสาธารณะไว้ที่ตัวแปลงชื่อภายในขณะส่งชื่อภายในไปยังสำนักงาน

การรั่วคือกฎ ไม่ใช่ช่องทำเครื่องหมาย

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

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

ถ้าคำถามปรากฏบนอินเทอร์เฟซนั้นในรูปแบบที่อ่านได้ อุโมงค์ไม่ได้ส่งมัน การซ่อมคือกฎที่อนุญาตพอร์ต 53 ไปยังตัวแปลงชื่อที่ VPN ส่งมาเท่านั้นและทิ้งปลายทางอื่น บวกกับการตั้งค่าไคลเอนต์ที่ไม่ทิ้งตัวเลือกที่ส่งมาอย่างเงียบ ๆ

ส่วนสุดท้ายสำคัญกว่าที่เห็น เริ่ม OpenVPN ด้วย route-nopull แล้วตัวเลือก DNS ที่ส่งมาจะหายไปพร้อมเส้นทาง เว้นแต่ตัวกรองการดึงจะถูกขยายให้เก็บไว้ และไคลเอนต์ที่ dhcp-option DNS ไม่สนใจจะใช้สิ่งที่เคยมีต่อไป การเปลี่ยนแปลงใด ๆ ฝั่งเซิร์ฟเวอร์ต้องมีเซสชันใหม่จึงจะมีผล เพราะรายการตัวแปลงชื่อถูกส่งมาเมื่ออุโมงค์ขึ้น และเซสชันเก่ายังคงแสดงสถานะเก่า

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