Изборот меѓу 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 и рутата ѝ припаѓаат на различни одлуки и двете треба да се поправат.

Одмерете го одржувањето по проверките

Апстрактно ниту еден протокол не е полесно одржлив. Одржувањето зависи од тоа кој управува со порталот, како профилите стигнуваат до уредите и колку брзо изгубениот уред го губи пристапот. Едноставен краен клиент може да стои пред сервер што е потежок за управување, и обратното исто се случува. Прашајте кој од двата вашиот тим може да продолжи да го работи откако ќе замине човекот што го изградил.

Изберете ја поддржаната врска што ја покрива работата, потоа тестирајте ја спрема пристапот што навистина ви треба, а не спрема список со функции. Запишете на кој портал завршува секоја опција, бидејќи два различни портали ја прават споредбата исто толку прашање на рути колку и на протоколи. Повторете ги четирите проверки на уредот што навистина ќе го носите и задржете го профилот што го поминува на него.

Поврзани статии