Чаму IKEv2 на Android не працуе на нестандартным порце UDP
Натыўная форма IKEv2 прымае адрас, а не порт. Пераканайцеся, што кліент гэта падтрымлівае, задайце абодва порты сервера, затым паглядзіце на фарміраванне пакетаў і журналы.
Шлюз адказвае на IKEv2 на порце UDP 4443 нездарма, у профілі ёсць поле з назвай Server, вы ўводзіце імя хоста і порт, а тэлефон паведамляе, што не можа дасягнуць сервера або не можа разабраць адрас. Нічога не блакуецца. Натыўная форма Android чакае хост, і тое ж самае тычыцца Windows. Нестандартны порт — гэта магчымасць кліента, а не налада сервера, і толькі некаторыя кліенты дазваляюць яго выказаць. Прайдзіце тры часткі па парадку: што кліент можа сказаць, на чым слухае сервер і ці фармуюць абодва бакі пакеты аднолькава.
Што тэлефон насамрэч адправіў
Радок host:port у полі, прызначаным для імені, разбіраецца як імя. Рэзалвер не вяртае нічога для vpn.example.net:4443, і памылка, якую вы бачыце, — гэта збой разбору імені або недасяжнасць, а не тайм-аўт на порце. Гэта розніца важная, бо паўтор з больш кароткім імем або іншай сеткай ніколі не выправіць радок, які форма не можа разабраць.
Натыўны профіль IKEv2 на Android, як і ўбудаваны кліент Windows VPN, замацаваны на стандартных портах IKE. Ні адзін з іх не паказвае поле порта, і ніякае рэдагаванне профілю яго не дадае. Калі слухач аператара сапраўды на 4443, то ўбудаваны кліент — гэта няправільны інструмент, а не няправільна наладжаны.
Выкарыстоўвайце кліент, які паказвае порт
Кліент strongSwan для Android апісвае наладжваемы порт сервера ў пашыраных наладах профілю, таму ён з’яўляецца амаль у кожным працоўным рэцэпце для гэтай схемы. Гэтая падтрымка належыць менавіта гэтаму кліенту: іншая праграма IKEv2 або вендарны форк той жа праграмы можа не паказваць тое ж поле, нават калі базавы дэман strongSwan яго падтрымлівае.
Папрасіце ў аператара ўвесь набор адразу: імя шлюза, порт UDP, метад аўтэнтыфікацыі і ідэнтычнасць сервера, якую кліент павінен чакаць. Нестандартны порт — не прычына адключаць праверку сертыфікатаў або змяняць пратакол. Увядзіце порт там, дзе яго чакае ўсталяваны кліент, і калі ў гэтага кліента няма такога поля, адказ — іншы дазволены кліент, а не выдуманы абыход.
У сервера два порты, і абодва павінны супадаць
IKE пачынаецца на UDP 500, а NAT-транзіт звычайна пераносіць IKE і інкапсуляваны ESP на UDP 4500. Гэта асобныя налады ў strongSwan, таму сервер, перанесены на адзін нестандартны порт, патрабуе змены абодвух на аднолькавае значэнне:
plugins {
socket-default {
port = 4443
port_nat_t = 4443
}
}
Калі адзін порт абслугоўвае абедзве ролі, дэман павінен адрозніваць IKE ад ESP-у-UDP на тым жа сокеце, што ён робіць па чатырохбайтавым маркеры не-ESP, які папярэднічае паведамленню IKE. Таму кліент не можа дамовіцца на нестандартным порце, а затым моўчкі працягнуць на 4500, і таму фраза “проста змяніце порт” хавае патрабаванне да фарміравання.
Перанакіраванне — гэта не слухач
Перанакіраванне 4443 на звычайны слухач IKE — гэта рэжым збою, які выглядае амаль паспяхова. Першы абмен прыходзіць, сервер адказвае, а затым злучэнне застойваецца або перагенерыруе ключы ў нішто, бо адказ выходзіць з іншага порта, і наступны інкапсуляваны трафік ніколі не адпавядае стану, створанаму абодвума бакамі. Правіла, якое перапісвае порт прызначэння без пераносу слухача, дае менавіта гэты напалову адкрыты вынік.
Шлях таксама павінен дазваляць UDP ад канца да канца. Прапуск TCP 443 праз гатэльную або аператарскую сетку нічога не кажа пра IKEv2 на порце UDP, нават з тым жа нумарам. Там, дзе дазволены толькі TCP 443, нестандартны порт UDP не ператварае IKEv2 у HTTPS, і правільны адказ можа быць іншым шляхам доступу, а не чарговым эксперыментам з портам.
Падзяляйце тры этапы пры тэставанні
Здымайце трафік на серверы, пакуль кліент спрабуе адзін раз. Запыт, які не прыходзіць, — гэта пытанне канчатковай кропкі або міжсеткавага экрана; запыт, які прыйшоў без адказу, — пытанне слухача або палітыкі; адказ, пасля якога настае цішыня, — пытанне фарміравання або ідэнтычнасці.
tcpdump -ni eth0 -vv udp port 4443
Затым чытайце паведамленне кліента, а не яго круцёлку. Памылка прапановы азначае, што алгарытмы не супадаюць, памылка аўтэнтыфікацыі азначае, што не супадаюць ідэнтычнасці або сертыфікаты, а паўторныя перадачы без адказу азначаюць, што на гэтым порце ніхто не адказвае. Тэстуйце адзін этап за раз і мяняйце адно поле паміж спробамі; дакументацыя strongSwan пра NAT-транзіт апісвае маркер і паводзіны порта, якія паказвае вам здымак.