วิธีตรวจสอบว่า VPN บน Windows ส่งทราฟฟิกจริงผ่านเส้นทางใดใน PowerShell
ไทล์ VPN ที่เชื่อมต่ออยู่ไม่ได้พิสูจน์ความครอบคลุม อ่านแฟล็กโปรไฟล์ที่บันทึกไว้ ตารางเส้นทางสด และกฎ NRPT ตามลำดับนี้
ผมเชื่อมต่อไคลเอนต์ VPN บนแล็ปท็อป Windows 11 ไทล์เปลี่ยนเป็น Connected แชร์ไฟล์ภายในเปิดขึ้น และเว็บไซต์สาธารณะยังโหลดตรงจาก Wi-Fi ของออฟฟิศ การผสมกันนี้ดูเหมือนอุโมงค์ที่พัง แต่จริง ๆ แล้วเป็นผลลัพธ์ปกติของโปรไฟล์ที่ส่งทราฟฟิกบางส่วนผ่าน VPN และปล่อยส่วนที่เหลือไว้บนอะแดปเตอร์จริง การบังคับอุโมงค์เปลี่ยนเส้นทางเริ่มต้นที่ Windows เลือกใช้ แต่ไม่ได้ลบเส้นทางที่เจาะจงกว่า และไม่ได้สัญญาว่าทราฟฟิกจะหยุดเมื่อการเชื่อมต่อหลุด ต่อไปนี้คือลำดับที่ผมใช้เมื่อไคลเอนต์อ้างว่าครอบคลุม: สถานะไคลเอนต์ โปรไฟล์ที่บันทึกไว้ เส้นทางที่ใช้งาน ตัวแก้ชื่อ แล้วจึงเป็นโฟลว์จริง
เริ่มจากไคลเอนต์ แล้วเลิกเชื่อถือมัน
ไคลเอนต์เป็นจุดเริ่มที่ถูกต้องเพียงเพราะมันบอกว่าโปรไฟล์ใดทำงานอยู่ เปิดคุณสมบัติการเชื่อมต่อและบันทึกชื่อโปรไฟล์ที่แน่นอน ว่าสร้างสำหรับผู้ใช้ปัจจุบันหรือทุกคนบนเครื่อง และอะแดปเตอร์ใดปรากฏใน ncpa.cpl หลังเชื่อมต่อ บนแล็ปท็อปทดสอบของผมอะแดปเตอร์มีชื่อโปรไฟล์ ซึ่งทำให้อ่านเอาต์พุตเส้นทางได้ง่าย บนเครื่องอื่นมันปรากฏเป็นรายการ WAN Miniport และชื่อไม่ได้บอกอะไรคุณเลย
สิ่งที่ไคลเอนต์บอกคุณไม่ได้คือความครอบคลุม ไทล์ที่เชื่อมต่ออยู่อธิบายสถานะของอุโมงค์ ไม่ใช่บัญชีปลายทาง ไคลเอนต์ของบุคคลที่สามก็เก็บการกำหนดค่าของตัวเองไว้ ดังนั้นโปรไฟล์ Windows แท้ และทุกคุณสมบัติที่คุณจะอ่านจากมัน อาจไม่เกี่ยวข้องกับสิ่งที่ไคลเอนต์นั้นติดตั้งไว้ หาก VPN มาจาก AnyConnect, OpenVPN GUI, WireGuard หรือเอเจนต์ของผู้จำหน่าย การตรวจสอบ PowerShell ด้านล่างมักใช้ไม่ได้ และคุณควรอ่านการตั้งค่า split-tunnel และการกำหนดเส้นทางของไคลเอนต์นั้นแทน
อ่านโปรไฟล์ที่บันทึกไว้ ไม่ใช่ไทล์
สำหรับโปรไฟล์ Windows แท้ (IKEv2, L2TP, SSTP หรือโปรไฟล์ที่ MDM ผลัก) การตัดสินใจ split-tunnel ที่บันทึกไว้เป็นคุณสมบัติเดียว:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixเพิ่ม -AllUserConnection เมื่อโปรไฟล์ถูกสร้างสำหรับทุกคนบนอุปกรณ์ หากไม่มี คุณกำลังอ่านรายชื่อของผู้ใช้ปัจจุบัน ซึ่งอาจว่างเปล่าหรือมีรายการอื่นที่ชื่อคล้ายกัน ค่า False ใน SplitTunneling หมายความว่าโปรไฟล์ถูกบันทึกเป็นอุโมงค์เต็มรูปแบบ: Windows ติดตั้งเส้นทางเริ่มต้นผ่านอะแดปเตอร์ VPN True หมายถึง split tunnel และความครอบคลุมจะขึ้นอยู่กับเส้นทางและกฎการแก้ชื่อที่โปรไฟล์นั้นผลักทั้งหมด
มองค่านั้นเป็นการกำหนดค่า ไม่ใช่การสังเกต มันบันทึกว่าโปรไฟล์ขออะไรตอนเชื่อมต่อ Windows อาจลงเอยด้วยเส้นทางที่ใช้งานต่างออกไป เพราะเส้นทางที่เจาะจงกว่าของอินเทอร์เฟซอื่น การตั้งค่านโยบาย หรือรายการที่ตกค้างจากการเชื่อมต่อก่อนหน้า ดังนั้นค่าบูลีนเพียงอย่างเดียวไม่เคยตัดสินคำถาม
เปรียบเทียบค่าที่บันทึกไว้กับตารางเส้นทางที่ใช้งาน
หลังเชื่อมต่อ ให้แสดงรายการเส้นทางบนอะแดปเตอร์อุโมงค์แทนการเลื่อนทั้งตาราง
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute คือครึ่งที่มีประโยชน์ มันตอบคำถามที่ไคลเอนต์ไม่เคยตอบ: สำหรับปลายทางนี้ Windows จะใช้อินเทอร์เฟซใดและที่อยู่ต้นทางใดจริง ๆ เรียกใช้กับโฮสต์ภายใน โฮสต์สาธารณะ และสิ่งที่คุณถือเป็นข้อยกเว้นโดยเจตนา โปรไฟล์อุโมงค์เต็มควรแสดงอินเทอร์เฟซอุโมงค์สำหรับที่อยู่สาธารณะ โปรไฟล์ split tunnel มักแสดงอะแดปเตอร์จริงตรงนั้น ขณะที่พรีฟิกซ์ภายในยังแก้ไปยัง VPN
กับดักสองอย่างอธิบายรายงาน «มันกำหนดเส้นทางผิดทาง» ส่วนใหญ่ พรีฟิกซ์ที่เจาะจงที่สุดชนะเสมอ ดังนั้น /24 บนอะแดปเตอร์จริงจึงชนะเส้นทางเริ่มต้นบน VPN ไม่ว่าค่าเมตริกของอุโมงค์จะต่ำเพียงใด เมตริกตัดสินเฉพาะค่าเสมอกันระหว่างเส้นทางของพรีฟิกซ์เดียวกัน และ IPv4 กับ IPv6 ถูกตัดสินแยกกัน: โปรไฟล์ที่ครอบ 0.0.0.0/0 อาจทิ้ง IPv6 ไว้บนลิงก์ท้องถิ่น ซึ่งทำให้ไซต์ dual-stack ดูเหมือนถูกอุโมงค์เพียงครึ่งเดียว ตรวจสอบ Get-NetRoute -AddressFamily IPv6 ก่อนสรุปว่าอุโมงค์ปกติ
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
ตรวจสอบการแก้ชื่อแยกต่างหากด้วย NRPT
ชื่อภายในที่ล้มเหลวในขณะที่ที่อยู่ IP ภายในใช้งานได้ชี้ไปที่นโยบายของตัวแก้ชื่อ ไม่ใช่การกำหนดเส้นทาง Windows ตัดสิน DNS ต่อเนมสเปซผ่านตารางนโยบายการแก้ชื่อ ซึ่งเป็นอิสระจากตารางเส้นทาง:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexเมื่อกฎตรงกับ *.corp.example คำค้นสำหรับเนมสเปซนั้นจะไปยังเซิร์ฟเวอร์ DNS ของอุโมงค์ แม้เส้นทางข้อมูลไปยังเซิร์ฟเวอร์เหล่านั้นในโหมด split tunnel จะอยู่บนอะแดปเตอร์จริง นั่นคือการออกแบบ และนั่นคือเหตุผลที่การทดสอบเบราว์เซอร์ที่เปิดไซต์สาธารณะไม่ได้บอกอะไรเกี่ยวกับชื่อภายใน หากอะแดปเตอร์แสดงเซิร์ฟเวอร์ที่คาดไว้แต่การค้นยังไปที่อื่น ให้เปรียบเทียบลำดับกฎ NRPT และตรวจสอบว่าเนมสเปซที่เจาะจงกว่าตรงก่อนหรือไม่
ตรวจสอบโฟลว์ แล้วตัดสินว่าคุณขออะไรจริง ๆ
ไล่ปลายทางตามลำดับคงที่เพื่อให้ผลลัพธ์เทียบกันได้ระหว่างเครื่อง: ที่อยู่สาธารณะ ที่อยู่ภายใน ชื่อภายใน และข้อยกเว้นโดยเจตนาหนึ่งรายการ เช่น เครื่องพิมพ์ท้องถิ่นหรือวิดีโอคอล บันทึกอินเทอร์เฟซและที่อยู่ต้นทางที่ Find-NetRoute คืนค่าสำหรับแต่ละรายการ หลังการเปลี่ยนนโยบายใด ๆ ให้เชื่อมต่อใหม่และทำการตรวจทั้งสี่ซ้ำ ตารางเส้นทางหลังการเชื่อมต่อใหม่คือหลักฐานเดียวว่าโปรไฟล์ใหม่มีผล
จากนั้นแยกการกำหนดเส้นทางออกจากการบังคับใช้ การบังคับอุโมงค์เลือกอุโมงค์สำหรับทราฟฟิกที่ครอบคลุมขณะที่อุโมงค์ยังขึ้นอยู่ ไม่ใช่ kill switch หากข้อกำหนดคือไม่มีสิ่งใดออกจากเครื่องเมื่ออุโมงค์ล่ม สิ่งนั้นต้องมาจากการออกแบบที่บล็อก: โปรไฟล์ไฟร์วอลล์ที่ผูกกับสถานะอุโมงค์ โปรไฟล์เปิดตลอดพร้อมตัวกรองทราฟฟิก หรือตัวเลือกปิดเมื่อล้มเหลวของไคลเอนต์ผู้จำหน่ายเอง การบังคับอุโมงค์ยังต้องปล่อยให้ที่อยู่ของเซิร์ฟเวอร์ VPN เองเข้าถึงได้นอกอุโมงค์ และการบล็อกมันในนามของ «บังคับทุกอย่าง» เป็นวิธีที่เชื่อถือได้ในการล็อกตัวเองออกจากการเชื่อมต่อที่คุณพยายามบังคับ
ก่อนเปลี่ยนอะไร ให้ไล่รายการนี้ ทุกรายการที่ล้มเหลวจะทำให้เห็นว่าปัญหาจริงอยู่ที่ใดแคบลง
- ยืนยันชื่อและขอบเขตโปรไฟล์แล้ว ใช้
-AllUserConnectionสำหรับโปรไฟล์ทั้งเครื่อง - อ่าน
SplitTunnelingแล้วและถือเป็นการกำหนดค่า ไม่ใช่หลักฐานความครอบคลุม - แสดงรายการเส้นทางของอะแดปเตอร์อุโมงค์แยกสำหรับ IPv4 และ IPv6
- เรียกใช้
Find-NetRouteสำหรับปลายทางสาธารณะหนึ่ง ภายในหนึ่ง และข้อยกเว้นหนึ่ง - ตรวจสอบกฎ NRPT ก่อนตำหนิเส้นทางสำหรับความล้มเหลวของชื่อ
- อ่านข้อกำหนดการบล็อกอีกครั้ง: การกำหนดเส้นทางที่ต้องการไม่เหมือนกับการบล็อกที่บังคับใช้
การตัดสินใจเรื่องอุโมงค์เต็มหรือ split เป็นของเจ้าของโปรไฟล์ และบันทึกการกำหนดเส้นทางของ Microsoft อธิบายพฤติกรรมที่ Windows ใช้งานเมื่อโปรไฟล์ตั้งค่าไว้ Microsoft: อุโมงค์แบบบังคับและ split คือเอกสารอ้างอิงที่ผมเปิดไว้ขณะอ่านเอาต์พุต