OpenVPN หรือ WireGuard? ตัดสินจากตัวตนและเส้นทางขนส่ง
คีย์ ลำดับการเข้าสู่ระบบ และการขนส่งผ่าน UDP เท่านั้น กำหนดทางเลือกก่อนอัตราการส่งข้อมูลมากนัก ทำการตรวจสอบสี่ข้อและรักษาการวัดให้ซื่อตรง
การเปรียบเทียบสองโปรโตคอลนี้มีประโยชน์ก็ต่อเมื่อมันเปรียบเทียบสิ่งที่คุณจะใช้งานจริง WireGuard ระบุ peer ด้วยกุญแจสาธารณะและบรรทุกโปรโตคอลของตนผ่าน UDP ขณะที่ OpenVPN มีรูปแบบการพิสูจน์ตัวตนให้เลือกหลากหลายกว่า และทำงานผ่าน UDP หรือ TCP ได้เมื่อเซิร์ฟเวอร์มีให้ทั้งสองแบบ ความต่างเหล่านี้กำหนดการติดตั้งและเส้นทางสำรองก่อนที่จะกำหนดอัตราการส่งข้อมูลมากนัก ทำการตรวจสอบสี่ข้อด้านล่างตามลำดับ สองข้อแรกมักตัดสินทางเลือก และสองข้อหลังบอกว่าการตัดสินใจนั้นถูกต้องหรือไม่
เริ่มจากตัวตน ไม่ใช่จากรายการการเข้ารหัส
peer ของ WireGuard เก็บกุญแจส่วนตัวหนึ่งอันและแสดงรายการกุญแจสาธารณะที่เข้าถึงได้ ผู้ให้บริการอาจห่อหุ้มด้วยพอร์ทัลบัญชี แต่โปรโตคอลเองไม่มีการแลกเปลี่ยนชื่อผู้ใช้และรหัสผ่าน ดังนั้นวงจรชีวิตของบัญชีจึงอยู่ในสิ่งที่แจกจ่ายกุญแจ OpenVPN ใช้ใบรับรอง ส่วนเสริมกับไดเรกทอรีที่มีอยู่ หรือสคริปต์ตรวจสอบได้ จึงเป็นเหตุผลที่องค์กรที่มีระบบตัวตนมักเลือกใช้ ทั้งสองแบบไม่ได้ขจัดคำถามว่าเครื่องที่หายไปจะถูกถอดออกอย่างไร
| Decision | OpenVPN | WireGuard |
|---|---|---|
| Identity | Certificates, plugins or scripts against an existing directory | One private key per peer, public keys listed for the peers it may reach |
| Transport | UDP or TCP profiles when the server offers both | UDP only in the native protocol |
| Routing and DNS | Server pushes routes and DNS options | AllowedIPs maps ranges to peers, and tooling installs the routes |
| Where it usually breaks | Profile mismatch, expired certificate, failing plugin | Blocked UDP, wrong AllowedIPs, key not installed |
การตั้งค่าที่สั้นไม่เหมือนกับการติดตั้งที่ง่าย การให้กุญแจส่วนตัวหนึ่งอันแก่หลายคนทำให้การถอดออกภายหลังไม่ชัดเจน เพราะการเพิกถอนจะถอดทุกคนพร้อมกัน เขียนการจับคู่จากบุคคลไปยังกุญแจหรือใบรับรองก่อนเลือก แล้วการตัดสินใจเรื่องโปรโตคอลจะง่ายขึ้นมาก
จากนั้นดูว่าการขนส่งอนุญาตอะไร
โปรโตคอลของ WireGuard ใช้ UDP บริการ OpenVPN อาจมีโปรไฟล์ทั้ง UDP และ TCP และในเครือข่ายที่บล็อกหรือทำให้ UDP แย่ลง ตัวเลือกที่สองนั้นเป็นเส้นทางสำรองที่ใช้ได้จริง ไม่ใช่ทางทฤษฎี เซิร์ฟเวอร์ต้องรองรับโปรไฟล์ที่คุณเลือก และการเปลี่ยนหมายเลขพอร์ตไม่ได้ทำให้อุโมงค์กลายเป็น HTTPS หรือโน้มน้าวไฟร์วอลล์ให้อนุญาต
การบรรทุก TCP ไว้ใน TCP ก็เปลี่ยนพฤติกรรมเมื่อเกิดการสูญหายเพราะทั้งสองชั้นลองใหม่และจัดลำดับใหม่โดยอิสระ โปรไฟล์ TCP ที่ทำงานในเครือข่ายจำกัดอาจยังทำงานได้ไม่ดีในเครือข่ายที่มีการสูญหาย และนั่นเป็นเหตุผลให้เก็บทั้งสองโปรไฟล์ไว้ใช้แทนการประกาศว่าอันหนึ่งดีกว่า
จากนั้นตรวจสอบการกำหนดเส้นทางและการแปลงชื่อ
AllowedIPs ของ WireGuard จับคู่ช่วงที่อยู่กับ peer และทำหน้าที่เป็นการตัดสินใจกำหนดเส้นทางภายในโปรโตคอล และเครื่องมือรอบข้างใช้ช่วงเหล่านั้นเมื่อติดตั้งเส้นทาง OpenVPN ดันเส้นทางและตัวเลือก DNS จากเซิร์ฟเวอร์ ในทั้งสองกรณีไคลเอนต์อาจขึ้นมาได้ในขณะที่นโยบายที่ตั้งใจไว้ถูกใช้เพียงครึ่งเดียว
ip route show
ip -6 route show
resolvectl status
wg showอ่านผลลัพธ์ก่อนเชื่อตัวบ่งชี้การเชื่อมต่อ ip route show แสดงรายการที่ไคลเอนต์ติดตั้งสำหรับ IPv4 และรุ่น IPv6 จับอุโมงค์ที่บรรทุกเพียงตระกูลเดียว resolvectl status แสดงว่าไคลเอนต์จะถามตัวแปลงชื่อใดจริง ๆ และ wg show พิมพ์ AllowedIPs ที่ WireGuard คิดว่าเป็นของตน หากตัวแปลงชื่อยังชี้ไปที่เครือข่ายท้องถิ่นในขณะที่เส้นทางอ้างว่าครอบคลุมทั้งหมด DNS ก็ออกนอกอุโมงค์
จากนั้นวัดงานที่คุณใส่ใจ
ทำให้อุปกรณ์ เครือข่าย และปลายทางคงที่ และบันทึกไคลเอนต์กับปลายทางที่คุณใช้ หากสองบริการออกในเมืองต่างกันหรือทำงานบนฮาร์ดแวร์ต่างกัน ให้บอกไว้ เพราะผลลัพธ์จะอธิบายบริการเหล่านั้น ไม่ใช่โปรโตคอล
iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20เรียกใช้ทั้งสองคำสั่งสองครั้ง ครั้งละคู่โปรไฟล์ บนเครือข่ายและอุปกรณ์เดียวกัน iperf3 ให้ตัวเลขอัตราการส่งข้อมูล และ mtr ให้เส้นทางและจุดที่เกิดการสูญหาย ซึ่งตัวเลขดาวน์โหลดตัวเดียวแสดงไม่ได้ ตัวเลขดาวน์โหลดยังพลาดสิ่งที่การโทรสังเกตได้ คือความหน่วงที่เพิ่มขึ้น ความสั่นไหว และเวลาที่ใช้เชื่อมต่อใหม่ บันทึกสิ่งเหล่านี้แยกกัน เพราะโปรโตคอลที่ชนะด้านอัตราการส่งข้อมูลอาจแพ้ในงานที่คุณเรียกใช้จริง
สำหรับการเชื่อมต่อแบบมีการจัดการ ความเข้ากันได้ การสนับสนุน และภาระการต่ออายุอาจมีน้ำหนักกว่าความต่างเล็กน้อยในการวัด สำหรับทางออกส่วนบุคคล การบันทึกและเขตอำนาจของผู้ให้บริการสำคัญกว่าป้ายชื่อโปรโตคอล ทั้งสองโปรโตคอลบรรทุกการเชื่อมต่อที่ดีได้ บริการและการตั้งค่าของบริการเป็นตัวกำหนดว่าคุณได้อะไร
เขียนคู่โปรไฟล์ก่อนทดสอบ
เลือกโปรไฟล์หนึ่งสำหรับแต่ละโปรโตคอลก่อนวัด และเขียนว่าแต่ละอันควรทำอะไร เฉพาะซับเน็ตส่วนตัว หรือทราฟฟิกทั้งหมดผ่านทางออกที่ระบุ การทดสอบที่เปรียบเทียบโปรไฟล์อุโมงค์แยกกับโปรไฟล์อุโมงค์เต็มนั้นวัดโปรไฟล์ ไม่ใช่โปรโตคอล ใส่ชื่อไคลเอนต์ เวอร์ชันไคลเอนต์ และตำแหน่งทางออกไว้ในบันทึกเดียวกัน
จากนั้นเรียกใช้งานเดียวกันบนทั้งสอง บนเครือข่ายเดียวกัน ในเซสชันเดียวกัน หากอันหนึ่งเชื่อมต่อไม่ได้เลย ความล้มเหลวนั้นคือผลลัพธ์ และต้องอยู่ในบันทึกพร้อมเหตุผล เก็บบันทึกไว้กับเอกสารของบริการ เพื่อให้คนถัดไปเปรียบเทียบคู่เดียวกันแทนการเริ่มใหม่