Valget mellem OpenVPN og IKEv2 bliver som regel diskuteret som et protokolspørgsmål, og den ramme spilder beslutningen. Det afgørende er, om din server og dine enheder understøtter den samme komplette profil, og om den profil overlever den måde, du flytter dig mellem netværk på. De to stakke kan ikke oversættes til hinanden: en OVPN-fil er ikke en IKEv2-profil med en anden syntaks. Fire kontroller, udført i rækkefølge, besvarer spørgsmålet hurtigere end nogen funktionstabel.

En manglende klient afslutter diskussionen

Windows og macOS leveres med en IKEv2-klient, så en IKEv2-profil koster intet ekstra at udrulle der og arver de klargøringsmuligheder, som styresystemet allerede tilbyder. OpenVPN på de samme maskiner betyder en tredjepartsklient, der skal installeres, opdateres og understøttes, og den klient skal acceptere hver eneste mulighed, som profilen bruger. Tæl de platforme, du skal dække, før du sammenligner noget andet, for en platform uden en fungerende klient er slet ikke et sammenligningspunkt.

På Windows viser én kommando de profiler, der allerede findes, og hvilken type hver af dem er. Det navn, den udskriver, er det navn, som de senere kontroller bruger.

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

En opfordring til at installere en klient er det reelle svar for OpenVPN-kolonnen på de platforme, og det er en udrulningsopgave snarere end en protokolbegrænsning. Ingen af de to ordninger fjerner tillidskontroller, identitetsbekræftelse eller vedligeholdelse. Spørg, hvordan profiler distribueres, hvordan legitimationsoplysninger fornyes, og hvordan en tabt enhed fjernes, før du forpligter dig. En enkel installation kan stadig skjule en gendannelsesproces, som ingen vil køre i weekenden.

Mobilitet er en fælles indstilling, ikke et protokoløfte

IKEv2 kan bruge MOBIKE, når begge ender understøtter og aktiverer det, hvilket lader en klient beholde sin tunnel, mens dens adresse ændres. RFC 4555 definerer udvidelsen, og den betingede formulering er vigtig: en server, der ignorerer evnen, forhandler i stedet på ny. Resultatet kan se identisk ud ved en filoverførsel og meget anderledes ved et aktivt opkald.

Test den overgang, du faktisk bekymrer dig om, med noget kørende, som du kan følge med i. Lad ping -t <internal-host> køre på Windows, eller den almindelige ping andre steder, skift derefter fra Wi-Fi til mobildata, og hold øje med huller. En MOBIKE-fejl vises som en fuld genbekræftelse i klientloggen i stedet for en stille adresseopdatering. Det, du måler, er, om tunnelen overlever ændringen, ikke om protokollen reklamerer med understøttelse.

OpenVPN-klienter genopretter forbindelse efter deres egen platformadfærd og profilens timere, så den samme test kan give en anden form for afbrydelse. Sammenlign den hændelse, der betyder noget for dine brugere, ikke etiketten på protokollen.

Legitimationsoplysninger tilhører tjenesten, ikke stakken

Certifikater og andre loginordninger tilhører den tjeneste, der afslutter forbindelsen. En adgangskodeanmodning i én klient siger intet om kompatibilitet med en anden, og en profil, der virker mod en anden gateway, siger intet om denne. Bevar serverens identitetsregler intakte, mens du sammenligner de to stakke. At skifte protokol, før du har identificeret fejlen, giver som regel en anden inkompatibel profil.

Undersøg den legitimationsoplysning, klienten vil fremlægge, før du bebrejder nogen af protokollerne, for et udløbet eller forkert udstedt certifikat fejler på samme måde på begge. Nedenstående output viser emne, udsteder og gyldighedsdatoer uden at læse den private nøgle.

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

Brug den metode, virksomheden offentliggør, til en virksomhedsforbindelse, og hold op med at behandle sammenligningen som et eksperiment. Hvis du sammenligner de to for dig selv, så undersøg først, om begge muligheder ender på én gateway, for den ene detalje afgør, hvor meget af dit resultat der handler om protokollen. En afvisning, der navngiver legitimationsoplysningen, er et problem med legitimationsoplysningen, og ingen protokolskift vil reparere det.

Kontroller, hvad tunnelen faktisk ruter

Bekræft efter forbindelsen, at den rute, du har brug for, findes, og at navne opløses. En profil, der findes til interne ressourcer, kan bevidst lade almindelig browsing blive på den lokale vej, og det er en politikbeslutning snarere end en fejl. Det afgørende er, om de destinationer, dit team bruger, kan nås gennem tunnelen.

To kommandoer dækker ruten og navneopslaget på Windows. Linux-modstykkerne er ip route show default og resolvectl query <internal-host>.

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

En tunnel, der kommer op og ikke ruter noget nyttigt, er et almindeligt resultat, når en profil er kopieret mellem tjenester, og en generisk forbindelsestest vil ikke vise det, fordi grænsefladen er oppe. Test den ressource, dine brugere åbner først, ikke en offentlig adresse, som enhver vej kan nå. Hvis navnet opløses til en offentlig adresse, mens ruten peger ind i tunnelen, tilhører DNS-svaret og ruten forskellige beslutninger, og begge skal rettes.

Afvej vedligeholdelsen efter kontrollerne

Ingen af protokollerne er mere vedligeholdelsesvenlig i sig selv. Vedligeholdelsen afhænger af, hvem der driver gatewayen, hvordan profiler når enhederne, og hvor hurtigt en tabt enhed mister adgang. En simpel slutpunktsklient kan stå foran en sværere server at drive, og det modsatte sker også. Spørg, hvilken af de to dit team kan holde kørende, efter at personen, der byggede den, er væk.

Vælg den understøttede forbindelse, der dækker arbejdet, og test den derefter mod den adgang, du faktisk har brug for, i stedet for mod en funktionsliste. Noter, hvilken gateway hver mulighed ender på, for to forskellige gatewayer gør sammenligningen lige så meget til et spørgsmål om ruter som om protokoller. Gentag de fire kontroller på den enhed, du faktisk vil bære, og behold den profil, der består på den.

Relaterede artikler