SSTP คือ PPP บน HTTPS ไม่ใช่หน้าเว็บบนพอร์ต 443

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

เดินผ่านทั้งสี่ขั้นตามลำดับ และความล้มเหลวที่คุณเห็นจะตกอยู่ในขั้นใดขั้นหนึ่ง

ขั้นที่ 1: TCP และ TLS

ไคลเอนต์เปิดการเชื่อมต่อ TCP ไปยังพอร์ต 443 และทำ handshake TLS ต้องให้ห่วงโซ่ใบรับรองตรงกับชื่อโฮสต์ที่ไคลเอนต์ถูกกำหนดไว้ ชื่อไม่ตรงกันตรงนี้ทำให้เกิดความล้มเหลวก่อนจะมีการแลกเปลี่ยนข้อความ SSTP ใด ๆ และ ข้อกำหนด SSTP สันนิษฐานว่าช่องทาง HTTPS ภายนอกนี้มีอยู่แล้ว ไม่มีสิ่งใดในขั้นต่อมาชดเชยความล้มเหลวของความเชื่อถือตรงนี้ได้

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

ขั้นที่ 2: คำขอ HTTPS

SSTP ส่งคำขอด้วยเมธอดเฉพาะ คือ SSTP_DUPLEX_POST และคงการแลกเปลี่ยนไว้เปิดแทนการส่งเอกสารกลับ เซิร์ฟเวอร์หรือพร็อกซีที่กำหนดค่าสำหรับคำขอหน้าเว็บทั่วไปอาจยอมรับการเชื่อมต่อแล้วปฏิเสธเมธอด การปฏิเสธนั้นคือปัญหาความเข้ากันได้ที่ผู้คนมักอธิบายว่าพอร์ต 443 ถูกบล็อก

อ่านรหัสตอบกลับและเมธอดในบันทึกเซิร์ฟเวอร์ การปฏิเสธในขั้นนี้เป็นปัญหาที่ต่างจาก TCP หมดเวลา และทั้งสองนำไปสู่การแก้ไขที่ต่างกัน

ขั้นที่ 3: ข้อความควบคุม

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

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

ขั้นที่ 4: PPP เข้าควบคุม

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

ใบรับรองที่ได้รับการยอมรับและการเข้าสู่ระบบที่ถูกปฏิเสธไม่ได้ขัดแย้งกัน สิ่งเหล่านี้เป็นขั้นต่อเนื่องที่มีผลลัพธ์อิสระ

การพิสูจน์ตัวตนมีหลายบทบาท

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

จดบันทึกว่าขั้นใดรายงานความล้มเหลว ใบรับรอง เมธอด ข้อความควบคุม การพิสูจน์ตัวตน PPP จากนั้นเส้นทาง: ห้าจุด ห้าการแก้ไข

การทดสอบในเบราว์เซอร์แสดงอะไรได้และแสดงอะไรไม่ได้

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

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