OpenVPN eller IKEv2: fire kontrollar før du vel protokoll

Valet mellom OpenVPN og IKEv2 blir oftast drøfta som eit protokollspørsmål, og ei slik innramming sløser bort avgjerda. Det som avgjer, er om tenaren og einingane dine støttar same komplette profil, og om den profilen toler måten du flyttar deg mellom nettverk på. Dei to stakkane blir ikkje omsette til kvarandre: ei OVPN-fil er ikkje ein IKEv2-profil med annan syntaks. Fire kontrollar, køyrde i rekkjefølgje, svarar på spørsmålet raskare enn noka funksjonstabell.

Ein manglande klient avsluttar diskusjonen

Windows og macOS kjem med ein IKEv2-klient, så ein IKEv2-profil kostar ingenting ekstra å rulle ut der og arvar klargjeringsvala operativsystemet alt tilbyr. OpenVPN på dei same maskinene tyder ein tredjepartsklient som må installerast, oppdaterast og støttast, og den klienten må godta kvart val profilen brukar. Tel plattformane du må dekkje før du samanliknar noko anna, fordi ein plattform utan ein fungerande klient ikkje er eit samanlikningspunkt i det heile.

På Windows listar éin kommando opp profila som alt finst og viser kva type kvar av dei er. Namnet han skriv ut, er namnet dei seinare kontrollane brukar.

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

Ein førespurnad om å installere ein klient er det eigentlege svaret for OpenVPN-kolonnen på desse plattformane, og det er ei distribusjonsoppgåve og ikkje ei protokollavgrensing. Ingen av ordningane fjernar tillitskontrollar, identitetsstadfesting eller vedlikehald. Spør korleis profilar blir distribuerte, korleis legitimasjon blir fornya og korleis ei tapt eining blir fjerna før du forpliktar deg. Ein enkel installasjon kan framleis gøyme ein gjenopprettingsprosess ingen vil køyre i helga.

Mobilitet er ei felles innstilling, ikkje eit protokolløfte

IKEv2 kan bruke MOBIKE når båe endar støttar og aktiverer det, noko som lèt ein klient halde på tunnelen medan adressa hans endrar seg. RFC 4555 definerer utvidinga, og den vilkårlege ordlyden er viktig: ein tenar som ignorerer eigenskapen, forhandlar på nytt i staden. Resultatet kan sjå identisk ut for ei filoverføring og svært ulikt for ein direkte samtale.

Test overgangen du faktisk bryr deg om, med noko som køyrer og som du kan følgje med på. Lat ping -t <internal-host> gå på Windows, eller vanleg ping andre stader, byt deretter frå Wi-Fi til mobilnett og sjå etter avbrot. Ein MOBIKE-feil viser seg som full reautentisering i klientloggen, ikkje som ei stille adresseoppdatering. Det du måler er om tunnelen overlever endringa, ikkje om protokollen annonserer støtte.

OpenVPN-klientar koplar til på nytt etter eiga plattformåtferd og tidsur for profilen, så same test kan gje ei anna form for avbrot. Samanlikn hendinga som betyr noko for brukarane dine, ikkje etiketten på protokollen.

Legitimasjon høyrer til tenesta, ikkje til stakken

Sertifikat og andre innloggingsordningar høyrer til tenesta som avsluttar tilkoplinga. Ein passordførespurnad i éin klient seier ingenting om kompatibilitet med ein annan, og ein profil som verkar mot ein annan gateway, seier ingenting om denne. Hald reglane for tenaridentitet intakte medan du samanliknar dei to stakkane. Å byte protokoll før du har identifisert feilen gjev vanlegvis ein andre inkompatibel profil.

Gransk legitomasjonen klienten vil presentere før du klandrar nokon av protokollane, fordi eit utløpt eller feil utstedt sertifikat feilar på same måte på båe. Utdataa nedanfor viser subjekt, utferdar og gyldigheitsdatoar utan å lese den private nøkkelen.

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

For ei bedriftstilkopling, bruk metoden bedrifta publiserer, og slutt å handsame samanlikninga som eit eksperiment. Viss du samanliknar dei to sjølv, sjekk først om båe alternativa endar på éin gateway, fordi den eine detaljen avgjer kor mykje av resultatet ditt som handlar om protokollen. Ei avvising som namngjev legitomasjonen, er eit legitomasjonsproblem, og inga mengd protokollbyte reparerer det.

Sjekk kva tunnelen faktisk rutar

Etter tilkopling, stadfest at ruta du treng finst og at namn blir løyste opp. Ein profil som finst for interne ressursar, kan med vilje la vanleg nettlesing bli på den lokale vegen, og det er ei policyavgjerd, ikkje ein feil. Det som betyr noko, er om destinasjonane teamet ditt brukar, er nåbare gjennom tunnelen.

På Windows dekkjer to kommandoar ruta og namneoppslaget. Linux-ekvivalentane er ip route show default og resolvectl query <internal-host>.

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

Ein tunnel som kjem opp og ikkje rutar noko nyttig, er eit vanleg utfall når ein profil er kopiert mellom tenester, og ein generell tilkoplingstest vil ikkje vise det fordi grensesnittet er oppe. Test ressursen brukarane dine opnar først, ikkje ei offentleg adresse som kvar veg kan nå. Viss namnet blir løyst til ei offentleg adresse medan ruta peikar inn i tunnelen, høyrer DNS-svaret og ruta til ulike avgjerder, og båe må rettast.

Vei vedlikehaldet etter kontrollane

Ingen av protokollane er meir vedlikehaldsvennlege i abstrakt forstand. Vedlikehald avheng av kven som driftar gatewayen, korleis profilar når einingane og kor raskt ei tapt eining mistar tilgang. Ein enkel endepunktklient kan stå framfor ein vanskelegare tenar å drifte, og det motsette skjer òg. Spør kva av dei to teamet ditt kan halde i drift etter at personen som bygde han, sluttar.

Vel den støtta tilkoplinga som dekkjer arbeidet, og test henne deretter mot tilgangen du faktisk treng, ikkje mot ei funksjonsliste. Noter kva gateway kvart alternativ endar på, fordi to ulike gatewayar gjer samanlikninga like mykje til eit spørsmål om ruter som om protokollar. Gjenta dei fire kontrollane på eininga du faktisk vil bere, og hald på profilen som passerer på henne.