NO_PROPOSAL_CHOSEN на L2TP-у? Прво скенирајте пролаз

Клијент L2TP/IPsec који падне пре упита за корисничко име никада се није усагласио о фази 1. Скенирајте скуп предлога пролаза уместо да лепите шифарске низове.

Упит за корисничко име се никада не појави, а клијент пријави NO_PROPOSAL_CHOSEN. У том тренутку подаци за пријаву и унапред дељени кључ нису важни, јер се две стране нису усагласиле како ће штитити фазу 1. Већина људи одговори тако што залепи шифарски низ који су нашли на интернету. Скенирање пролаза одговара на исто питање доказима и траје отприлике исто.

Шта порука искључује

Одбијање се дешава у главном режиму, пре било какве размене L2TP или PPP, па тунел и база корисника нису консултовани. Фаза 1 преговара о шифровању, интегритету и Diffie-Hellman групи. Фаза 2 преговара о ESP предлогу за податке. Квар у фази 1 не може се поправити променом PFS поставке фазе 2, а завршена IKE асоцијација не доказује да ESP предлог одговара.

Забележите backend пре уређивања синтаксе: ipsec --version. libreswan и strongSwan прихватају различита писања предлога за исте алгоритме.

Затим прочитајте одбијање у контексту са journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Скенирајте пролаз ради његовог скупа трансформација

Скенер директно пита пролаз које ће трансформације преговарати. Најпре зауставите локалну IPsec услугу да се проба не такмичи са вашим клијентом, затим прочитајте SA линије. Третирајте листу као доказ о другој страни, а не као мени који треба укључити цео.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Старији уређаји често нуде 3DES, SHA1 и MODP1024, јер су то биле подразумеване вредности када је производ испоручен и нико их није преиспитао. Сачувајте сирови излаз скенирања, јер је то једини запис о томе шта је друга страна нудила тог дана. Ако је то најјаче доступно преклапање, права ескалација је према власнику пролаза, а не према конфигурацији клијента која свима поново укључује слабу криптографију.

Ускладите преклапање без искључивања безбедности

Унесите само трансформације које се појављују и у скенирању и у вашој политици. Пример испод приказује пролаз који нуди 3DES, SHA1 и MODP1024 у фази 1. Обратите пажњу на напомену о backend-у: libreswan 4.x не компајлира modp1024 групу, па се ово односи на strongSwan или libreswan изградњу са DH2 подршком. Проверите верзију пре него што закључите да је клијент покварен.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Узвичник на крају фиксира један предлог. Користите га да изолујете тест, па га уклоните како би пролаз касније могао да преговара нешто јаче.

Проверите демон и порт пре поновног покушаја

NetworkManager-l2tp покреће сопствену xl2tpd инстанцу. Ако системска услуга већ држи UDP 1701, клијент прелази на ефемерни изворни порт, што RFC 3193 дозвољава, а неки сервери тихо одбацују. Проверите власника сокета пре следећег покушаја.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Застареле генерисане тајне су још један тихи узрок. Датотеке под /etc/ipsec.d/ назване по старој вези могу надживети профил који их је створио, па уклоните оне на које ништа не упућује и покушајте поново.

На крају проверите одакле савет долази. ipsec.conf, написан за IKEv1 XAuth, описује другу врсту VPN-а, а његов предлог није једини ред који ће бити погрешан у L2TP профилу. Запишите скуп трансформација који сте унели поред профила, да следећа особа не понавља пробу.

Повезани чланци