NO_PROPOSAL_CHOSEN при L2TP? Първо сканирайте шлюза

L2TP/IPsec клиент, който се проваля преди поканата за потребителско име, никога не е съгласувал фаза 1. Сканирайте набора от предложения на шлюза, вместо да поставяте шифърни низове.

Поканата за потребителско име така и не се появява, а клиентът съобщава 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. Запишете набора от трансформации, който сте въвели, до профила, за да не повтаря следващият човек пробата.

Подобни статии