SSTP ล้มเหลวในจุดที่ HTTPS ของเบราว์เซอร์สำเร็จ: เพราะอะไร
SSTP ทำงานภายใน TLS บนพอร์ต 443 แต่ไม่ใช่คำขอเว็บ ทดสอบ TCP ตัวตน TLS การแลกเปลี่ยน SSTP และการรับรองตัวตน PPP เป็นขั้นแยกกัน
เบราว์เซอร์เปิดชื่อโฮสต์ VPN ผ่าน HTTPS ได้โดยไม่มีข้อบกพร่อง แต่ไคลเอนต์ SSTP ยังคงปฏิเสธการเชื่อมต่อ ทั้งสองอย่างนี้ไม่ได้ขัดแย้งกันเลย SSTP ใช้ TLS เป็นการขนส่งชั้นนอก แล้วจึงเรียกคำขอของตัวเองและเพย์โหลด PPP ภายใน การเชื่อมต่อนั้น ดังนั้นการโหลดหน้าเว็บสำเร็จพิสูจน์เพียงเรื่องแคบ ๆ อย่างเดียว: โฮสต์ตอบ GET บนพอร์ต 443 ไคลเอนต์กำลังถามคำถามอื่น และเซิร์ฟเวอร์อาจตอบได้ไม่ดี
หน้าเว็บโหลดได้แต่ทันเนลไม่ขึ้น
ผู้คนหันไปใช้การทดสอบผ่านเบราว์เซอร์เพราะรวดเร็ว แล้วจึงถือผลลัพธ์เป็นหลักฐานว่าเซิร์ฟเวอร์เข้าถึงได้และกำหนดค่าแล้ว มันเป็นหลักฐานเกี่ยวกับ GET ไปยังเส้นทางที่แถบที่อยู่เปิดขึ้น ไม่มากไปกว่านั้น การสนทนา VPN เริ่มหลังการจับมือ TLS เดียวกัน แต่ส่ง เมธอดและเส้นทางที่หน้าเว็บไม่เคยใช้ ดังนั้นการตอบกลับ 200 สำหรับเบราว์เซอร์จึงไม่ได้บอกอะไรว่าจุดปลาย SSTP มีอยู่หรือไม่
แยกข้อสังเกตสองอย่างออกจากกัน แล้วการค้นหาจะสั้นลง การขนส่งและห่วงโซ่ใบรับรองทำงาน และมีบางอย่างในการแลกเปลี่ยนโปรโตคอลเหนือขึ้นไปที่ไม่ทำงาน นี่คือการสอบสวนที่ต่างจากพอร์ตเสียหรือใบรับรองหมดอายุ และต้องใช้หลักฐานต่างกัน
ไคลเอนต์ SSTP ส่งอะไรจริง ๆ
ไคลเอนต์ส่งคำขอ HTTP ด้วยเมธอด SSTP_DUPLEX_POST ไปยังเส้นทาง /sra_{GUID}/ แล้วเก็บเนื้อความการเชื่อมต่อไว้เปิดเป็นสตรีมสองทิศทางที่บรรทุกเฟรม PPP เซิร์ฟเวอร์ที่สอดคล้องตอบ HTTP/1.1 200 และเลิกทำตัวเหมือนเว็บเซิร์ฟเวอร์ สิ่งอื่นใดคือลายเซ็น: 405 หรือ 404 หมายถึงไม่มีจุดปลาย 301 หรือ 302 หมายถึงมีบางอย่างเปลี่ยนเส้นทางคำขอ และ FIN ทันทีหมายถึงพร็อกซีหรือเซิร์ฟเวอร์ปิดสตรีม
นั่นคือเหตุผลที่เป้าหมายต้องเป็นเซิร์ฟเวอร์ SSTP ไม่ใช่เว็บเซิร์ฟเวอร์ที่ติดใบรับรอง TLS ไว้ เมธอด เส้นทาง และเนื้อความที่มีอายุยาวเป็นข้อกำหนดของโปรโตคอล พร็อกซีย้อนกลับจึงเพิ่มสิ่งเหล่านั้นด้วยการกำหนดค่าเพียงอย่างเดียวไม่ได้ พร็อกซีที่ส่งต่อ HTTPS ปกติได้อย่างสมบูรณ์แบบก็ยังอาจปฏิเสธเมธอดที่ไม่รู้จัก
พร็อกซีหรือเว็บเซิร์ฟเวอร์ทำให้สตรีมแตกที่ไหน
ตัวกลางตรวจสอบบรรทัดคำขอ HTTP ก่อนส่งต่อสิ่งใด และเมธอดที่กำหนดเองพร้อมเส้นทางแปลก ๆ อาจไม่ผ่านกฎของมัน อุปกรณ์บางชนิดให้บริการหน้าเว็บปกติขณะที่ปฏิเสธหรือขัดจังหวะทันเนล ไคลเอนต์จึงรายงานการเชื่อมต่อที่เริ่มแล้วตายลงแทนการปฏิเสธอย่างสะอาด อุปกรณ์อื่นยอมรับคำขอแล้วใช้เวลาหมดอายุของเนื้อความหรือการไม่ใช้งานที่ keepalive ของ PPP ทนไม่ได้ ทั้งสองดูเหมือนกันจากฝั่งไคลเอนต์ เพราะเหตุนี้ขั้นที่ล้มเหลวจึงสำคัญกว่าข้อความข้อผิดพลาด
การแชร์พอร์ต 443 ระหว่างเว็บไซต์และ SSTP เป็นการเลือกเส้นทาง ไม่ใช่คำสัญญาว่าทุกฮอปจะจัดการบทสนทนาทั้งสองเหมือนกัน หากมีตัวบาลานซ์โหลด ไฟร์วอลล์ หรือตัวสิ้นสุด TLS อยู่ในเส้นทาง ให้เพิ่มเข้าในรายการต้องสงสัยก่อนแตะการกำหนดค่า VPN
ทดสอบแต่ละขั้นแยกกัน
รันการตรวจสอบตามลำดับและหยุดที่ความล้มเหลวแรก เพราะแต่ละขั้นตัดชั้นที่ต่างกันออกไป โพรบ TLS ด้านล่างแยกตัวตนของใบรับรองออกจากทุกสิ่งที่ SSTP ทำ แทนที่ชื่อโฮสต์ด้วยจุดปลายของคุณแล้วอ่าน subject และห่วงโซ่ที่มันพิมพ์ออกมา
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comจากนั้นจับคู่หลักฐานที่เหลือกับขั้นต่าง ๆ แทนการเดาจากข้อผิดพลาดของไคลเอนต์ ตารางด้านล่างคือรายการตรวจสอบสำหรับอ้างอิงในตั๋ว พร้อมลายเซ็นที่แยกความล้มเหลวหนึ่งจากถัดไป
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
บันทึกขั้นสุดท้ายที่สำเร็จในตั๋วแทนการเขียน "เชื่อมต่อไม่ได้" ข้อกำหนด MS-SSTP จัดทำเอกสารคำขอและการแลกเปลี่ยน PPP ที่ตามหลังการจับมือ TLS และเป็นข้อมูลอ้างอิงว่าทำไมการทดสอบผ่านเบราว์เซอร์จึงแทนที่ทั้งสองอย่างไม่ได้
ตัวตนก่อน แล้วจึง PPP
ตัวตน TLS และการรับรองตัวตน PPP เป็นลำดับ ไม่ใช่ทางเลือก และการสับสนทั้งสองทำให้ผู้คนไปสู่การตั้งค่าเซิร์ฟเวอร์ผิด ไคลเอนต์ตรวจสอบใบรับรองของเซิร์ฟเวอร์และวัตถุประสงค์ที่ตั้งใจก่อน จากนั้น PPP เจรจาสถานะของตัวเองและรับรองผู้ใช้ด้วยวิธีท้าทาย-ตอบสนองหรือ EAP ปัญหาใบรับรองให้ข้อผิดพลาดต่างจากรหัสผ่านที่ถูกปฏิเสธ และไม่มีข้อผิดพลาดใดอธิบายขั้นที่อีกอย่างครอบคลุม
การแทนที่ชื่อโฮสต์ด้วยที่อยู่ หรือคลิกข้ามคำเตือนใบรับรอง ลบการตรวจสอบที่จะระบุขั้นที่ล้มเหลวออกไปแทนการแก้ไข รักษาคำเตือนไว้และอ่านมัน อย่ารีเซ็ตรหัสผ่าน PPP เมื่อการแลกเปลี่ยน HTTP ไม่เคยไปถึงพฤติกรรม SSTP เพราะข้อมูลรับรองไม่เคยถูกขอ