OpenVPN vai IKEv2: četras pārbaudes pirms protokola izvēles
Klientu atbalsts, mobilitāte, autentifikācija un nepieciešamā piekļuve izšķir OpenVPN un IKEv2. Šie divi profili nav savstarpēji aizstājami.
Izvēle starp OpenVPN un IKEv2 parasti tiek apspriesta kā protokola jautājums, un šāds ietvars izšķiež lēmumu. Izšķirošais ir tas, vai jūsu serveris un ierīces atbalsta vienu un to pašu pilno profilu un vai šis profils iztur jūsu pārvietošanos starp tīkliem. Abi steiki viens otrā nepārveidojas: OVPN fails nav IKEv2 profils ar citu sintaksi. Četras pārbaudes, veiktas secībā, atbild uz jautājumu ātrāk nekā jebkura funkciju tabula.
Trūkstošs klients izbeidz diskusiju
Windows un macOS nāk ar IKEv2 klientu, tāpēc IKEv2 profils tur neizmaksā neko papildus un manto piegādes opcijas, ko operētājsistēma jau piedāvā. OpenVPN uz tām pašām mašīnām nozīmē trešās puses klientu, kas jāinstalē, jāatjaunina un jāatbalsta, un šim klientam jāpieņem katra opcija, ko profils izmanto. Saskaitiet platformas, kas jums jāaptver, pirms salīdzināt jebko citu, jo platforma bez strādājoša klienta nemaz nav salīdzināšanas punkts.
Windows viena komanda uzskaita jau esošos profilus un parāda, kāda tipa ir katrs. Nosaukums, ko tā izdrukā, ir nosaukums, ko izmanto vēlākās pārbaudes.
Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType
Aicinājums instalēt klientu ir īstā atbilde OpenVPN kolonnai šajās platformās, un tas ir izvietošanas uzdevums, nevis protokola ierobežojums. Neviens risinājums neatceļ uzticības pārbaudes, identitātes verifikāciju vai uzturēšanu. Pirms apņemšanās jautājiet, kā profili tiek izplatīti, kā tiek atjaunoti akreditācijas dati un kā tiek noņemta pazaudēta ierīce. Vienkārša instalācija joprojām var slēpt atjaunošanas procedūru, ko nedēļas nogalē neviens negrib palaist.
Mobilitāte ir kopīgs iestatījums, nevis protokola solījums
IKEv2 var izmantot MOBIKE, ja abi gali to atbalsta un ieslēdz, kas klientam ļauj saglabāt tuneli, kamēr mainās tā adrese. RFC 4555 definē paplašinājumu, un nosacītā formulējums ir svarīgs: serveris, kas ignorē šo iespēju, tā vietā pārrunā no jauna. Rezultāts var izskatīties vienādi faila pārsūtīšanā un ļoti atšķirīgi tiešā zvanā.
Pārbaudiet pāreju, kas jums patiešām svarīga, ar kaut ko darbojošos, ko varat novērot. Lai ping -t <internal-host> darbojas Windows, vai vienkāršs ping citur, pēc tam pārslēdzieties no Wi-Fi uz mobilo tīklu un vērojiet pārtraukumus. MOBIKE kļūme klienta žurnālā parādās kā pilna atkārtota autentifikācija, nevis klusa adreses atjaunināšana. Jūs mērāt, vai tunelis iztur izmaiņas, nevis vai protokols reklamē atbalstu.
OpenVPN klienti atkārtoti pieslēdzas atbilstoši savas platformas uzvedībai un profila taimeriem, tāpēc tas pats tests var radīt cita veida pārtraukumu. Salīdziniet notikumu, kas svarīgs jūsu lietotājiem, nevis etiķeti uz protokola.
Akreditācijas dati pieder pakalpojumam, nevis steikam
Sertifikāti un citi pieteikšanās risinājumi pieder pakalpojumam, kas izbeidz savienojumu. Paroles pieprasījums vienā klientā neko nepasaka par saderību ar citu, un profils, kas darbojas pret citu vārteju, neko nepasaka par šo. Saglabājiet servera identitātes noteikumus nemainītus, kamēr salīdzināt abus steikus. Protokolu maiņa pirms kļūmes noteikšanas parasti rada otru nesaderīgu profilu.
Pirms vainot kādu no protokoliem, pārbaudiet akreditācijas datus, ko klients uzrādīs, jo beidzies vai nepareizi izsniegts sertifikāts abos gadījumos neizdodas vienādi. Zemāk redzamā izvade parāda subjektu, izdevēju un derīguma datumus, nelasot privāto atslēgu.
openssl x509 -in client.crt -noout -subject -issuer -dates
Uzņēmuma savienojumam izmantojiet metodi, ko uzņēmums publicē, un pārtrauciet uzskatīt salīdzinājumu par eksperimentu. Ja salīdzināt abus pats, vispirms pārbaudiet, vai abi varianti beidzas vienā vārtejā, jo šī viena detaļa nosaka, cik liela jūsu rezultāta daļa ir par protokolu. Noraidījums, kas nosauc akreditācijas datus, ir akreditācijas datu problēma, un nekāda protokolu maiņa to nesalabos.
Pārbaudiet, ko tunelis patiešām maršrutē
Pēc savienojuma apstipriniet, ka nepieciešamais maršruts pastāv un ka vārdi tiek atrisināti. Profils, kas pastāv iekšējiem resursiem, var apzināti atstāt parasto pārlūkošanu vietējā ceļā, un tas ir politikas lēmums, nevis kļūme. Svarīgi ir tas, vai galamērķi, ko izmanto jūsu komanda, ir sasniedzami caur tuneli.
Windows divas komandas aptver maršrutu un vārdu meklēšanu. Linux ekvivalenti ir ip route show default un resolvectl query <internal-host>.
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>
Tunelis, kas paceļas un neko lietderīgu nemaršrutē, ir biežs iznākums, kad profils tika kopēts starp pakalpojumiem, un vispārīgs savienojamības tests to neparādīs, jo interfeiss ir pacelts. Pārbaudiet resursu, ko jūsu lietotāji atver pirmo, nevis publisku adresi, ko var sasniegt jebkurš ceļš. Ja vārds atrisinās uz publisku adresi, kamēr maršruts rāda tunelī, DNS atbilde un maršruts pieder pie dažādiem lēmumiem, un abi ir jālabo.
Pēc pārbaudēm izsveriet uzturēšanu
Abstrakti neviens protokols nav vieglāk uzturams. Uzturēšana atkarīga no tā, kas pārvalda vārteju, kā profili nonāk ierīcēs un cik ātri pazaudēta ierīce zaudē piekļuvi. Vienkāršs gala klients var stāvēt priekšā grūtāk pārvaldāmam serverim, un notiek arī pretējais. Jautājiet, kuru no abiem jūsu komanda var turpināt uzturēt pēc tam, kad tā veidotājs aiziet.
Izvēlieties atbalstīto savienojumu, kas aptver darbu, pēc tam pārbaudiet to pret piekļuvi, kas jums patiešām nepieciešama, nevis pret funkciju sarakstu. Pierakstiet, kurā vārtejā beidzas katrs variants, jo divas dažādas vārtejas salīdzinājumu padara par maršrutu jautājumu tikpat, cik par protokolu. Atkārtojiet četras pārbaudes ierīcē, ko patiešām nēsāsiet, un saglabājiet profilu, kas tajā iztur.