ทำไม VPN ที่มีมาใน Windows จึงต่อเข้ากับเกตเวย์ SSL ของผู้จำหน่ายไม่ได้

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

สี่ชนิดกับกล่องโต้ตอบเดียว

ทุกโปรไฟล์ที่บันทึกไว้มีชนิดของอุโมงค์ ไคลเอนต์ที่มีมาให้รองรับ PPTP, L2TP, IKEv2 และ SSTP พร้อมโหมดอัตโนมัติที่ลองตามลำดับ ไม่มีรายการ SSL VPN แบบทั่วไป และไม่มีวิธีเพิ่มผ่านกล่องโต้ตอบ เกตเวย์ของผู้จำหน่ายพูดโปรโตคอลแอปพลิเคชันของตนเองบน TLS ซึ่งมีเพียงไคลเอนต์ของผู้จำหน่ายรายนั้นที่ทำงานตาม

รายการอยู่ห่างออกไปเพียงคำสั่งเดียว และคุ้มค่าที่จะรันก่อนการแก้ปัญหาอื่นใด เพราะใช้เวลาเพียงวินาทีเดียวและกำจัดสมมติฐานผิด ๆ ได้ทั้งกลุ่ม:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

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

SSTP กับ TLS ของผู้จำหน่ายดูคล้ายกันบนพอร์ต 443

SSTP ห่อเซสชัน PPP ไว้ใน TLS และวิ่งบน TCP 443 ในสแต็กของ Microsoft นั้น RRAS เป็นตัวปิดเซสชัน ซึ่งนำเสนอใบรับรองเซิร์ฟเวอร์ที่ไคลเอนต์ตรวจสอบ อุปกรณ์ Fortinet, Citrix หรือ Pulse ก็ปิด TLS บน 443 เช่นกัน และพอร์ทัลของอุปกรณ์นั้นเปิดได้ในเบราว์เซอร์ใดก็ได้โดยไม่มีปัญหา

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

ความสับสนแบบกลับกันก็เกิดขึ้นได้ โปรไฟล์ที่ตั้งเป็น SSTP กับเซิร์ฟเวอร์ RRAS ของจริงอาจล้มเหลวในการตรวจสอบใบรับรองทั้งที่พอร์ทัลปกติดี และนั่นเป็นปัญหาใบรับรองไม่ใช่ปัญหาโปรโตคอล

ข้อผิดพลาดที่ปรากฏก่อนที่อุโมงค์จะเกิดขึ้น

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

เปิดการติดตามก่อนที่จะสร้างอะไรใหม่ การติดตามจะระบุขั้นตอนที่ล้มเหลว และชื่อขั้นตอนมีค่ามากกว่าข้อความในกล่องโต้ตอบ:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

ร่องรอยการติดตามจะไปอยู่ในไดเรกทอรีการติดตามและอยู่ที่นั่นจนกว่าคุณจะล้างออก ดังนั้นควรปิดการติดตามภายหลังแทนที่จะปล่อยให้ทำงานหลายสัปดาห์

โปรไฟล์ที่เชื่อมต่อได้ก็ยังทำให้ทุกอย่างพังได้

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

การตั้งค่าสองอย่างตัดสินเรื่องนี้ อย่างแรกคือคุณสมบัติ split tunneling บนโปรไฟล์ อย่างที่สองคือตัวเลือกต่ออะแดปเตอร์ให้ใช้เกตเวย์เริ่มต้นบนเครือข่ายระยะไกล ซึ่งอยู่ในการตั้งค่า IPv4 ขั้นสูง

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

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

ตรวจสอบระบบท่อก่อน แล้วจึงตรวจชนิด

ทำตามลำดับนี้ และหยุดเมื่อขั้นตอนใดล้มเหลวแทนที่จะปรับทุกอย่างพร้อมกัน:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

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

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