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. Забележете го множеството трансформации што сте го внеле покрај профилот, за да не ја повторува следната личност проверката.

Поврзани статии