OpenVPN ali IKEv2: štiri preverjanja pred izbiro protokola

Izbira med OpenVPN in IKEv2 se običajno obravnava kot vprašanje protokola, in tak okvir zapravi odločitev. Odloča to, ali strežnik in naprave podpirajo isti celoten profil in ali ta profil prenese način, kako se premikate med omrežji. Ta dva sklada se ne pretvarjata drug v drugega: datoteka OVPN ni profil IKEv2 z drugačno sintakso. Štiri preverjanja, izvedena po vrsti, odgovorijo na vprašanje hitreje kot katera koli tabela funkcij.

Manjkajoči odjemalec konča razpravo

Windows in macOS prineseta odjemalca IKEv2, zato profil IKEv2 tam ne stane nič dodatnega pri uvajanju in podeduje možnosti priprave, ki jih operacijski sistem že ponuja. OpenVPN na istih strojih pomeni odjemalca tretje strani, ki ga je treba namestiti, posodabljati in podpirati, in ta odjemalec mora sprejeti vsako možnost, ki jo profil uporablja. Preštejte platforme, ki jih morate pokriti, preden primerjate kar koli drugega, ker platforma brez delujočega odjemalca sploh ni primerjalna točka.

V Windowsu en ukaz našteje obstoječe profile in pokaže, katere vrste je vsak. Ime, ki ga izpiše, je ime, ki ga uporabljajo poznejša preverjanja.

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

Zahteva za namestitev odjemalca je pravi odgovor za stolpec OpenVPN na teh platformah in je naloga uvajanja, ne omejitev protokola. Nobena ureditev ne odpravi preverjanj zaupanja, preverjanja identitete ali vzdrževanja. Preden se zavežete, vprašajte, kako se profili razdeljujejo, kako se obnavljajo poverilnice in kako se odstrani izgubljena naprava. Preprosta namestitev lahko še vedno skrije postopek obnovitve, ki ga nihče ne želi izvajati med vikendom.

Mobilnost je skupna nastavitev, ne obljuba protokola

IKEv2 lahko uporablja MOBIKE, ko ga oba konca podpirata in omogočita, kar odjemalcu omogoča, da obdrži tunel, medtem ko se njegov naslov spreminja. RFC 4555 opredeljuje to razširitev in pogojna formulacija je pomembna: strežnik, ki to zmožnost prezre, namesto tega znova pogaja. Rezultat je lahko pri prenosu datoteke videti enak, pri klicu v živo pa zelo drugačen.

Preizkusite prehod, ki vam je res pomemben, z nečim, kar teče in kar lahko opazujete. Pustite ping -t <internal-host> delovati v Windowsu ali navaden ping drugje, nato preklopite z Wi-Fi na mobilno omrežje in opazujte vrzeli. Napaka MOBIKE se v dnevniku odjemalca pokaže kot popolna ponovna overitev, ne kot tiho posodobitev naslova. Merite, ali tunel prenese spremembo, ne pa, ali protokol oglašuje podporo.

Odjemalci OpenVPN se znova povežejo glede na vedenje svoje platforme in časovnike profila, zato lahko isti preizkus prinese drugačno obliko prekinitve. Primerjajte dogodek, ki je pomemben za vaše uporabnike, ne oznake na protokolu.

Poverilnice pripadajo storitvi, ne skladu

Potrdila in druge načine prijave pripadajo storitvi, ki zaključi povezavo. Zahteva za geslo v enem odjemalcu ne pove nič o združljivosti z drugim, profil, ki deluje z drugim prehodom, pa ne pove nič o tem. Ohranite pravila identitete strežnika nespremenjena, medtem ko primerjate oba sklada. Zamenjava protokolov pred prepoznavo okvare običajno ustvari drugi nezdružljivi profil.

Preden okrivite kateri koli protokol, preglejte poverilnice, ki jih bo odjemalec predstavil, ker poteklo ali napačno izdano potrdilo spodleti enako pri obeh. Spodnji izpis prikazuje subjekt, izdajatelja in datume veljavnosti, ne da bi prebral zasebni ključ.

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

Za povezavo podjetja uporabite metodo, ki jo podjetje objavi, in prenehajte primerjavo obravnavati kot poskus. Če oba primerjate sami, najprej preverite, ali se obe možnosti končata na istem prehodu, ker ta posamezna podrobnost odloči, kolikšen del rezultata je o protokolu. Zavrnitev, ki navaja poverilnice, je težava s poverilnicami, in nobena zamenjava protokola je ne odpravi.

Preverite, kaj tunel dejansko usmerja

Po povezavi potrdite, da potrebna pot obstaja in da se imena razrešijo. Profil, ki obstaja za notranje vire, lahko običajno brskanje namerno pusti na lokalni poti, in to je odločitev politike, ne napaka. Pomembno je, ali so cilji, ki jih uporablja vaša ekipa, dosegljivi skozi tunel.

V Windowsu dva ukaza pokrivata pot in iskanje imen. Ustrezniki v Linuxu so ip route show default in resolvectl query <internal-host>.

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

Tunel, ki se dvigne in ne usmerja nič koristnega, je pogost izid, ko je bil profil kopiran med storitvami, in splošni preizkus povezljivosti tega ne bo pokazal, ker je vmesnik dvignjen. Preizkusite vir, ki ga vaši uporabniki odprejo prvega, ne javnega naslova, ki ga doseže katera koli pot. Če se ime razreši v javni naslov, medtem ko pot kaže v tunel, odgovor DNS in pot pripadata različnima odločitvama in oba je treba popraviti.

Po preverjanjih pretehtajte vzdrževanje

Noben od protokolov ni v abstraktnem smislu lažje vzdržljiv. Vzdrževanje je odvisno od tega, kdo upravlja prehod, kako profili pridejo do naprav in kako hitro izgubljena naprava izgubi dostop. Preprost končni odjemalec lahko stoji pred strežnikom, ki ga je težje upravljati, zgodi pa se tudi obratno. Vprašajte, katerega od dveh lahko vaša ekipa ohrani v delovanju, ko oseba, ki ga je zgradila, odide.

Izberite podprto povezavo, ki pokriva delo, nato jo preizkusite glede na dostop, ki ga res potrebujete, ne glede na seznam funkcij. Zabeležite, na katerem prehodu se konča vsaka možnost, ker dva različna prehoda naredita primerjavo enako vprašanje poti kot protokolov. Ponovite štiri preverjanja na napravi, ki jo boste res nosili, in obdržite profil, ki na njej uspe.