วิธีตรวจว่าไคลเอนต์ VPN รองรับ SSTP จริงหรือไม่
ปุ่มนำเข้าและพอร์ต 443 ไม่ได้พิสูจน์อะไร ตรวจสอบการใช้งานที่ระบุ รูปแบบโปรไฟล์ ใบรับรอง และการพิสูจน์ตัวตน PPP แล้วจึงตรวจแต่ละขั้น
การเรียกผลิตภัณฑ์ว่าไคลเอนต์ VPN ไม่ได้บอกอะไรว่ามันพูด SSTP ได้หรือไม่ และพอร์ต 443 ในที่อยู่ยิ่งพิสูจน์ได้น้อยกว่า SSTP รัน TLS บน TCP 443 จากนั้นแลกเปลี่ยนควบคุม SSTP จากนั้น PPP สำหรับลิงก์เอง โดยมีการตรวจใบรับรองและวิธีการพิสูจน์ตัวตน PPP อยู่ด้านบน ไคลเอนต์รองรับโปรโตคอลก็ต่อเมื่อการใช้งานที่ระบุในเวอร์ชันที่ติดตั้งทำให้ทุกชั้นเหล่านั้นสำเร็จตามข้อกำหนดของเซิร์ฟเวอร์ของคุณ ทำการตรวจสอบด้านล่างตามลำดับและหยุดที่รายการแรกที่ล้มเหลว เพราะนั่นคือสิ่งที่คุ้มค่าแก่การแก้
จับคู่การใช้งาน เวอร์ชัน และแพลตฟอร์ม
เริ่มจากแพลตฟอร์ม แอปพลิเคชัน และบิลด์ที่ติดตั้ง เพราะชื่อผู้จำหน่ายชื่อเดียวอาจอยู่บนการใช้งานที่ต่างกันโดยสิ้นเชิงสองแบบ ชนิด VPN ที่มีมาในระบบกับไคลเอนต์บุคคลที่สามไม่ใช่สิ่งเดียวกัน และปลั๊กอินอาจแสดงป้ายอะแดปเตอร์ที่ไม่ตรงกับโปรโตคอลข้างใต้ เอกสารของรุ่นปัจจุบันไม่ได้อธิบายบิลด์ที่ทำงานบนเครื่องตรงหน้าคุณ อ่านหน้าของเวอร์ชันนั้นแล้วเปรียบเทียบกับสิ่งที่ไคลเอนต์รายงานเกี่ยวกับตัวเอง
ใน Windows ชนิดอุโมงค์มาจากแพลตฟอร์มไม่ใช่จาก GUI จึงต้องถามแพลตฟอร์ม Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress แสดง Sstp เมื่อไคลเอนต์พื้นฐานจะลองโปรโตคอล และ เอกสารอ้างอิงชนิดการเชื่อมต่อ ก็ระบุไว้ในชนิดอุโมงค์ที่มีมาในระบบ ใน Linux ไม่มีไคลเอนต์ SSTP พื้นฐานเลย คำถามจึงกลายเป็นว่าการใช้งานแยกเช่น sstpc จากแพ็กเกจ sstp-client ติดตั้งอยู่และเป็นปัจจุบันหรือไม่
อ่านรูปแบบโปรไฟล์ก่อนป้ายชื่อ
โปรไฟล์ใช้แทนกันไม่ได้ และไฟล์ที่ได้รับมามักตัดสินคำถามได้เร็วกว่ารายการคุณสมบัติใด ๆ คำสั่ง OpenVPN คีย์ WireGuard และการตั้งค่าการเชื่อมต่อ SSTP อธิบายโปรโตคอลสามอย่างที่ไม่เกี่ยวข้องกัน และไม่มีกล่องนำเข้ารายการใดเปลี่ยนสิ่งหนึ่งเป็นอีกสิ่งหนึ่ง การแชร์พอร์ต TCP 443 ไม่ได้แปลอะไร เพราะ SSTP, OpenVPN บน TLS และบริการ HTTPS ทั่วไปสามารถใช้พอร์ตเดียวกันได้และไม่มีอะไรเหมือนกันเหนือพอร์ตนั้น
ถ้าไฟล์เป็น .ovpn หรือการตั้งค่า WireGuard คำตอบก็ชัดเจนอยู่แล้ว ไคลเอนต์นั้นไม่ได้ถูกขอให้พูด SSTP การนำเข้าไปยังไคลเอนต์ที่ทำได้แค่ SSTP จะล้มเหลวตั้งแต่ขั้นโปรไฟล์ ก่อนการเจรจาโปรโตคอลใด ๆ จะเริ่มขึ้นเสียอีก
สิ่งที่ TLS ไม่ได้พิสูจน์เกี่ยวกับการติดตั้ง
การจับมือ TLS ที่เสร็จสมบูรณ์พิสูจน์ว่าเซิร์ฟเวอร์มีใบรับรอง และไม่ได้พิสูจน์อะไรเกี่ยวกับว่าไคลเอนต์ของคุณเชื่อถือห่วงโซ่ผู้ออกหรือชื่อภายในตรงกันหรือไม่ การตรวจสอบต้องสำเร็จกับเซิร์ฟเวอร์ที่ตั้งใจ รวมถึง CA ส่วนตัวใด ๆ ที่องค์กรดำเนินการ และไคลเอนต์ที่เสนอให้ข้ามข้อผิดพลาดใบรับรองได้เอาการตรวจออกไปแทนที่จะได้การรองรับโปรโตคอล การตรวจห่วงโซ่และการจับคู่ชื่อเป็นการทดสอบแยกกันสองอย่าง และสแตกที่ผ่านอย่างหนึ่งอาจล้มเหลวในอีกอย่างหนึ่ง ทั้งสองอย่างอยู่ในเกณฑ์การยอมรับ ไม่ใช่ภาคผนวกการแก้ปัญหา
จากนั้นยืนยันวิธีการพิสูจน์ตัวตน PPP เพราะการติดตั้งที่ใช้ EAP-TLS ต้องการไคลเอนต์ที่นำเสนอใบรับรองภายใน PPP ได้ ขณะที่วิธีที่ใช้รหัสผ่านต้องการการรองรับการแลกเปลี่ยนนั้น ถามว่าเซิร์ฟเวอร์บังคับวิธีใดก่อนจะถือว่าไคลเอนต์ทำได้
ติดตามเซสชันผ่านสี่ขั้น
ดูการเชื่อมต่อข้ามสี่พรมแดน: TCP และ TLS ไปยังเซิร์ฟเวอร์ การแลกเปลี่ยนควบคุม SSTP การเจรจา PPP แล้วจึงเป็นทรัพยากรที่คุณต้องการจริง ๆ บันทึกที่หยุดหลัง TLS อธิบายความผิดพลาดต่างจากที่หยุดภายใน PPP และทั้งสองนำไปสู่ผู้รับผิดชอบต่างกัน การที่เบราว์เซอร์โหลดหน้าเว็บของโฮสต์พิสูจน์เพียงว่ามีบางสิ่งตอบบน 443 ซึ่งเป็นผลบวกลวงที่พบบ่อยที่สุดในด้านนี้ ถ้าหน้านั้นโหลดได้แต่ไคลเอนต์ยังล้มเหลว ปัญหา อยู่เหนือ TLS และเว็บเซิร์ฟเวอร์ไม่ใช่ผู้ต้องสงสัย
ปิดท้ายด้วยทรัพยากรส่วนตัวจริงและการค้นหาชื่อ เพราะเซสชันที่สร้างขึ้นแล้วไม่บรรทุกอะไรดูเหมือนเซสชันที่ทำงานได้ในหน้าต่างสถานะส่วนใหญ่ คำขอเดียวที่สำเร็จไปยังทรัพยากรที่คุณต้องการจะตัดสินคำถามที่ไอคอนตอบไม่ได้
เมื่อไม่มีการรองรับ ให้เปลี่ยนแผน
ถ้าไคลเอนต์พูด SSTP ไม่ได้ ให้หาทางเลือกที่ได้รับอนุมัติหรือขอให้เจ้าของเซิร์ฟเวอร์ใช้โปรโตคอลที่ทั้งสองฝั่งรองรับ การลบตัวเลือกที่ไม่รู้จักจนกว่าการนำเข้าจะสำเร็จทำให้เกิดโปรไฟล์ที่ไม่เชื่อมต่อกับสิ่งใดเลย ซึ่งเป็นเส้นทางที่ช้ากว่าไปยังทางตันเดียวกัน ตัวติดตั้งจากแหล่งที่ไม่รู้จักซึ่งโฆษณาความเข้ากันได้สากลเพิ่มเส้นทางความเชื่อถือที่ไม่ได้รับอนุมัติให้กับเครื่อง และมักแทนที่ไคลเอนต์ของแพลตฟอร์มด้วยสิ่งที่องค์กรอัปเดตไม่ได้ ทั้งสองอย่างไม่ใช่การแก้ไข และทั้งสองอย่างย้อนกลับยากกว่าปัญหาเดิม
แยกคำถามเรื่องความเข้ากันได้ออกจากประสิทธิภาพและการเลือกปลายทาง เพราะเซิร์ฟเวอร์ที่อยู่ใกล้ไร้ประโยชน์เมื่อไคลเอนต์พูดโปรโตคอลของมันไม่ได้ การปรับความหน่วงไม่ได้แก้ขั้นตอนที่ไม่เคยเสร็จสิ้น