OpenVPN ar IKEv2: keturi patikrinimai prieš renkantis protokolą

Pasirinkimas tarp OpenVPN ir IKEv2 paprastai svarstomas kaip protokolo klausimas, ir tokia formuluotė iššvaisto sprendimą. Lemiama, ar jūsų serveris ir įrenginiai palaiko tą patį išsamų profilį, ir ar tas profilis atlaiko jūsų judėjimą tarp tinklų. Šie du rinkiniai nepersiverčia vienas į kitą: OVPN failas nėra IKEv2 profilis su kita sintakse. Keturi patikrinimai, atlikti iš eilės, atsako į klausimą greičiau nei bet kokia funkcijų lentelė.

Trūkstamas klientas užbaigia diskusiją

Windows ir macOS turi IKEv2 klientą, todėl IKEv2 profilis ten nieko papildomai nekainuoja ir paveldi diegimo parinktis, kurias operacinė sistema jau siūlo. OpenVPN tuose pačiuose kompiuteriuose reiškia trečiosios šalies klientą, kurį reikia įdiegti, atnaujinti ir palaikyti, ir tas klientas turi priimti kiekvieną profilio naudojamą parinktį. Suskaičiuokite platformas, kurias turite aprėpti, prieš lygindami ką nors kita, nes platforma be veikiančio kliento visai nėra palyginimo taškas.

Windows sistemoje viena komanda išvardija jau esamus profilius ir parodo, kokio tipo yra kiekvienas. Pavadinimas, kurį ji išspausdina, yra pavadinimas, kurį naudoja vėlesni patikrinimai.

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

Prašymas įdiegti klientą yra tikrasis OpenVPN stulpelio atsakymas tose platformose, ir tai diegimo užduotis, o ne protokolo apribojimas. Nė viena tvarka nepanaikina pasitikėjimo patikrinimų, tapatybės patvirtinimo ar priežiūros. Prieš įsipareigodami paklauskite, kaip platinami profiliai, kaip atnaujinami prisijungimo duomenys ir kaip pašalinamas pamestas įrenginys. Paprastas diegimas vis tiek gali slėpti atkūrimo procedūrą, kurios savaitgalį niekas nenori vykdyti.

Mobilumas yra bendras nustatymas, o ne protokolo pažadas

IKEv2 gali naudoti MOBIKE, kai abu galai jį palaiko ir įjungia, o tai leidžia klientui išlaikyti tunelį keičiantis jo adresui. RFC 4555 apibrėžia šį plėtinį, ir sąlyginė formuluotė svarbi: serveris, kuris nepaiso šios galimybės, vietoj to derasi iš naujo. Rezultatas gali atrodyti vienodai perduodant failą ir labai skirtingai tiesioginio skambučio metu.

Išbandykite perėjimą, kuris jums tikrai svarbus, su kuo nors veikiančiu, ką galite stebėti. Palikite ping -t <internal-host> veikti Windows sistemoje arba paprastą ping kitur, tada perjunkite iš Wi-Fi į mobilųjį tinklą ir stebėkite pertraukas. MOBIKE gedimas kliento žurnale pasirodo kaip visiška pakartotinė autentifikacija, o ne tyliai atnaujintas adresas. Jūs matuojate, ar tunelis atlaiko pokytį, o ne tai, ar protokolas skelbia palaikymą.

OpenVPN klientai jungiasi iš naujo pagal savo platformos elgseną ir profilio laikmačius, todėl tas pats testas gali sukelti kitokią pertraukimo formą. Palyginkite įvykį, kuris svarbus jūsų naudotojams, o ne etiketę ant protokolo.

Prisijungimo duomenys priklauso paslaugai, o ne rinkiniui

Sertifikatai ir kitos prisijungimo tvarkos priklauso paslaugai, kuri užbaigia ryšį. Slaptažodžio prašymas viename kliente nieko nesako apie suderinamumą su kitu, o profilis, kuris veikia su kita tinklų sietuve, nieko nesako apie šią. Išlaikykite serverio tapatybės taisykles nepakitusias, kol lyginate du rinkinius. Protokolų keitimas prieš nustatant gedimą paprastai sukuria antrą nesuderinamą profilį.

Patikrinkite prisijungimo duomenis, kuriuos klientas pateiks, prieš kaltindami bet kurį protokolą, nes pasibaigęs ar neteisingai išduotas sertifikatas nepavyksta abiem atvejais vienodai. Toliau pateikta išvestis rodo subjektą, išdavėją ir galiojimo datas neskaitant privataus rakto.

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

Įmonės ryšiui naudokite metodą, kurį įmonė paskelbia, ir nustokite laikyti palyginimą eksperimentu. Jei patys lyginate abu, pirmiausia patikrinkite, ar abu variantai baigiasi viename tinklų sietuve, nes ši viena detalė lemia, kokia jūsų rezultato dalis yra apie protokolą. Atmetimas, kuriame nurodomi prisijungimo duomenys, yra prisijungimo duomenų problema, ir joks protokolų keitimas to nesutaisys.

Patikrinkite, ką tunelis iš tikrųjų maršrutizuoja

Prisijungę patvirtinkite, kad reikiamas maršrutas egzistuoja ir kad vardai išsprendžiami. Profilis, skirtas vidiniams ištekliams, gali sąmoningai palikti įprastą naršymą vietiniame kelyje, ir tai yra politikos sprendimas, o ne gedimas. Svarbu, ar paskirties vietos, kurias naudoja jūsų komanda, pasiekiamos per tunelį.

Windows sistemoje dvi komandos apima maršrutą ir vardų paiešką. Linux atitikmenys yra ip route show default ir resolvectl query <internal-host>.

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

Tunelis, kuris pakyla ir nieko naudingo nemaršrutizuoja, yra dažnas rezultatas, kai profilis buvo nukopijuotas tarp paslaugų, o bendras ryšio testas to neparodys, nes sąsaja pakilusi. Išbandykite išteklių, kurį jūsų naudotojai atidaro pirmiausia, o ne viešą adresą, kurį pasiekia bet kuris kelias. Jei vardas išsprendžiamas į viešą adresą, o maršrutas rodo į tunelį, DNS atsakymas ir maršrutas priklauso skirtingiems sprendimams ir abu turi būti sutaisyti.

Pasverkite priežiūrą po patikrinimų

Abstrakčiai nė vienas protokolas nėra lengviau prižiūrimas. Priežiūra priklauso nuo to, kas valdo tinklų sietuvą, kaip profiliai pasiekia įrenginius ir kaip greitai pamestas įrenginys netenka prieigos. Paprastas galinis klientas gali stovėti prieš sunkiau valdomą serverį, ir atvirkščiai taip pat nutinka. Paklauskite, kurį iš dviejų jūsų komanda gali toliau valdyti po to, kai jį sukūręs žmogus išeina.

Pasirinkite palaikomą ryšį, kuris apima darbą, tada išbandykite jį pagal prieigą, kurios jums tikrai reikia, o ne pagal funkcijų sąrašą. Užrašykite, kuriame tinklų sietuve baigiasi kiekvienas variantas, nes du skirtingi sietuvai palyginimą daro tiek pat maršrutų, kiek ir protokolų klausimu. Pakartokite keturis patikrinimus įrenginyje, kurį tikrai nešiositės, ir palikite profilį, kuris jame praeina.