พอร์ตในช่องที่อยู่ของ VPN บน Windows ใช้ได้เฉพาะกับ SSTP

เซิร์ฟเวอร์ VPN ตอบบน TCP 10443 ไคลเอนต์ในตัวของ Windows มีข้อมูลรับรองที่ถูกต้อง แต่การเชื่อมต่อก็ยังขาดหลังจากหยุดชั่วครู่ที่ดูเหมือน DNS หมดเวลา สาเหตุมักอยู่ที่ช่องที่อยู่ การพิมพ์ vpn.example.com:10443 ลงในช่องชื่อเซิร์ฟเวอร์หรือที่อยู่ทำให้ Windows อ่านทั้งสตริงเป็นชื่อโฮสต์ เพราะช่องนั้นไม่ใช่ช่องกรอก host:port ทั่วไป การจะเขียนพอร์ตตรงนั้นได้หรือไม่ขึ้นกับชนิดอุโมงค์ที่โปรไฟล์ใช้ และมีเพียงหนึ่งในสี่ชนิดที่ถือว่าเป็นค่าที่ตนแยกวิเคราะห์ได้

ทำไมช่องที่อยู่จึงไม่ใช่ช่อง host:port

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

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

สามชนิดที่มีพอร์ตตายตัว

PPTP เชื่อมต่อ TCP 1723 แล้วบรรทุกอุโมงค์ใน GRE ซึ่งเป็นโปรโตคอล IP 47 L2TP/IPsec ใช้ UDP 1701 สำหรับอุโมงค์ และ UDP 500 กับ 4500 สำหรับ IPsec โดย 4500 เป็นพอร์ตสำหรับผ่าน NAT IKEv2 ก็ใช้ UDP 500 และ 4500 เช่นกัน ไม่มีโปรไฟล์ใดในกลุ่มนี้แสดงช่องพอร์ตที่ใดในอินเทอร์เฟซ และไม่มีตัวใดเจรจาพอร์ตที่ไม่ได้มาตรฐาน

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

SSTP ต้องการ URL ไม่ใช่ชื่อ

SSTP เป็นข้อยกเว้นเพราะทำงานภายในเซสชัน TLS ช่องนี้ต้องแยกวิเคราะห์เป็น URL คือสคีมา https:// ก่อน ตามด้วยโฮสต์ แล้วจึงโคลอนและพอร์ต หากไม่มีสคีมา Windows จะยังถือค่าเป็นชื่อธรรมดาและการเชื่อมต่อล้มเหลวก่อนการแลกเปลี่ยน TLS ใด ๆ

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

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

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

ไวยากรณ์ของผู้จำหน่ายที่ถูกวางลงในช่องเดียวกัน

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

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

พิสูจน์พอร์ต แล้วอ่านขั้นตอนที่ล้มเหลว

ก่อนจะโทษโปรไฟล์ ให้ยืนยันว่ามีบางอย่างรับ TCP บนพอร์ตนั้นจากเครือข่ายของไคลเอนต์

Test-NetConnection vpn.example.com -Port 10443

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

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