คำอธิบายการเข้ารหัส VPN: IPSec กับ SSL

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

โปรโตคอล VPN ที่ใช้ การเข้ารหัส IPSec ประกอบด้วย L2TP, IKEv2 และ SSTP OpenVPN เป็นโปรโตคอลยอดนิยมที่ใช้การเข้ารหัส SSL, เฉพาะไลบรารี OpenSSL SSL นั้นใช้ใน VPN ที่ใช้เบราว์เซอร์เช่นกัน.

บทความนี้เปรียบเทียบและเปรียบเทียบ IPSec และการเข้ารหัส SSL จากจุดยืนของผู้ใช้ VPN หากคุณต้องการคำอธิบายพื้นฐานเพิ่มเติมเกี่ยวกับโปรโตคอลทั้งสองลองอ่านคู่มือเชิงลึกเกี่ยวกับการเข้ารหัสประเภททั่วไป.

พื้นฐานของการเข้ารหัส VPN

การเข้ารหัส VPN จะแปลงสัญญาณเนื้อหาของการรับส่งข้อมูลอินเทอร์เน็ตของคุณในลักษณะที่จะสามารถยกเลิกการแปลงสัญญาณ (ถอดรหัส) โดยใช้คีย์ที่ถูกต้องเท่านั้น ข้อมูลขาออกถูกเข้ารหัสก่อนที่จะออกจากอุปกรณ์ของคุณ จากนั้นจะถูกส่งไปยังเซิร์ฟเวอร์ VPN ซึ่งจะถอดรหัสข้อมูลด้วยรหัสที่เหมาะสม จากนั้นข้อมูลของคุณจะถูกส่งไปยังปลายทางเช่นเว็บไซต์ การเข้ารหัสจะป้องกันไม่ให้ใครก็ตามที่ดักจับข้อมูลระหว่างคุณกับเซิร์ฟเวอร์ VPN – ผู้ให้บริการอินเทอร์เน็ต, หน่วยงานราชการ, แฮ็กเกอร์ไร้สายเป็นต้น – ไม่สามารถถอดรหัสเนื้อหาได้.

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

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

ความแตกต่างระหว่างการเข้ารหัสชนิดต่าง ๆ รวมถึง:

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

ความปลอดภัย

ในระยะสั้น: ขอบเล็กน้อยในความโปรดปรานของ SSL.

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

SSL VPN ไม่มีปัญหานี้เนื่องจากใช้การเข้ารหัสแบบพับลิกคีย์เพื่อเจรจาจับมือและแลกเปลี่ยนคีย์การเข้ารหัสอย่างปลอดภัย แต่ TLS / SSL มีรายการช่องโหว่ของตัวเองเช่น Heartbleed.

SSL VPN บางตัวอนุญาตใบรับรองที่ไม่ได้ลงนามเองและไม่ยืนยันลูกค้า นี่เป็นเรื่องปกติโดยเฉพาะอย่างยิ่งในส่วนขยายเบราว์เซอร์ SSL VPN ที่“ ไม่มีไคลเอ็นต์” VPN เหล่านี้ที่อนุญาตให้ทุกคนเชื่อมต่อจากเครื่องใด ๆ มีความเสี่ยงต่อการโจมตีจากคนกลาง (MITM) อย่างไรก็ตามนี่ไม่ใช่กรณีของไคลเอนต์ OpenVPN ดั้งเดิม.

โดยทั่วไปแล้ว SSL ต้องการแพตช์บ่อยครั้งเพื่อให้ทันสมัยสำหรับทั้งเซิร์ฟเวอร์และไคลเอนต์.

การขาดรหัสโอเพนซอร์ซสำหรับโปรโตคอล VPN ที่ใช้ IPSec อาจเป็นปัญหาสำหรับผู้ที่ระวังสายลับและคนสอดแนมของรัฐบาล ในปี 2013 Edward Snowden เปิดเผยโปรแกรม Bullrun ของหน่วยงานความมั่นคงแห่งชาติของสหรัฐอเมริกาได้พยายามอย่างแข็งขันที่จะ“ แทรกช่องโหว่ในระบบเข้ารหัสเชิงพาณิชย์ระบบไอทีเครือข่ายและอุปกรณ์สื่อสารปลายทางที่ใช้งานโดยเป้าหมาย” NSA กล่าวหาว่า IPSec กำหนดเป้าหมาย แฮกเกอร์สามารถเอาเปรียบ.

ในที่สุดการรักษาความปลอดภัยที่แข็งแกร่งน่าจะเป็นผลมาจากผู้ดูแลระบบเครือข่ายที่มีทักษะและมีสติมากกว่าที่จะเลือกใช้โปรโตคอล.

การข้ามผ่านไฟร์วอลล์

ในระยะสั้น: VPNs ที่ใช้ SSL นั้นจะดีกว่าสำหรับการข้ามไฟร์วอลล์.

ไฟร์วอลล์ NAT มักจะมีอยู่ในเราเตอร์ไร้สายและฮาร์ดแวร์เครือข่ายอื่น ๆ เพื่อป้องกันภัยคุกคามพวกเขาจะทิ้งการรับส่งข้อมูลทางอินเทอร์เน็ตที่ไม่รู้จักซึ่งรวมถึงแพ็คเก็ตข้อมูลโดยไม่มีหมายเลขพอร์ต แพ็กเก็ต IPSec ที่เข้ารหัส (แพ็คเก็ต ESP) ไม่มีหมายเลขพอร์ตที่กำหนดไว้โดยค่าเริ่มต้นซึ่งหมายความว่าพวกเขาสามารถถูกดักจับในไฟร์วอลล์ NAT สิ่งนี้สามารถป้องกัน IPSec VPNs ไม่ให้ทำงาน.

ในการหลีกเลี่ยงปัญหานี้ IPSec VPNs จำนวนมากห่อหุ้มแพ็กเก็ต ESP ภายในแพ็คเก็ต UDP เพื่อให้ข้อมูลได้รับการกำหนดหมายเลขพอร์ต UDP โดยทั่วไปคือ UDP 4500 ขณะที่วิธีนี้แก้ปัญหาการแวะผ่าน NAT ไฟร์วอลล์เครือข่ายของคุณอาจไม่อนุญาตแพ็กเก็ตบนพอร์ตนั้น ผู้ดูแลระบบเครือข่ายที่โรงแรมสนามบินและสถานที่อื่น ๆ อาจอนุญาตให้มีการรับส่งข้อมูลบนโปรโตคอลที่จำเป็นบางอย่างเท่านั้นและ UDP 4500 อาจไม่ได้อยู่ในกลุ่มเดียวกัน.

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

ความเร็วและความน่าเชื่อถือ

ในระยะสั้น: ทั้งสองอย่างรวดเร็วพอสมควร แต่ IKEv2 / IPSec เจรจาเชื่อมต่อที่เร็วที่สุด.

โปรโตคอล VPN ที่ใช้ IPSec ส่วนใหญ่ใช้เวลานานกว่าในการต่อรองการเชื่อมต่อกว่าโปรโตคอลที่ใช้ SSL แต่นี่ไม่ใช่กรณีของ IKEv2 / IPSec.

IKEv2 เป็นโปรโตคอล VPN ที่ใช้ IPSec ซึ่งมีมานานกว่าทศวรรษ แต่ตอนนี้กำลังได้รับความนิยมจากผู้ให้บริการ VPN การขับเคลื่อนการปรับใช้คือความสามารถในการเชื่อมต่ออย่างรวดเร็วและเชื่อถือได้ทุกครั้งที่การเชื่อมต่อ VPN ถูกขัดจังหวะ สิ่งนี้ทำให้มีประโยชน์อย่างยิ่งสำหรับลูกค้ามือถือ iOS และ Android ที่ไม่มีการเชื่อมต่อที่เชื่อถือได้หรือผู้ที่สลับระหว่างข้อมูลมือถือและ wifi.

สำหรับปริมาณงานจริงมันเป็นการพลิกขึ้น เราเคยเห็นข้อโต้แย้งจากทั้งสองฝ่าย ในบล็อกโพสต์ NordVPN ระบุว่า IKEv2 / IPSec สามารถให้ปริมาณงานที่รวดเร็วกว่าคู่แข่งเช่น OpenVPN โปรโตคอลทั้งสองมักใช้รหัส AES แบบ 128 บิตหรือ 256 บิต.

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

สำหรับ VPNs สำหรับผู้บริโภคส่วนใหญ่ปริมาณงานจะถูกกำหนดโดยความแออัดของเซิร์ฟเวอร์และเครือข่ายมากกว่าโปรโตคอล VPN.

ดูสิ่งนี้ด้วย: VPN ที่เร็วที่สุด

สะดวกในการใช้

ในระยะสั้น: IPSec เป็นสากลมากขึ้น แต่ผู้ใช้ส่วนใหญ่ที่ใช้แอปของผู้ให้บริการ VPN จะไม่สังเกตเห็นความแตกต่างอย่างมาก.

IKEv2, SSTP และ L2TP เป็นโปรโตคอล VPN ที่ใช้ IPSec ในตัวบนระบบปฏิบัติการที่สำคัญที่สุดซึ่งหมายความว่าไม่จำเป็นต้องมีแอปพลิเคชันพิเศษในการติดตั้ง ผู้ใช้ VPN ของผู้ใช้ส่วนใหญ่จะยังคงใช้แอปของผู้ให้บริการเพื่อเชื่อมต่อ.

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

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

เมื่อพูดถึง VPN ขององค์กรที่ให้การเข้าถึงเครือข่ายของ บริษัท มากกว่าอินเทอร์เน็ตฉันทามติทั่วไปคือ IPSec นั้นดีกว่าสำหรับ VPN จากไซต์ถึงไซต์และ SSL นั้นดีกว่าสำหรับการเข้าถึงระยะไกล เหตุผลคือ IPSec ทำงานที่ Network Layer ของรุ่น OSI ซึ่งให้ผู้ใช้สามารถเข้าถึงเครือข่ายขององค์กรได้อย่างเต็มที่โดยไม่คำนึงถึงแอปพลิเคชัน เป็นการยากกว่าที่จะ จำกัด การเข้าถึงทรัพยากรเฉพาะ ในทางกลับกัน SSL VPNs ทำให้องค์กรต่างๆสามารถควบคุมการเข้าถึงระยะไกลในระดับที่ละเอียดสำหรับแอพพลิเคชั่นที่เฉพาะเจาะจง.

ผู้ดูแลระบบเครือข่ายที่ใช้งาน VPN มักจะพบว่าการจัดการลูกค้าง่ายกว่าและใช้เวลาน้อยกว่าด้วย SSL มากกว่าด้วย IPSec.

IPSec vs SSL VPN: ข้อสรุป

สรุปสำหรับผู้ใช้ VPN ที่มีทั้งสองตัวเลือกเราขอแนะนำให้ใช้ IKEv2 / IPSec ก่อนจากนั้นหันไปใช้ OpenVPN หากมีปัญหาเกิดขึ้น ความเร็วที่ IKEv2 สามารถต่อรองและสร้างการเชื่อมต่อจะนำเสนอการปรับปรุงคุณภาพชีวิตที่เป็นรูปธรรมมากขึ้นสำหรับผู้ใช้ VPN เฉลี่ยรายวันในขณะที่ให้ความปลอดภัยและความเร็วเทียบเท่า แต่มันอาจไม่ทำงานในทุกสถานการณ์.

OpenVPN / SSL จนกระทั่งเมื่อไม่นานมานี้ถือว่าเป็นชุด VPN ที่ดีที่สุดสำหรับผู้ใช้ VPN ส่วนใหญ่ของผู้ใช้ OpenVPN ซึ่งใช้ไลบรารี OpenSSL สำหรับการเข้ารหัสและการรับรองความถูกต้องมีความรวดเร็วปลอดภัยมากโอเพนซอร์สและสามารถท่อง NAT ไฟร์วอลล์ได้ สามารถรองรับ UDP หรือโปรโตคอล TCP.

IKEv2 / IPSec ขอเสนอผู้ท้าชิงใหม่สำหรับ OpenVPN การปรับปรุง L2TP และโปรโตคอลที่ใช้ IPSec อื่น ๆ ด้วยการเชื่อมต่อที่เร็วขึ้นเสถียรภาพมากขึ้นและการสนับสนุนในตัวบนอุปกรณ์ผู้บริโภครุ่นใหม่ล่าสุด.

ทั้ง SSL และ IPSec มีความปลอดภัยสูงพร้อมความเร็วในการรับส่งข้อมูลความปลอดภัยและความสะดวกในการใช้งานสำหรับลูกค้าส่วนใหญ่ของบริการ VPN เชิงพาณิชย์.

“ IPsec in de netwerklaag” โดย Soufiane Hamdaoui ได้รับใบอนุญาตภายใต้ CC BY-SA 3.0