OpenVPN sau IKEv2: patru verificări înainte de a alege un protocol

Alegerea între OpenVPN și IKEv2 este de obicei dezbătută ca o chestiune de protocol, iar această încadrare irosește decizia. Ceea ce decide este dacă serverul și dispozitivele dumneavoastră acceptă același profil complet și dacă acel profil rezistă modului în care vă deplasați între rețele. Cele două stive nu se traduc una în alta: un fișier OVPN nu este un profil IKEv2 cu altă sintaxă. Patru verificări, făcute în ordine, răspund la întrebare mai repede decât orice tabel de funcții.

Un client lipsă încheie discuția

Windows și macOS vin cu un client IKEv2, așa că un profil IKEv2 nu costă nimic în plus de implementat acolo și moștenește opțiunile de pregătire pe care sistemul de operare le expune deja. OpenVPN pe aceleași mașini înseamnă un client terț care trebuie instalat, actualizat și susținut, iar acel client trebuie să accepte fiecare opțiune folosită de profil. Numărați platformele pe care trebuie să le acoperiți înainte de a compara orice altceva, pentru că o platformă fără client funcțional nu este deloc un punct de comparație.

Pe Windows, o singură comandă listează profilurile care există deja și arată ce tip este fiecare. Numele pe care îl afișează este numele pe care îl folosesc verificările ulterioare.

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

Cererea de a instala un client este răspunsul real pentru coloana OpenVPN pe acele platforme și este o sarcină de implementare, nu o limitare a protocolului. Nicio aranjare nu elimină verificările de încredere, verificarea identității sau întreținerea. Întrebați cum sunt distribuite profilurile, cum sunt reînnoite acreditările și cum este eliminat un dispozitiv pierdut înainte de a vă angaja. O instalare simplă poate ascunde în continuare o procedură de recuperare pe care nimeni nu vrea să o ruleze în weekend.

Mobilitatea este o setare comună, nu o promisiune a protocolului

IKEv2 poate folosi MOBIKE atunci când ambele capete îl acceptă și îl activează, ceea ce permite unui client să își păstreze tunelul în timp ce adresa i se schimbă. RFC 4555 definește extensia, iar formularea condiționată contează: un server care ignoră capacitatea renegociază în schimb. Rezultatul poate părea identic pentru un transfer de fișier și foarte diferit pentru un apel în direct.

Testați tranziția care vă interesează cu adevărat, cu ceva care rulează și pe care îl puteți observa. Lăsați ping -t <internal-host> să ruleze pe Windows, sau ping simplu în altă parte, apoi treceți de la Wi-Fi la rețeaua mobilă și urmăriți întreruperile. O defecțiune MOBIKE apare ca o reautentificare completă în jurnalul clientului, nu ca o actualizare silențioasă a adresei. Ceea ce măsurați este dacă tunelul supraviețuiește schimbării, nu dacă protocolul anunță suport.

Clienții OpenVPN se reconectează conform comportamentului platformei lor și temporizatoarelor profilului, așa că același test poate produce o altă formă de întrerupere. Comparați evenimentul care contează pentru utilizatorii dumneavoastră, nu eticheta de pe protocol.

Acreditările aparțin serviciului, nu stivei

Certificatele și alte aranjamente de autentificare aparțin serviciului care încheie conexiunea. O cerere de parolă într-un client nu spune nimic despre compatibilitatea cu altul, iar un profil care funcționează cu alt gateway nu spune nimic despre acesta. Păstrați intacte regulile de identitate ale serverului în timp ce comparați cele două stive. Schimbarea protocoalelor înainte de a identifica defecțiunea produce de obicei un al doilea profil incompatibil.

Inspectați acreditarea pe care clientul o va prezenta înainte de a învinui oricare protocol, pentru că un certificat expirat sau emis greșit eșuează la fel pe ambele. Ieșirea de mai jos arată subiectul, emitentul și datele de valabilitate fără a citi cheia privată.

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

Pentru o conexiune de companie, folosiți metoda pe care compania o publică și nu mai tratați comparația ca pe un experiment. Dacă comparați cele două pe cont propriu, verificați mai întâi dacă ambele opțiuni se termină la un singur gateway, pentru că acel singur detaliu decide cât din rezultatul dumneavoastră ține de protocol. Un refuz care numește acreditarea este o problemă de acreditare, iar nicio schimbare de protocol nu o repară.

Verificați ce rutează de fapt tunelul

După conectare, confirmați că ruta de care aveți nevoie există și că numele se rezolvă. Un profil creat pentru resurse interne poate lăsa navigarea obișnuită pe calea locală în mod intenționat, iar aceasta este o decizie de politică, nu o defecțiune. Contează dacă destinațiile folosite de echipa dumneavoastră sunt accesibile prin tunel.

Pe Windows, două comenzi acoperă ruta și căutarea numelui. Echivalentele din Linux sunt ip route show default și resolvectl query <internal-host>.

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

Un tunel care se ridică și nu rutează nimic util este un rezultat obișnuit când un profil a fost copiat între servicii, iar un test generic de conectivitate nu îl va arăta pentru că interfața este ridicată. Testați resursa pe care utilizatorii o deschid prima, nu o adresă publică la care poate ajunge orice cale. Dacă numele se rezolvă la o adresă publică în timp ce ruta indică în tunel, răspunsul DNS și ruta aparțin unor decizii diferite și ambele trebuie corectate.

Cântăriți întreținerea după verificări

Niciun protocol nu este mai ușor de întreținut în mod abstract. Întreținerea depinde de cine operează gateway-ul, cum ajung profilurile la dispozitive și cât de repede pierde accesul un dispozitiv pierdut. Un client de capăt simplu poate sta în fața unui server mai greu de operat, iar inversul se întâmplă și el. Întrebați care dintre cele două poate fi ținut în funcțiune de echipa dumneavoastră după ce persoana care l-a construit pleacă.

Alegeți conexiunea acceptată care acoperă munca, apoi testați-o față de accesul de care aveți cu adevărat nevoie, nu față de o listă de funcții. Notați pe ce gateway se termină fiecare opțiune, pentru că două gateway-uri diferite fac comparația tot atât despre rute, cât și despre protocoale. Repetați cele patru verificări pe dispozitivul pe care îl veți purta cu adevărat și păstrați profilul care trece pe el.