OpenVPN eller IKEv2: fyra kontroller innan du väljer protokoll

Valet mellan OpenVPN och IKEv2 diskuteras oftast som en protokollfråga, och en sådan inramning slösar bort beslutet. Det som avgör är om servern och enheterna stöder samma kompletta profil, och om den profilen klarar hur du rör dig mellan nätverk. De två staplarna översätts inte till varandra: en OVPN-fil är inte en IKEv2-profil med annan syntax. Fyra kontroller, körda i ordning, besvarar frågan snabbare än någon funktionstabell.

En saknad klient avslutar diskussionen

Windows och macOS levereras med en IKEv2-klient, så en IKEv2-profil kostar inget extra att distribuera där och ärver de etableringsalternativ som operativsystemet redan erbjuder. OpenVPN på samma maskiner innebär en tredjepartsklient som måste installeras, uppdateras och stödjas, och den klienten måste acceptera varje alternativ som profilen använder. Räkna de plattformar du måste täcka in innan du jämför något annat, eftersom en plattform utan fungerande klient inte alls är en jämförelsepunkt.

I Windows listar ett kommando de profiler som redan finns och visar vilken typ var och en är. Namnet det skriver ut är namnet som de senare kontrollerna använder.

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

En begäran att installera en klient är det egentliga svaret för OpenVPN-kolumnen på dessa plattformar, och det är en distributionsuppgift och inte en protokollbegränsning. Ingen av lösningarna tar bort förtroendekontroller, identitetsverifiering eller underhåll. Fråga hur profiler distribueras, hur inloggningsuppgifter förnyas och hur en förlorad enhet tas bort innan du binder dig. En enkel installation kan fortfarande dölja en återställningsprocess som ingen vill köra på helgen.

Rörlighet är en gemensam inställning, inte ett protokollöfte

IKEv2 kan använda MOBIKE när båda ändarna stöder och aktiverar det, vilket låter en klient behålla sin tunnel medan adressen ändras. RFC 4555 definierar utökningen, och den villkorliga formuleringen spelar roll: en server som ignorerar förmågan förhandlar om i stället. Resultatet kan se identiskt ut för en filöverföring och mycket annorlunda för ett samtal i realtid.

Testa den övergång du faktiskt bryr dig om, med något som körs och som du kan följa. Låt ping -t <internal-host> köra i Windows, eller vanlig ping någon annanstans, byt sedan från Wi-Fi till mobilnät och leta efter avbrott. Ett MOBIKE-fel visas som fullständig omautentisering i klientloggen, inte som en tyst adressuppdatering. Det du mäter är om tunneln överlever ändringen, inte om protokollet annonserar stöd.

OpenVPN-klienter återansluter enligt sitt eget plattformsbeteende och profilens timers, så samma test kan ge en annan form av avbrott. Jämför händelsen som är viktig för dina användare, inte etiketten på protokollet.

Inloggningsuppgifter tillhör tjänsten, inte stapeln

Certifikat och andra inloggningsupplägg tillhör tjänsten som avslutar anslutningen. En lösenordsbegäran i en klient säger inget om kompatibilitet med en annan, och en profil som fungerar mot en annan gateway säger inget om den här. Håll reglerna för serveridentitet intakta medan du jämför de två staplarna. Att byta protokoll innan du har identifierat felet ger oftast en andra inkompatibel profil.

Granska den inloggningsuppgift som klienten kommer att presentera innan du skyller på något av protokollen, eftersom ett utgånget eller felaktigt utfärdat certifikat misslyckas på samma sätt på båda. Utdata nedan visar subjekt, utfärdare och giltighetsdatum utan att läsa den privata nyckeln.

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

Använd metoden som företaget publicerar för en företagsanslutning och sluta behandla jämförelsen som ett experiment. Om du jämför de två själv, kontrollera först om båda alternativen slutar på samma gateway, eftersom den enda detaljen avgör hur mycket av ditt resultat som handlar om protokollet. En avvisning som namnger inloggningsuppgiften är ett problem med inloggningsuppgiften, och ingen mängd protokollbyte reparerar det.

Kontrollera vad tunneln faktiskt routar

Efter anslutning, bekräfta att rutten du behöver finns och att namn löses upp. En profil som finns för interna resurser kan med avsikt lämna vanligt surfande på den lokala vägen, och det är ett policybeslut, inte ett fel. Det som spelar roll är om destinationerna ditt team använder nås genom tunneln.

I Windows täcker två kommandon rutten och namnsökningen. Linux-motsvarigheterna är ip route show default och resolvectl query <internal-host>.

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

En tunnel som kommer upp och inte routar något användbart är ett vanligt utfall när en profil kopierats mellan tjänster, och ett allmänt anslutningstest visar det inte eftersom gränssnittet är uppe. Testa resursen dina användare öppnar först, inte en offentlig adress som vilken väg som helst kan nå. Om namnet löses till en offentlig adress medan rutten pekar in i tunneln, tillhör DNS-svaret och rutten olika beslut och båda behöver rättas.

Väg underhållet efter kontrollerna

Inget av protokollen är mer underhållsvänligt i abstrakt mening. Underhåll beror på vem som driftar gatewayen, hur profiler når enheterna och hur snabbt en förlorad enhet förlorar åtkomst. En enkel slutpunktsklient kan stå framför en svårare server att drifta, och det motsatta händer också. Fråga vilket av de två ditt team kan hålla igång efter att personen som byggde det slutar.

Välj den anslutning som stöds och täcker arbetet, testa den sedan mot åtkomsten du faktiskt behöver, inte mot en funktionslista. Notera vilken gateway varje alternativ slutar på, eftersom två olika gatewayer gör jämförelsen lika mycket till en fråga om rutter som om protokoll. Upprepa de fyra kontrollerna på enheten du faktiskt kommer att bära, och behåll profilen som klarar sig på den.