NO_PROPOSAL_CHOSEN у L2TP? Спачатку прасканаваць шлюз

Кліент L2TP/IPsec, які зрываецца да запрашэння імені карыстальніка, так і не ўзгадніў першую фазу. Прасканаваць набор прапаноў шлюза замест устаўкі радкоў шыфра.

Запрашэнне імені карыстальніка так і не з’яўляецца, а кліент паведамляе NO_PROPOSAL_CHOSEN. Уліковыя даныя і агульны сакрэтны ключ на гэтым этапе не маюць значэння, бо два бакі не ўзгаднілі, як абараняць фазу 1. Большасць людзей у адказ устаўляюць радок шыфра, знойдзены ў інтэрнэце. Сканаванне шлюза адказвае на тое ж пытанне з доказамі і займае прыкладна столькі ж часу.

Што выключае гэтае паведамленне

Адмова адбываецца ў асноўным рэжыме, да любога абмену L2TP або PPP, таму тунель і база карыстальнікаў не запытваліся. Фаза 1 узгадняе шыфраванне, цэласнасць і групу Diffie-Hellman. Фаза 2 узгадняе прапанову ESP для даных. Збой на фазе 1 не выправіць змяненнем налады PFS фазы 2, і завершаная асацыяцыя IKE не даказвае, што прапанова ESP падыходзіць.

Зафіксуйце бэкенд перад змяненнем сінтаксісу: 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. Звярніце ўвагу на агаворку бэкенда: 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. Запішыце ўведзены набор трансфармацый побач з профілем, каб наступны чалавек не паўтараў пробу.

Падобныя артыкулы