SSTP เบื้องหลังพร็อกซีที่ตรวจสอบ TLS: จุดที่เซสชันขาด

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

เริ่มจากจุดที่ไคลเอนต์หยุด

ไคลเอนต์ผ่านลำดับคงที่ คือ การเชื่อมต่อ TCP ไปยังพอร์ต 443 การจับมือ TLS การตรวจสอบใบรับรอง การแลกเปลี่ยน HTTP ของ SSTP การเจรจาและรับรองตัวตน PPP จากนั้นจึงเป็นการกำหนดค่า IP ความล้มเหลวในแต่ละขั้นทิ้งร่องรอยต่างกัน และการสับสนระหว่างกันจะพาคุณไปยังหน้าการกำหนดค่าที่ผิด

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

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

สิ่งที่ SSTP ขอให้เครือข่ายบรรทุก

SSTP ทำงานบน TLS บน TCP 443 แล้วส่งคำขอ HTTP ชื่อ SSTP_DUPLEX_POST ซึ่งกำหนดไว้ในข้อกำหนด SSTP ไปยังเส้นทางรูปแบบ /sra_{GUID}/ คำขอประกาศความยาวเนื้อหาที่ไม่จำกัดโดยพฤตินัย และคงสตรีมเปิดทั้งสองทิศทางตลอดอายุเซสชัน เฟรม PPP เดินทางภายในสตรีมนั้น

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

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

ทำไมการตรวจสอบจึงเปลี่ยนอัตลักษณ์

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

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

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

ระบุผู้ออกใบรับรองก่อนเปลี่ยนการตั้งค่า

ถามปลายทางว่าแสดงใบรับรองใดและใครลงนาม คำสั่งด้านล่างแสดงห่วงโซ่และผู้ออกโดยไม่เริ่มเซสชัน VPN

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

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

เลือกเส้นทางที่ได้รับการสนับสนุน

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

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

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