ชื่อโฮสต์ของ VPN ใช้ไม่ได้ แต่ที่อยู่ IP ใช้ได้: ควรดูตรงไหน

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

ชื่อถามคำถามที่ที่อยู่ไม่ได้ถาม

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

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

อ่านตัวแก้ชื่อที่อุโมงค์ติดตั้งจริง

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

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

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

Get-DnsClientNrptPolicy
ipconfig /all

หยุดถ้าโซนภายในแก้ได้ผ่านเซิร์ฟเวอร์ที่ถูกต้อง ตัวแก้ชื่อไม่ใช่ปัญหาของคุณ

คำต่อท้ายอธิบายชื่อสั้นที่ใช้ไม่ได้

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

nslookup fileserver.corp.example
ping -a 192.168.50.20

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

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

NetBIOS และ WINS เป็นกลไกที่ต่างกัน

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

nbtstat -n
nbtstat -R

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

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