OpenVPN eller IKEv2: fire kontroller før du velger protokoll

Valget mellom OpenVPN og IKEv2 blir vanligvis diskutert som et protokollspørsmål, og en slik innramming sløser bort beslutningen. Det som avgjør er om serveren og enhetene dine støtter samme komplette profil, og om den profilen tåler måten du beveger deg mellom nettverk. De to stakkene oversettes ikke til hverandre: en OVPN-fil er ikke en IKEv2-profil med annen syntaks. Fire kontroller, kjørt i rekkefølge, svarer på spørsmålet raskere enn noen funksjonstabell.

En manglende klient avslutter diskusjonen

Windows og macOS leveres med en IKEv2-klient, så en IKEv2-profil koster ingenting ekstra å rulle ut der og arver klargjøringsalternativene operativsystemet allerede tilbyr. OpenVPN på de samme maskinene betyr en tredjepartsklient som må installeres, oppdateres og støttes, og den klienten må godta hvert alternativ profilen bruker. Tell plattformene du må dekke før du sammenligner noe annet, fordi en plattform uten en fungerende klient ikke er et sammenligningspunkt i det hele tatt.

På Windows lister én kommando opp profilene som allerede finnes og viser hvilken type hver av dem er. Navnet den skriver ut, er navnet de senere kontrollene bruker.

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

En forespørsel om å installere en klient er det egentlige svaret for OpenVPN-kolonnen på disse plattformene, og det er en distribusjonsoppgave og ikke en protokollbegrensning. Ingen av ordningene fjerner tillitskontroller, identitetsbekreftelse eller vedlikehold. Spør hvordan profiler distribueres, hvordan legitimasjon fornyes og hvordan en tapt enhet fjernes før du forplikter deg. En enkel installasjon kan fortsatt skjule en gjenopprettingsprosess ingen vil kjøre i helgen.

Mobilitet er en felles innstilling, ikke et protokolløfte

IKEv2 kan bruke MOBIKE når begge ender støtter og aktiverer det, noe som lar en klient beholde tunnelen mens adressen endres. RFC 4555 definerer utvidelsen, og den betingede ordlyden er viktig: en server som ignorerer egenskapen, forhandler på nytt i stedet. Resultatet kan se identisk ut for en filoverføring og svært forskjellig for en direktesamtale.

Test overgangen du faktisk bryr deg om, med noe som kjører og som du kan følge med på. La ping -t <internal-host> gå på Windows, eller vanlig ping andre steder, bytt deretter fra Wi-Fi til mobilnett og se etter avbrudd. En MOBIKE-feil vises som full reautentisering i klientloggen, ikke som en stille adresseoppdatering. Det du måler er om tunnelen overlever endringen, ikke om protokollen annonserer støtte.

OpenVPN-klienter kobler til på nytt etter egen plattformatferd og profilens tidsur, så samme test kan gi en annen form for avbrudd. Sammenlign hendelsen som betyr noe for brukerne dine, ikke etiketten på protokollen.

Legitimasjon tilhører tjenesten, ikke stakken

Sertifikater og andre innloggingsordninger tilhører tjenesten som avslutter tilkoblingen. En passordforespørsel i én klient sier ingenting om kompatibilitet med en annen, og en profil som virker mot en annen gateway, sier ingenting om denne. Hold reglene for serveridentitet intakte mens du sammenligner de to stakkene. Å bytte protokoll før du har identifisert feilen gir vanligvis en andre inkompatibel profil.

Undersøk legitimasjonen klienten vil presentere før du klandrer noen av protokollene, fordi et utløpt eller feil utstedt sertifikat feiler på samme måte på begge. Utdataene nedenfor viser subjekt, utsteder og gyldighetsdatoer uten å lese den private nøkkelen.

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

For en bedriftstilkobling, bruk metoden bedriften publiserer, og slutt å behandle sammenligningen som et eksperiment. Hvis du sammenligner de to selv, sjekk først om begge alternativene ender på én gateway, fordi den ene detaljen avgjør hvor mye av resultatet ditt som handler om protokollen. En avvisning som navngir legitimasjonen, er et legitimasjonsproblem, og ingen mengde protokollbytte reparerer det.

Sjekk hva tunnelen faktisk ruter

Etter tilkobling, bekreft at ruten du trenger finnes og at navn løses opp. En profil som finnes for interne ressurser, kan med vilje la vanlig nettlesing bli på den lokale veien, og det er en policybeslutning, ikke en feil. Det som betyr noe, er om destinasjonene teamet ditt bruker, er nåbare gjennom tunnelen.

På Windows dekker to kommandoer ruten og navneoppslaget. Linux-ekvivalentene er ip route show default og resolvectl query <internal-host>.

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

En tunnel som kommer opp og ikke ruter noe nyttig, er et vanlig utfall når en profil er kopiert mellom tjenester, og en generell tilkoblingstest vil ikke vise det fordi grensesnittet er oppe. Test ressursen brukerne dine åpner først, ikke en offentlig adresse som enhver vei kan nå. Hvis navnet løses til en offentlig adresse mens ruten peker inn i tunnelen, tilhører DNS-svaret og ruten forskjellige beslutninger, og begge må rettes.

Vei vedlikeholdet etter kontrollene

Ingen av protokollene er mer vedlikeholdsvennlige i abstrakt forstand. Vedlikehold avhenger av hvem som drifter gatewayen, hvordan profiler når enhetene og hvor raskt en tapt enhet mister tilgang. En enkel endepunktklient kan stå foran en vanskeligere server å drifte, og det motsatte skjer også. Spør hvilken av de to teamet ditt kan holde i drift etter at personen som bygde den, slutter.

Velg den støttede tilkoblingen som dekker arbeidet, og test den deretter mot tilgangen du faktisk trenger, ikke mot en funksjonsliste. Noter hvilken gateway hvert alternativ ender på, fordi to forskjellige gatewayer gjør sammenligningen like mye til et spørsmål om ruter som om protokoller. Gjenta de fire kontrollene på enheten du faktisk vil bære, og behold profilen som passerer på den.