VPN บน Windows แสดง 255.255.255.255: มาสก์ผิดหรือไม่
ในทันเนลแบบจุดต่อจุด มาสก์โฮสต์เป็นเรื่องปกติ ตรวจสอบชนิดอินเทอร์เฟซ อ่านเส้นทางของโฮสต์ที่เข้าถึงไม่ได้ และแยก DNS ออกจากการเข้าถึงบริการ
ทันเนลเชื่อมต่อได้ แต่เมื่อเปิดรายละเอียดอะแดปเตอร์กลับเห็นมาสก์เป็น 255.255.255.255 เมื่อเทียบกับ 255.255.255.0 ของ LAN ในออฟฟิศแล้วดูเหมือนพัง และมักทำให้วินิจฉัยผิดตั้งแต่ตรงนั้น บนลิงก์แบบจุดต่อจุด มาสก์โฮสต์คือคำอธิบายที่ถูกต้องของปลายทางฝั่งท้องถิ่น ส่วนเครือข่ายปลายทางไกลจะมาในรูปของเส้นทาง ไม่ใช่ซับเน็ตที่เชื่อมต่อตรง ขั้นตอนด้านล่างแยกคำถามสองข้อออกจากกัน เพื่อไม่ให้สร้างขอบเขต DHCP ที่ทำงานอยู่ใหม่เพียงเพราะค่าที่แสดงผล
ลิงก์แบบจุดต่อจุดไม่ใช่เซกเมนต์อีเทอร์เน็ต
อินเทอร์เฟซอีเทอร์เน็ตต้องมีซับเน็ตมาสก์เพราะทุกแอดเดรสในช่วงนั้นอาจเข้าถึงได้บนสายเดียวกัน ทันเนลแบบ PPP มีคู่ตรงข้ามเพียงหนึ่งเดียวที่ปลายอีกด้าน ไม่มีบรอดแคสต์โดเมน ไม่มี ARP และไม่มีเหตุผลให้แอดเดรสท้องถิ่นอธิบายช่วงใดช่วงหนึ่ง
การเจรจาแอดเดรสของแบบจำลองนี้กำหนดไว้ใน RFC 1332 ซึ่งอธิบายว่าปลายทั้งสองตกลงแอดเดรสของตนกันอย่างไร แต่ไม่ได้ส่ง LAN ของออฟฟิศให้ไคลเอนต์ในฐานะเครือข่ายที่เชื่อมต่อโดยตรง ไคลเอนต์เรียนรู้ว่าออฟฟิศอยู่ที่ใดโดยการติดตั้งเส้นทางผ่านลิงก์ และเส้นทางเหล่านั้นคือสิ่งที่กำหนดการเข้าถึงจริง
นี่ไม่ได้หมายความว่าทุกมาสก์ที่เห็นถูกต้อง ไคลเอนต์ที่ตั้งค่าผิดก็ทำให้เกิดการกำหนดแอดเดรสแปลก ๆ ได้ ประเด็นแคบกว่า: มาสก์โฮสต์บนอะแดปเตอร์ชนิดนี้เป็นสิ่งที่คาดไว้ จึงไม่ใช่หลักฐานของความขัดข้องโดยตัวมันเอง
ขั้นที่ 1: ตรวจสอบชนิดอินเทอร์เฟซ
ดูก่อนว่าอะแดปเตอร์คืออะไร แล้วจึงตัดสินว่ามันบอกอะไร สตริงคำอธิบายระบุไดรเวอร์ และความยาวพรีฟิกซ์ของแอดเดรสที่ได้รับยืนยันว่าไคลเอนต์เจรจาอะไรไว้:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuคำสั่งที่สามคือตัวที่ยุติข้อโต้แย้งส่วนใหญ่ หน่วยส่งข้อมูลสูงสุดที่ต่ำเป็นลักษณะของลิงก์ที่ห่อหุ้ม ขณะที่ค่าที่ใกล้เคียงอีเทอร์เน็ต ชี้ไปที่แบบจำลองอะแดปเตอร์เสมือนอีกรูปแบบหนึ่ง หากคำอธิบายระบุไดรเวอร์ PPP หรือ RAS และพรีฟิกซ์เป็น 32 แปลว่ากำลังดูการออกแบบที่อธิบายข้างต้นพอดี และเลิกกังวลเรื่องมาสก์ได้
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
ขั้นที่ 2: อ่านเส้นทางของปลายทางที่ล้มเหลว
การเข้าถึงถูกตัดสินแยกตามปลายทาง และอินเทอร์เฟซที่เชื่อมต่อเพียงตัวเดียวไม่ได้บอกอะไรเกี่ยวกับเรื่องนี้ ถามตารางเส้นทางโดยตรงถึงแอดเดรสที่ผู้ใช้กำลังพยายามเข้าถึงจริง:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute คือคำตอบตรง ๆ: มันระบุอินเทอร์เฟซและแอดเดรสต้นทางที่ระบบจะใช้สำหรับปลายทางนั้น หากคืนค่าทันเนล แปลว่าทราฟฟิกไปยังโฮสต์นั้นผ่านทันเนล และมาสก์ไม่เคยเป็นปัญหา
หากคืนค่าอะแดปเตอร์กายภาพ ให้เทียบเส้นทางที่เป็นไปได้สองเส้นกับเมตริกของแต่ละเส้น เส้นทางท้องถิ่นที่เจาะจงกว่า รายการตกค้างจากไคลเอนต์อื่น หรือเมตริกที่ต่ำกว่าบนเส้นทางกายภาพ ล้วนชนะเส้นทางทันเนลที่กว้างกว่า ผลที่เห็นได้คือทรัพยากรที่เข้าถึงไม่ได้ในขณะที่อย่างอื่นทำงานปกติ พรีฟิกซ์ที่ยาวกว่าชนะเสมอ ผู้ชนะจึงมักเป็นเส้นทางโฮสต์ที่ใครบางคนเพิ่มไว้เมื่อหลายเดือนก่อนแล้วลืม
ตรวจทั้งสองทิศทางด้วย เส้นทางไปฝั่งเซิร์ฟเวอร์เป็นเงื่อนไขจำเป็นแต่ไม่เพียงพอ เพราะคำตอบก็ต้องกลับมาผ่านทันเนลเช่นกัน เมื่อโฮสต์ภายในเครื่องหนึ่งใช้ได้อีกเครื่องไม่ได้ ความแตกต่างมักอยู่ในตารางนี้ ไม่ใช่ในการตั้งค่าอะแดปเตอร์
ขั้นที่ 3: แยกการแก้ชื่อออกจากการเข้าถึงบริการ
แอปที่เปิดแชร์ไม่ได้อาจล้มเหลวที่ขั้นใดขั้นหนึ่งจากสองขั้นที่ต่างกันมาก ขั้นแรกคือแก้ชื่อ ขั้นถัดไปคือเข้าถึงแอดเดรส หากขั้นแรกล้มเหลวและขั้นที่สองสำเร็จ แปลว่าทันเนลปกติดี แต่ตัวแก้ชื่อมีปัญหา:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445การทดสอบแอดเดรสที่สำเร็จพร้อมกับการทดสอบชื่อที่ล้มเหลวทำให้ระบุปัญหาไปที่การแก้ชื่อ และคำสั่งที่สองแสดงว่าอินเทอร์เฟซทันเนลได้รับเซิร์ฟเวอร์มาหรือไม่ ไคลเอนต์จำนวนมากผลัก DNS ลงมาเป็นส่วนหนึ่งของการตั้งค่าทันเนล และโปรไฟล์ที่เพิกเฉยต่อตัวเลือกที่ผลักลงมานั้นจะทำให้เครื่องยังใช้ตัวแก้ชื่อที่ไม่เห็นโซนส่วนตัว
อย่าถือว่าแอดเดรสที่ใช้งานได้คือการแก้ไขถาวร การเชื่อมต่อด้วยแอดเดรสข้ามการแก้ชื่อ และอาจทำให้การตรวจสอบตัวตนของเซิร์ฟเวอร์ที่แอปควรทำอ่อนลง นี่คือการถอยหลังด้านความปลอดภัยที่ปลอมตัวเป็นวิธีเลี่ยงชั่วคราว ใช้มันเพื่อระบุตำแหน่งของปัญหา แล้วจึงแก้การแก้ชื่อ
ย้อนกลับ: อย่าสร้าง DHCP ใหม่เพราะค่าที่แสดงผล
หากเริ่มแก้บริการกำหนดแอดเดรสไปแล้ว ให้หยุดและตรวจว่าสิ่งที่แก้เป็นส่วนที่รับน้ำหนักหรือไม่ การสร้างขอบเขตใหม่ การออกสัญญาเช่าใหม่ หรือการย้ายพูลจะเปลี่ยนสถานะที่ไคลเอนต์อื่นพึ่งพา และไม่มีข้อใดสมเหตุสมผลเพราะมาสก์โฮสต์บนอะแดปเตอร์แบบจุดต่อจุด
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445รันสามคำสั่งนี้หลังการเปลี่ยนแปลงที่มีเป้าหมายทุกครั้ง และเทียบกับผลรอบก่อน ผลลัพธ์ที่มีประโยชน์คือเส้นทางที่บันทึกได้ไปยังทรัพยากร ไม่ใช่อะแดปเตอร์ที่มีมาสก์คล้าย LAN ของออฟฟิศ
จากนั้นจดว่ามาสก์นั้นหมายความว่าอะไรจริง ๆ เพราะคนถัดไปจะเปิดกล่องโต้ตอบเดิมและได้ข้อสรุปผิดแบบเดียวกัน การเขียนหนึ่งประโยคในบันทึกโปรไฟล์ว่า ทันเนลเป็นแบบจุดต่อจุดและซับเน็ตปลายทางไกลมาในรูปเส้นทาง จะประหยัดการสอบสวนทั้งหมดในครั้งหน้า