OpenVPN, nebo IKEv2: čtyři kontroly, než zvolíte protokol

Volba mezi OpenVPN a IKEv2 se obvykle vede jako otázka protokolu a tento rámec rozhodnutí promrhává. Rozhoduje totiž, zda váš server a vaše zařízení podporují stejný úplný profil a zda tento profil přežije způsob, jakým se pohybujete mezi sítěmi. Oba stacky se do sebe nepřekládají: soubor OVPN není profil IKEv2 s jinou syntaxí. Čtyři kontroly provedené v pořadí odpoví na otázku rychleji než jakákoli tabulka funkcí.

Chybějící klient ukončí diskusi

Windows a macOS dodávají klienta IKEv2, takže profil IKEv2 tam nestojí nic navíc při nasazení a dědí možnosti zřizování, které operační systém už nabízí. OpenVPN na stejných strojích znamená klienta třetí strany k instalaci, aktualizaci a podpoře a tento klient musí přijmout každou možnost, kterou profil používá. Spočítejte platformy, které musíte pokrýt, než začnete cokoli jiného srovnávat, protože platforma bez funkčního klienta není vůbec srovnávacím bodem.

Ve Windows jeden příkaz vypíše profily, které už existují, a ukáže, jakého typu každý je. Název, který vypíše, je název, který používají pozdější kontroly.

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

Výzva k instalaci klienta je skutečnou odpovědí pro sloupec OpenVPN na těchto platformách a jde o úkol nasazení, nikoli omezení protokolu. Ani jedno uspořádání neodstraňuje kontroly důvěry, ověřování identity ani údržbu. Ptejte se, jak se profily distribuují, jak se obnovují přihlašovací údaje a jak se odebere ztracené zařízení, než se zavážete. Jednoduchá instalace může stále skrývat proces obnovy, který o víkendu nikdo nechce spouštět.

Mobilita je společné nastavení, ne slib protokolu

IKEv2 může použít MOBIKE, když ho obě strany podporují a zapnou, což klientovi umožní udržet tunel, zatímco se mu mění adresa. RFC 4555 toto rozšíření definuje a podmíněná formulace je důležitá: server, který tuto schopnost ignoruje, místo toho znovu vyjednává. Výsledek může vypadat stejně při přenosu souboru a velmi odlišně během živého hovoru.

Otestujte přechod, na kterém vám skutečně záleží, s něčím spuštěným, co můžete sledovat. Nechte ping -t <internal-host> běžet ve Windows, nebo obyčejný ping jinde, pak přejděte z Wi-Fi na mobilní síť a sledujte mezery. Selhání MOBIKE se v protokolu klienta objeví jako úplné opětovné ověření, nikoli jako tiché obnovení adresy. Měříte, zda tunel změnu přežije, ne zda protokol inzeruje podporu.

Klienti OpenVPN se znovu připojují podle vlastního chování platformy a časovačů profilu, takže stejný test může dát jiný tvar přerušení. Srovnávejte událost, která je důležitá pro vaše uživatele, ne štítek na protokolu.

Přihlašovací údaje patří službě, ne stacku

Certifikáty a další způsoby přihlášení patří službě, která ukončuje spojení. Výzva k zadání hesla v jednom klientovi nic neříká o kompatibilitě s jiným a profil, který funguje proti jiné bráně, nic neříká o této. Zachovejte pravidla identity serveru nedotčená, když oba stacky srovnáváte. Změna protokolu dřív, než jste závadu určili, obvykle vytvoří druhý nekompatibilní profil.

Prohlédněte si přihlašovací údaj, který klient předloží, dřív než obviníte kterýkoli z protokolů, protože propadlý nebo špatně vydaný certifikát selhává u obou stejně. Výstup níže ukazuje subjekt, vydavatele a data platnosti, aniž by četl soukromý klíč.

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

Pro firemní připojení použijte metodu, kterou firma zveřejňuje, a přestaňte srovnání brát jako experiment. Pokud obě možnosti srovnáváte sami pro sebe, nejprve zkontrolujte, zda obě končí na jedné bráně, protože tento jediný detail rozhoduje, jak velká část vašeho výsledku je o protokolu. Odmítnutí, které pojmenuje přihlašovací údaj, je problém údaje a žádná změna protokolu ho nespraví.

Zkontrolujte, co tunel skutečně směruje

Po připojení ověřte, že trasa, kterou potřebujete, existuje a že se názvy překládají. Profil, který existuje pro interní zdroje, může běžné prohlížení záměrně nechat na místní cestě, a to je rozhodnutí politiky, ne závada. Důležité je, zda jsou cíle, které váš tým používá, dostupné tunelem.

Dva příkazy pokrývají trasu a vyhledávání názvů ve Windows. Ekvivalenty v Linuxu jsou ip route show default a resolvectl query <internal-host>.

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

Tunel, který naskočí a nesměruje nic užitečného, je častý výsledek, když byl profil zkopírován mezi službami, a obecný test konektivity to neukáže, protože rozhraní je aktivní. Testujte zdroj, který vaši uživatelé otevírají první, ne veřejnou adresu, na kterou se dostane každá cesta. Pokud se název přeloží na veřejnou adresu, zatímco trasa ukazuje do tunelu, odpověď DNS a trasa patří k různým rozhodnutím a obě je třeba opravit.

Po kontrolách zvažte údržbu

Ani jeden z protokolů není v abstraktu udržovatelnější. Údržba závisí na tom, kdo provozuje bránu, jak se profily dostávají do zařízení a jak rychle ztracené zařízení ztratí přístup. Jednoduchý koncový klient může stát před serverem, který se hůř provozuje, a opak se také stává. Zeptejte se, který z těch dvou váš tým udrží v provozu poté, co odejde člověk, který ho postavil.

Vyberte podporované připojení, které práci pokryje, a pak ho otestujte proti přístupu, který skutečně potřebujete, ne proti seznamu funkcí. Zaznamenejte, na které bráně každá možnost končí, protože dvě různé brány dělají srovnání stejně tak o trasách jako o protokolech. Zopakujte čtyři kontroly na zařízení, které skutečně budete nosit, a ponechte si profil, který na něm projde.