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 і маршрут належаць да розных рашэнняў, і абодва трэба выправіць.

Узважце абслугоўванне пасля праворак

Ні адзін з пратаколаў не больш зручны для абслугоўвання ў абстракцыі. Абслугоўванне залежыць ад таго, хто эксплуатуе шлюз, як профілі трапляюць на прылады і як хутка страчаная прылада губляе доступ. Просты кліент канчатковай кропкі можа стаяць перад больш складаным у эксплуатацыі серверам, і адваротнае таксама бывае. Спытайце, які з двух ваша каманда здольная падтрымліваць працоўным пасля таго, як чалавек, які яго пабудаваў, пойдзе.

Выберыце тое падтрыманае злучэнне, якое ахоплівае працу, затым праверце яго супраць доступу, які вам сапраўды патрэбны, а не супраць спісу магчымасцей. Занатуйце, на якім шлюзе сканчаецца кожны варыянт, бо два розныя шлюзы робяць параўнанне ў такой жа ступені пра маршруты, як і пра пратаколы. Паўтарыце чатыры праверкі на прыладзе, якую вы сапраўды будзеце насіць, і пакіньце профіль, які на ёй праходзіць.