OpenVPN aŭ IKEv2: kvar kontroloj antaŭ ol elekti protokolon

La elekto inter OpenVPN kaj IKEv2 kutime diskutiĝas kiel protokola demando, kaj tiu kadro malŝparas la decidon. Kion ĝi efektive decidas, estas ĉu via servilo kaj viaj aparatoj subtenas la saman kompletan profilon kaj ĉu tiu profilo postvivas la manieron, kiel vi moviĝas inter retoj. La du stakoj ne tradukiĝas unu en la alian: OVPN-dosiero ne estas IKEv2-profilaĵo kun alia sintakso. Kvar kontroloj, plenumitaj laŭ ordo, respondas la demandon pli rapide ol ia ajn trajto-tabelo.

Mankanta kliento finas la diskuton

Windows kaj macOS liveras IKEv2-klienton, do IKEv2-profilaĵo kostas nenion plian por deploji tie kaj heredas la provizajn opciojn, kiujn la operaciumo jam proponas. OpenVPN sur la samaj maŝinoj signifas triapartan klienton por instali, ĝisdatigi kaj subteni, kaj tiu kliento devas akcepti ĉiun opcion, kiun la profilo uzas. Kalkulu la platformojn, kiujn vi devas kovri, antaŭ ol kompari ion ajn alian, ĉar platformo sen funkcianta kliento tute ne estas kompara punkto.

En Windows unu komando listigas la profilojn, kiuj jam ekzistas, kaj montras, kia tipo estas ĉiu. La nomo, kiun ĝi presas, estas la nomo, kiun uzas la postaj kontroloj.

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

La peto instali klienton estas la reala respondo por la kolumno OpenVPN sur tiuj platformoj, kaj ĝi estas tasko pri deplojado, ne limigo de protokolo. Neniu el la du aranĝoj forigas fidokontrolojn, identecan konfirmon aŭ prizorgadon. Demandu, kiel profiloj estas disdonataj, kiel akreditaĵoj renoviĝas kaj kiel perdita aparato estas forigata, antaŭ ol vi sindevigas. Simpla instalo ankoraŭ povas kaŝi rekuperan procezon, kiun neniu volas ruli dum la semajnfino.

Mobileco estas komuna agordo, ne promeso de protokolo

IKEv2 povas uzi MOBIKE, kiam ambaŭ finoj subtenas kaj ebligas ĝin, kio lasas klienton teni sian tunelon dum ĝia adreso ŝanĝiĝas. RFC 4555 difinas la etendaĵon, kaj la kondiĉa vortigo gravas: servilo, kiu ignoras la kapablon, anstataŭe renegocias. La rezulto povas aspekti identa ĉe dosiera transdono kaj tre malsama ĉe aktiva voko.

Testu la transiron, kiu vere gravas al vi, kun io funkcianta, kiun vi povas observi. Lasu ping -t <internal-host> daŭrigi en Windows, aŭ la ordinaran ping aliloke, poste ŝanĝu de Wi-Fi al poŝtelefona reto kaj observu paŭzojn. MOBIKE-malsukceso aperas en la klienta protokolo kiel plena reaŭtentigo anstataŭ kvieta adresa ĝisdatigo. Kion vi mezuras, estas ĉu la tunelo postvivas la ŝanĝon, ne ĉu la protokolo reklamas subtenon.

OpenVPN-klientoj rekonektiĝas laŭ sia propra platforma konduto kaj la tempigiloj de la profilo, do la sama testo povas doni alian formon de interrompo. Komparu la eventon, kiu gravas por viaj uzantoj, ne la etikedon sur la protokolo.

Akreditaĵoj apartenas al la servo, ne al la stako

Atestiloj kaj aliaj ensalutaj aranĝoj apartenas al la servo, kiu finas la konekton. Pasvorta peto en unu kliento diras nenion pri kongrueco kun alia, kaj profilo, kiu funkcias kontraŭ alia enirejo, diras nenion pri ĉi tiu. Konservu la regulojn de servila identeco sendifektaj, dum vi komparas la du stakojn. Ŝanĝi protokolon antaŭ ol vi identigis la paneon kutime produktas duan malkongruan profilon.

Ekzamenu la akreditaĵon, kiun la kliento prezentos, antaŭ ol kulpigi iun el la du protokoloj, ĉar eksdata aŭ malĝuste eldonita atestilo malsukcesas same ĉe ambaŭ. La suba eligilo montras subjekton, eldoninton kaj validigajn datojn sen legi la privatan ŝlosilon.

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

Por firmaa konekto uzu la metodon, kiun la firmao publikigas, kaj ĉesu trakti la komparon kiel eksperimenton. Se vi komparas la du por vi mem, unue kontrolu, ĉu ambaŭ opcioj finiĝas ĉe unu enirejo, ĉar tiu sola detalo decidas, kiom de via rezulto temas pri la protokolo. Rifuzo, kiu nomas la akreditaĵon, estas problemo de akreditaĵo, kaj neniu protokola ŝanĝo riparos ĝin.

Kontrolu, kion la tunelo efektive enkursigas

Post konekto konfirmu, ke la bezonata itinero ekzistas kaj ke nomoj solviĝas. Profilo, kiu ekzistas por internaj rimedoj, povas laŭplane lasi ordinaran retumadon sur la loka vojo, kaj tio estas politika decido, ne paneo. Gravas, ĉu la celoj, kiujn via teamo uzas, estas atingeblaj tra la tunelo.

Du komandoj kovras la itineron kaj la nomserĉadon en Windows. La Linux-ekvivalentoj estas ip route show default kaj resolvectl query <internal-host>.

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

Tunelo, kiu leviĝas kaj enkursigas nenion utilan, estas ofta rezulto, kiam profilo kopiiĝis inter servoj, kaj ĝenerala konekteca testo ne montros ĝin, ĉar la interfaco estas aktiva. Testu la rimedon, kiun viaj uzantoj malfermas unue, ne publikan adreson, kiun ĉiu vojo povas atingi. Se la nomo solviĝas al publika adreso, dum la itinero montras en la tunelon, la DNS-respondo kaj la itinero apartenas al malsamaj decidoj kaj ambaŭ bezonas riparon.

Pripesu la prizorgadon post la kontroloj

Neniu el la protokoloj estas pli prizorgema en abstrakto. La prizorgado dependas de tio, kiu funkciigas la enirejon, kiel profiloj atingas aparatojn kaj kiom rapide perdita aparato perdas aliron. Simpla finpunkta kliento povas stari antaŭ pli malfacile funkciigebla servilo, kaj la malo ankaŭ okazas. Demandu, kiun el la du via teamo povas teni funkcianta post kiam la persono, kiu konstruis ĝin, foriros.

Elektu la subtenatan konekton, kiu kovras la laboron, poste testu ĝin kontraŭ la aliro, kiun vi efektive bezonas, anstataŭ kontraŭ trajto-listo. Notu, ĉe kiu enirejo ĉiu opcio finiĝas, ĉar du malsamaj enirejoj igas la komparon same pri itineroj kiel pri protokoloj. Ripetu la kvar kontrolojn sur la aparato, kiun vi efektive portos, kaj konservu la profilon, kiu pasas sur ĝi.