OpenVPN หรือ IKEv2: สี่การตรวจสอบก่อนเลือกโปรโตคอล

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

ไคลเอนต์ที่ขาดหายทำให้การถกเถียงจบลง

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

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

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

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

ความคล่องตัวเป็นการตั้งค่าร่วม ไม่ใช่คำสัญญาของโปรโตคอล

IKEv2 ใช้ MOBIKE ได้เมื่อทั้งสองฝั่งรองรับและเปิดใช้งาน ซึ่งช่วยให้ไคลเอนต์รักษาอุโมงค์ไว้ได้ขณะที่ที่อยู่เปลี่ยนไป RFC 4555 นิยามส่วนขยายนี้ และถ้อยคำแบบมีเงื่อนไขสำคัญ: เซิร์ฟเวอร์ที่ไม่สนใจความสามารถนี้จะเจรจาใหม่แทน ผลลัพธ์อาจดูเหมือนกันสำหรับการถ่ายโอนไฟล์และต่างกันมากสำหรับการโทรสด

ทดสอบการเปลี่ยนผ่านที่คุณสนใจจริง ๆ โดยมีบางอย่างทำงานอยู่และคุณเฝ้าดูได้ ปล่อยให้ ping -t <internal-host> ทำงานบน Windows หรือ ping ธรรมดาที่อื่น จากนั้นสลับจาก Wi-Fi ไปยังเครือข่ายมือถือและเฝ้าดูช่วงที่ขาดหาย ความล้มเหลวของ MOBIKE ปรากฏเป็นการยืนยันตัวตนใหม่ทั้งหมดในบันทึกของไคลเอนต์ ไม่ใช่การอัปเดตที่อยู่แบบเงียบ ๆ สิ่งที่คุณวัดคืออุโมงค์ทนต่อการเปลี่ยนแปลงหรือไม่ ไม่ใช่โปรโตคอลโฆษณาการรองรับหรือไม่

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

ข้อมูลรับรองเป็นของบริการ ไม่ใช่ของสแตก

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

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

ตรวจสอบว่าอุโมงค์กำหนดเส้นทางอะไรจริง ๆ

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

บน Windows มีสองคำสั่งครอบคลุมเส้นทางและการค้นหาชื่อ ใน Linux คำสั่งที่เทียบเท่าคือ ip route show default และ resolvectl query <internal-host>

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

ชั่งน้ำหนักการบำรุงรักษาหลังการตรวจสอบ

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

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