พอร์ต 443 ตอบสนอง แต่ SSTP ยังล้มเหลว: ขั้นตอนใดพัง

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

มีสี่ขั้นตอนระหว่าง handshake นั้นกับอุโมงค์ที่ใช้งานได้ และแต่ละขั้นให้ข้อผิดพลาดต่างกัน

พอร์ตที่เปิดเผยเพียงเลเยอร์เดียว

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

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

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

แยกสี่ขั้นตอนด้วยหลักฐาน

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

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

คำสั่งที่สามควรอ่านอย่างระมัดระวัง 200 จากหน้าเว็บธรรมดาบอกคุณว่ามีบริการเว็บอยู่ มันไม่ได้บอกว่าคำขอ SSTP จะถูกเข้าใจ 404 จากที่อยู่เดียวกันก็ไม่ให้ข้อมูลเกี่ยวกับ VPN เช่นกัน มีเพียงบันทึกของไคลเอนต์เท่านั้นที่บอกว่าถึงขั้นใดในสี่ขั้น

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

อ่านความสำเร็จบางส่วนในทิศทางที่ถูกต้อง

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

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

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

จากนั้นทดสอบแอปพลิเคชัน ไม่ใช่แค่เซสชัน

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

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