SSTP กับ OpenVPN: พอร์ต 443 เดียวกัน แต่โปรโตคอลต่างกัน

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

พอร์ตร่วมไม่ได้ทำให้โปรโตคอลร่วมกัน

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

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

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

SSTP อุโมงค์ PPP ภายใน HTTPS

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

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

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

OpenVPN นำไคลเอนต์ของตัวเองและทางเลือกทรานสปอร์ตมาให้

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

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

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

เลือกตามไคลเอนต์ ทรานสปอร์ต และการสนับสนุน

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

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

จากนั้นยืนยันว่าคุณสร้างอันไหนจริง ๆ ก่อนจะแก้ไขสิ่งอื่น:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

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

ในกองเรือที่บริหารจัดการ การแจกจ่ายโปรไฟล์และการสนับสนุนการอัปเดตมักตัดสินคำถามนี้ก่อนการวัดทรานสปอร์ตใด ๆ มาก