OpenVPN o WireGuard? Magpasya batay sa pagkakakilanlan at transport

Ang paghahambing sa dalawang protocol na ito ay kapaki-pakinabang lamang kung inihahambing nito ang aktuwal mong patatakbuhin. Kinikilala ng WireGuard ang mga peer sa pamamagitan ng public key at dinadala ang protocol nito sa UDP, samantalang OpenVPN nag-aalok ng mas malawak na hanay ng mga paraan ng pagpapatotoo at maaaring tumakbo sa UDP o TCP kapag ibinibigay ng server ang dalawa. Hinuhubog ng mga pagkakaibang ito ang paghahanda at ang alternatibong ruta bago pa hubugin ang throughput. Isagawa ang apat na pagsusuri sa ibaba nang sunod-sunod; karaniwang ang unang dalawa ang nagpapasya sa pagpili, at ang huling dalawa ang nagsasabi kung tama ang desisyon.

Magsimula sa pagkakakilanlan, hindi sa listahan ng cipher

Ang isang peer ng WireGuard ay nag-iimbak ng isang pribadong susi at inililista ang mga pampublikong susi na maaari nitong maabot. Maaaring balutin ito ng provider ng portal ng account, ngunit ang protocol mismo ay walang palitan ng username at password, kaya nabubuhay ang lifecycle ng account sa kung ano ang namamahagi ng mga susi. Maaaring gumamit ang OpenVPN ng mga sertipiko, plugin laban sa umiiral na direktoryo o script ng beripikasyon, at iyon ang dahilan kung bakit madalas itong pinipili ng mga organisasyong may sistema ng pagkakakilanlan. Wala sa dalawang disenyo ang nag-aalis ng tanong kung paano tinatanggal ang nawawalang device.

Ang maikling configuration ay hindi kapareho ng simpleng paghahanda. Ang pagbibigay ng isang pribadong susi sa maraming tao ay ginagawang malabo ang pagtanggal sa hinaharap, dahil ang pagbawi nito ay tinatanggal silang lahat nang sabay. Isulat ang pagmamapa mula sa tao patungo sa susi o sertipiko bago pumili, at ang desisyon sa protocol ay magiging mas madali.

Pagkatapos tingnan kung ano ang pinapayagan ng transport

Gumagamit ng UDP ang protocol ng WireGuard. Ang mga serbisyo ng OpenVPN ay maaaring mag-alok ng parehong UDP at TCP profile, at sa network na humaharang o nagpapababa sa UDP ang pangalawang pagpipilian ay praktikal na alternatibong ruta at hindi teoretikal. Dapat suportahan ng server ang profile na pipiliin mo, at ang pagpapalit ng port number ay hindi ginagawang HTTPS ang tunnel o nakakakumbinsi sa firewall na payagan ito.

Ang pagdadala ng TCP sa loob ng TCP ay nagbabago rin ng gawi kapag may pagkawala, dahil ang dalawang layer ay nag-uulit at nag-aayos muli nang nakapag-iisa. Ang TCP profile na gumagana sa mahigpit na network ay maaaring mahinang gumana sa network na may pagkawala, at iyon ay dahilan upang panatilihing available ang dalawang profile sa halip na ideklarang superyor ang isa.

Pagkatapos suriin ang routing at paglutas ng pangalan

Ang AllowedIPs ng WireGuard ay nagmamapa ng mga saklaw ng address sa mga peer at nagsisilbing desisyon sa routing sa loob ng protocol, at ginagamit ng mga kasangkapan sa paligid ang mga saklaw na iyon kapag nag-i-install ng mga ruta. Itinutulak ng OpenVPN ang mga ruta at opsyon ng DNS mula sa server. Sa dalawang kaso, maaaring bumangon ang client habang ang nilalayong patakaran ay kalahati pa lamang na nailalapat.

ip route show
ip -6 route show
resolvectl status
wg show

Basahin ang output bago magtiwala sa indicator ng koneksyon. Inililista ng ip route show kung ano ang ininstalla ng client para sa IPv4, at nahuhuli ng variant na IPv6 ang tunnel na nagdadala lamang ng isang pamilya. Ipinapakita ng resolvectl status kung aling resolver ang talagang tatanungin ng client, at ipinapakita ng wg show ang AllowedIPs na inaakalang pagmamay-ari ng WireGuard. Kung ang resolver ay nakaturo pa rin sa lokal na network habang inaangkin ng mga ruta ang buong saklaw, lumalabas ang DNS sa labas ng tunnel.

Pagkatapos sukatin ang gawaing mahalaga sa iyo

Panatilihing hindi nagbabago ang device, network at destinasyon, at itala ang mga client at endpoint na ginamit mo. Kung ang dalawang serbisyo ay lumalabas sa magkaibang lungsod o tumatakbo sa magkaibang hardware, sabihin ito, dahil ang resulta ay naglalarawan sa mga serbisyong iyon at hindi sa mga protocol.

iperf3 -c 203.0.113.20 -t 30
mtr -rwzbc 50 203.0.113.20

Patakbuhin ang dalawang utos nang dalawang beses, isa para sa bawat pares ng profile, sa parehong network at device. Nagbibigay ang iperf3 ng pigura ng throughput, at nagbibigay ang mtr ng landas at kung saan lumilitaw ang pagkawala, na hindi maipapakita ng isang pigura ng download. Nakakalampas din ang pigura ng download sa napapansin ng tawag: dagdag na latency, jitter at gaano katagal ang muling pagkonekta. Itala ang mga ito nang hiwalay, dahil ang protocol na nananalo sa throughput ay maaaring matalo pa rin sa gawaing talagang pinapatakbo mo.

Para sa pinamamahalaang koneksyon, ang pagiging tugma, suporta at pagsisikap sa pag-renew ay maaaring mabigat kaysa sa maliit na pagkakaiba sa benchmark. Para sa personal na labasan, mas mahalaga ang pag-log at hurisdiksyon ng operator kaysa sa label ng protocol. Ang dalawang protocol ay makakadala ng magandang koneksyon; ang serbisyo at ang configuration nito ang nagpapasya sa makukuha mo.

Isulat ang pares ng profile bago mag-test

Pumili ng isang profile sa bawat protocol bago magsukat, at isulat kung ano ang dapat gawin ng bawat isa: pribadong subnet lamang, o lahat ng trapik na may partikular na labasan. Ang test na naghahambing ng split-tunnel profile sa full-tunnel profile ay nagsusukat ng mga profile, hindi ng mga protocol. Ilagay ang pangalan ng client, bersyon ng client at lokasyon ng labasan sa parehong tala.

Pagkatapos patakbuhin ang parehong gawain sa dalawa, sa parehong network, sa parehong session. Kung ang isa ay talagang hindi makakonekta, ang kabiguang iyon ang resulta at kabilang ito sa tala kasama ang dahilan. Itago ang tala kasama ang dokumentasyon ng serbisyo upang ihambing ng susunod na tao ang parehong pares sa halip na magsimulang muli.