OpenVPN или IKEv2: четири провере пре избора протокола
Подршка клијената, мобилност, аутентификација и потребан приступ одлучују између OpenVPN и IKEv2. Ова два профила нису заменљива.
Избор између OpenVPN и IKEv2 обично се расправља као питање протокола, а такав оквир траћи одлуку. Одлучује то да ли сервер и уређаји подржавају исти потпуни профил и да ли тај профил издржава начин на који се крећете између мрежа. Два стека се не преводе један у други: OVPN датотека није IKEv2 профил са другачијом синтаксом. Четири провере, изведене по реду, одговарају на питање брже од било које табеле функција.
Клијент који недостаје завршава расправу
Windows и macOS долазе са IKEv2 клијентом, па IKEv2 профил тамо ништа додатно не кошта при испоруци и наслеђује опције припреме које оперативни систем већ излаже. OpenVPN на истим машинама значи клијент треће стране који треба инсталирати, ажурирати и подржавати, а тај клијент мора да прихвати сваку опцију коју профил користи. Избројте платформе које морате да покријете пре него што упоредите било шта друго, јер платформа без клијента који ради уопште није тачка поређења.
На Windows-у једна команда наводи профиле који већ постоје и показује које су врсте сваки од њих. Име које исписује је име које користе касније провере.
Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType
Захтев да се инсталира клијент прави је одговор за колону OpenVPN на тим платформама и то је задатак испоруке, а не ограничење протокола. Ниједно решење не уклања провере поверења, проверу идентитета нити одржавање. Питајте како се профили дистрибуирају, како се обнављају акредитиви и како се уклања изгубљени уређај пре него што се обавежете. Једноставна инсталација ипак може да сакрије поступак опоравка који нико не жели да покрене викендом.
Мобилност је заједничко подешавање, а не обећање протокола
IKEv2 може да користи MOBIKE када га оба краја подржавају и омогуће, што клијенту омогућава да задржи тунел док му се адреса мења. RFC 4555 дефинише то проширење, а условна формулација је важна: сервер који игнорише ту могућност уместо тога поново преговара. Резултат може да изгледа исто за пренос датотеке и веома другачије за позив уживо.
Тестирајте прелаз до којег вам је заиста стало, са нечим што ради и што можете да посматрате. Оставите ping -t <internal-host> да ради на Windows-у, или обичан ping другде, затим пређите са Wi-Fi на мобилну мрежу и гледајте прекиде. Неуспех MOBIKE се у дневнику клијента појављује као потпуна поновна аутентификација, а не као тихо ажурирање адресе. Оно што мерите јесте да ли тунел преживљава промену, а не да ли протокол рекламира подршку.
OpenVPN клијенти се поново повезују према понашању своје платформе и тајмерима профила, па исти тест може да произведе други облик прекида. Упоредите догађај који је важан вашим корисницима, а не ознаку на протоколу.
Акредитиви припадају услузи, а не стеку
Сертификати и други начини пријаве припадају услузи која завршава везу. Захтев за лозинку у једном клијенту не говори ништа о компатибилности са другим, а профил који ради са другим порталом не говори ништа о овом. Задржите правила идентитета сервера непромењена док поредите два стека. Промена протокола пре него што утврдите квар обично производи други некомпатибилни профил.
Прегледајте акредитив који ће клијент представити пре него што окривите било који протокол, јер сертификат коме је истекао рок или који је погрешно издат подједнако не успева на оба. Излаз испод приказује субјекат, издаваоца и датуме важности без читања приватног кључа.
openssl x509 -in client.crt -noout -subject -issuer -dates
За корпоративну везу користите метод који компанија објављује и престаните да поређење третирате као експеримент. Ако сами поредите то двоје, прво проверите да ли обе опције завршавају на истом порталу, јер тај један детаљ одлучује колико се вашег резултата односи на протокол. Одбијање које именује акредитив је проблем акредитива и никаква количина промене протокола то неће поправити.
Проверите шта тунел заиста усмерава
Након повезивања потврдите да рута која вам је потребна постоји и да се имена разрешавају. Профил који постоји због интерних ресурса може намерно да остави обично прегледање на локалној путањи, а то је одлука политике, а не квар. Важно је да ли су одредишта која ваш тим користи доступна кроз тунел.
На Windows-у две команде покривају руту и претрагу имена. Linux еквиваленти су ip route show default и resolvectl query <internal-host>.
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>
Тунел који се подигне и не усмерава ништа корисно чест је исход када је профил копиран између услуга, а општи тест повезаности то неће показати јер је интерфејс подигнут. Тестирајте ресурс који ваши корисници први отварају, а не јавну адресу до које може да стигне било која путања. Ако се име разрешава на јавну адресу док рута показује унутар тунела, одговор DNS-а и рута припадају различитим одлукама и обе треба поправити.
Након провера одмерите одржавање
Ниједан протокол није одрживији у апстрактном смислу. Одржавање зависи од тога ко управља порталом, како профили стижу до уређаја и колико брзо изгубљени уређај губи приступ. Једноставан крајњи клијент може да стоји пред сервером који је тежи за управљање, а дешава се и обрнуто. Питајте који од два ваша екипа може да одржи након што особа која га је изградила оде.
Изаберите подржану везу која покрива посао, затим је тестирајте према приступу који вам заиста треба, а не према списку функција. Забележите на ком порталу се завршава свака опција, јер два различита портала чине поређење исто толико питањем рута колико и протокола. Поновите четири провере на уређају који ћете заиста носити и задржите профил који на њему прође.