ทำไม SSL VPN กับ VPN แบบไซต์ถึงไซต์จึงไม่ใช่สิ่งที่ตรงข้ามกัน
SSL VPN กับ VPN แบบไซต์ถึงไซต์อธิบายแกนคนละแกน: ใครเข้าร่วมเครือข่ายและอุโมงค์ถูกสร้างอย่างไร การเรียกทั้งสองพร้อมกันเป็นข้อผิดพลาดทางหมวดหมู่
ลองให้ผู้ดูแลระบบสองคนอธิบาย VPN เดียวกัน คนหนึ่งอาจตอบว่า “SSL VPN” ขณะที่อีกคนพูดว่า “ไซต์ถึงไซต์” ราวกับทั้งสองเป็นตัวเลือกที่แข่งขันกันในเมนู ทั้งสองเป็นคำตอบของคำถามคนละข้อ และการปฏิบัติต่อทั้งสองเป็นทางเลือกย่อมสร้างการเปรียบเทียบที่หาข้อยุติไม่ได้ แยกแกนทั้งสองออกจากกัน แล้วข้อโต้แย้งส่วนใหญ่ก็จะหายไป
สองป้ายกำกับ สองคำถามที่แยกกัน
โทโพโลยีตอบว่าใครเข้าร่วมกับอะไร การออกแบบการเข้าถึงระยะไกลเชื่อมผู้ใช้หรืออุปกรณ์แต่ละรายเข้ากับเกตเวย์ โดยปกติมีตัวตนต่อผู้ใช้และกลุ่มที่อยู่ ส่วนการออกแบบไซต์ถึงไซต์เชื่อมสองเครือข่ายผ่านเกตเวย์ ตัวตนที่น่าสนใจจึงเป็นเกตเวย์คู่สัญญา ไม่ใช่คนที่อยู่หน้าแป้นพิมพ์ สิ่งเหล่านี้เป็นปัญหาการดำเนินงานที่ต่างกัน ตั้งแต่การวางแผนที่อยู่ไปจนถึงใครสามารถเพิกถอนการเข้าถึงได้ตอนตี 2
กลไกตอบว่าอุโมงค์ถูกสร้างและพิสูจน์ตัวตนอย่างไร IPsec กับ IKEv2 ผลิตภัณฑ์ที่อิง TLS ซึ่งบรรจุ IP ไว้ภายใน และพอร์ทัลแอปพลิเคชันที่หันหน้าไปทางเบราว์เซอร์ล้วนเป็นการเลือกกลไก และแต่ละอย่างมีการเจรจา ชุดรหัสลับ และโหมดความล้มเหลวของตัวเอง ไม่มีสิ่งใดบ่งบอกโทโพโลยี และโทโพโลยีไม่ได้เลือกกลไก
วางสองแกนลงในตารางเดียว ความสับสนจะปรากฏชัด เพราะทุกช่องในตารางสามารถเติมได้ สิ่งที่ตารางทำไม่ได้คือบอกคุณว่าผู้ขายของคุณส่งชุดใดมา เนื่องจากชื่อผลิตภัณฑ์บีบสองแกนให้เหลือเพียงวลีการตลาดเดียว
ข้อผิดพลาดทางหมวดหมู่มาจากไหน
ผู้ขายขาย “SSL VPN” มาหลายปีในฐานะสิ่งที่ตรงข้ามกับ “IPsec VPN” ซึ่งทำให้การเปรียบเทียบกลไกดูเหมือนการเลือกโทโพโลยี วลีนี้เองก็เสื่อมความหมายตามเงื่อนไขของตัวเอง เพราะการออกแบบปัจจุบันใช้เวอร์ชัน TLS ที่รองรับ และชื่อ SSL ยังคงอยู่ส่วนใหญ่ในฐานะหมวดหมู่ผลิตภัณฑ์
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
ตำนานสองเรื่องที่เกี่ยวข้องตามมาจากการบีบอัดเดียวกัน เรื่องแรกคือ IPsec หมายถึงไซต์ถึงไซต์ IKEv2 ถูกออกแบบมาสำหรับความสัมพันธ์ระหว่างไคลเอนต์กับเกตเวย์ด้วย ดังนั้นแล็ปท็อปเครื่องเดียวจึงเข้าร่วมด้วย IPsec ได้ เรื่องที่สองคือผลิตภัณฑ์ที่อิง TLS หมายถึงการเข้าถึงระยะไกลเท่านั้น OpenVPN ถูกใช้เป็นประจำเพื่อบรรทุกการรับส่งข้อมูลระหว่างสองไซต์ และการใช้ TLS ของมันกระจุกตัวอยู่ในการแลกเปลี่ยนการควบคุมและการพิสูจน์ตัวตนมากกว่าในเซสชันเบราว์เซอร์
การทดสอบที่มีประโยชน์สำหรับคำอธิบายใด ๆ: ถ้าการสลับคำหนึ่งคำเปลี่ยนทั้งจุดปลายและโปรโตคอล ประโยคนั้นกำลังผสมแกน “SSL VPN เทียบกับไซต์ถึงไซต์” ไม่ผ่านการทดสอบนั้น เพราะคำแรกระบุตระกูลกลไกและคำที่สองระบุโทโพโลยี
อธิบายการติดตั้งเพื่อให้เปรียบเทียบได้
เขียนสี่ช่องแล้วเติมให้ครบ: จุดปลาย กลไก การพิสูจน์ตัวตน และพื้นผิวการเข้าถึง ลิงก์สาขาอาจอ่านได้เป็นคู่เกตเวย์ IKEv2 ระหว่างสองคำนำหน้าที่ระบุชื่อ พร้อมการพิสูจน์ตัวตนด้วยใบรับรองและไม่มีพอร์ทัลระดับผู้ใช้ บริการการเข้าถึงระยะไกลอาจอ่านได้เป็นไคลเอนต์ที่อิง TLS ซึ่งจัดสรรที่อยู่ต่อผู้ใช้ เรียกปัจจัยที่สองตอนเข้าสู่ระบบ และเผยแพร่เฉพาะโซน DNS ภายใน
ประโยคเหล่านั้นเปรียบเทียบได้ในแบบที่ชื่อผลิตภัณฑ์ทำไม่ได้ สองการออกแบบการเข้าถึงระยะไกลสามารถวัดกับขั้นตอนการทำงานของผู้ใช้เดียวกันและเส้นทางการเพิกถอนเดียวกัน และสองการออกแบบระหว่างไซต์วัดกับรายการคำนำหน้า นโยบายการรับส่งข้อมูล และข้อกำหนดความล้มเหลวเดียวกัน ป้ายกำกับจัดระเบียบการเปรียบเทียบ ไม่ได้แทนที่มัน
ศัพท์ยังมีหลักยึดที่เผยแพร่แล้ว เอกสารศัพท์ VPN ของ IETF แยกแบบจำลองบริการหลายแบบ รวมถึงการเข้าถึงระยะไกลและไซต์ถึงไซต์ ออกจากกลไกที่ใช้สร้างมัน และนั่นคือความแตกต่างที่หลุดหายอยู่ตลอด
อ่านโปรโตคอลที่เจรจาแล้ว ไม่ใช่ชื่อผลิตภัณฑ์
ป้ายบนกล่องไม่ได้กำหนดว่าอุโมงค์ที่ทำงานอยู่ตกลงอะไร ถามคู่สัญญาโดยตรงทางฝั่ง TLS และอ่านเวอร์ชันโปรโตคอลและรหัสลับที่การจับมือสร้างขึ้น แทนเวอร์ชันในโบรชัวร์
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefสำหรับเกตเวย์ IPsec การสังเกตที่เทียบเท่ามาจากเอาต์พุตสถานะของการนำไปใช้เอง ซึ่งรายงานข้อเสนอ IKE และ ESP ที่ใช้งานอยู่ ไม่ว่าอย่างไรประเด็นก็เหมือนกัน: แกนกลไกต้องอ่านจากเซสชันที่มีชีวิต เพราะไคลเอนต์และเกตเวย์สามารถเจรจาลงไปถึงสิ่งที่เก่ากว่าที่ผู้ดูแลระบบคนใดคาดไว้
ipsec statusall | grep -E "IKE|ESP"หลังจากนั้น คำถามที่เหลือคือคำถามที่ไม่มีป้ายใดตอบได้ มีเวอร์ชันโปรโตคอลใดที่ยังยอมรับอยู่ ตัวตนของเกตเวย์ถูกตรวจสอบอย่างไร ชุดอัลกอริทึมใดได้รับอนุญาต ใครอนุญาตผู้ใช้ที่กำหนดให้เข้าถึงทรัพยากรที่กำหนด และอะไรเพิกถอนการเข้าถึงเมื่ออุปกรณ์สูญหาย แผนภาพโทโพโลยีและชื่อกลไกเป็นจุดเริ่มต้นของรายการนั้น ไม่ใช่สิ่งทดแทน
ดังนั้นเก็บป้ายทั้งสองไว้ แต่ใช้ตามที่มันเป็น: วิธีสั้น ๆ ในการบอกว่าจุดปลายใดถูกเชื่อมและอุโมงค์ถูกสร้างอย่างไร ในขณะที่ตัวหนึ่งถูกใช้เพื่อกีดกันอีกตัว คำอธิบายนั้นก็หยุดอธิบายสิ่งใด ๆ