NO_PROPOSAL_CHOSEN ĉe L2TP? Unue skanu la pordegon

L2TP/IPsec-kliento, kiu malsukcesas antaŭ la salutmesaĝo pri uzantnomo, neniam interkonsentis pri fazo 1. Skanu la proponaron de la pordego anstataŭ alglui ĉifroĉenojn.

La salutmesaĝo pri uzantnomo neniam aperas, kaj la kliento raportas NO_PROPOSAL_CHOSEN. Akreditiloj kaj la antaŭe kunhavigita ŝlosilo estas nerelevantaj en tiu momento, ĉar la du flankoj ne interkonsentis pri tio, kiel protekti la fazon 1. Plej multaj homoj respondas per algluo de ĉifroĉeno, kiun ili trovis rete. Skano de la pordego respondas la saman demandon per pruvoj kaj daŭras proksimume same longe.

Kion la mesaĝo ekskludas

La malakcepto okazas en ĉefa reĝimo, antaŭ iu ajn interŝanĝo L2TP aŭ PPP, do nek la tunelo nek la uzantdatumbazo estis konsultitaj. Fazo 1 intertraktas ĉifradon, integrecon kaj Diffie-Hellman-grupon. Fazo 2 intertraktas la ESP-proponon por datumoj. Malsukceso en fazo 1 ne ripareblas per ŝanĝo de PFS-agordo en fazo 2, kaj kompletigita IKE-asocio ne pruvas, ke la ESP-propono taŭgas.

Notu la backend antaŭ ol redakti la sintakson: ipsec --version. libreswan kaj strongSwan akceptas malsamajn literumojn de la propono por la samaj algoritmoj.

Poste legu la malakcepton en kunteksto per journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Skanu la pordegon por ĝia transformaro

Skanilo demandas la pordegon rekte, kiujn transformojn ĝi intertraktos. Unue haltigu la lokan IPsec-servon, por ke la provo ne konkuru kun via propra kliento, poste legu la SA-liniojn. Traktu la liston kiel pruvon pri la samtavolulo, ne kiel menuon por ŝalti ĉion samtempe.

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

Pli malnovaj aparatoj ofte proponas 3DES, SHA1 kaj MODP1024, ĉar tiuj estis la defaŭltoj kiam la produkto liveriĝis kaj neniu reviziis ilin. Konservu la krudan skanelon, ĉar ĝi estas la sola registro pri tio, kion la samtavolulo proponis tiun tagon. Se tio estas la plej forta havebla interkovro, la ĝusta eskalo estas al la posedanto de la pordego, ne al klienta agordo, kiu reŝaltas malfortan ĉifradon por ĉiuj.

Kongruigu la interkovron sen malŝalti sekurecon

Enigu nur la transformojn, kiuj aperas kaj en la skano kaj en via politiko. La sekva ekzemplo spegulas pordegon, kiu proponas 3DES, SHA1 kaj MODP1024 en fazo 1. Rimarku la backend-kaŭzon: libreswan 4.x ne kompilas la grupon modp1024, do tio validas por strongSwan aŭ por libreswan-konstruo kun DH2-subteno. Kontrolu la version antaŭ ol konkludi, ke la kliento estas difektita.

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

Krisigno ĉe la fino fiksas unu solan proponon. Uzu ĝin por izoli teston, poste forigu ĝin, por ke la pordego povu poste intertrakti ion pli fortan.

Kontrolu la demonon kaj la pordon antaŭ ol reprovi

NetworkManager-l2tp lanĉas sian propran xl2tpd-instancon. Se la sistema servo jam posedas UDP 1701, la kliento falis al efemera fontpordo, kion permesas RFC 3193 kaj kelkaj serviloj silente forĵetas. Kontrolu la posedanton de la ingo antaŭ la sekva provo.

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

Malaktualaj generitaj sekretoj estas alia silenta kaŭzo. Dosieroj sub /etc/ipsec.d/ nomitaj laŭ malnova konekto povas postvivi la profilon, kiu kreis ilin, do forigu tiujn, al kiuj nenio referencas, kaj reprovu.

Fine, kontrolu, de kie venis la konsilo. ipsec.conf, skribita por IKEv1 XAuth, priskribas alian specon de VPN, kaj ĝia propono ne estas la sola linio, kiu malĝustos en L2TP-profila. Notu la transformaron, kiun vi enigis, apud la profilo, por ke la sekva persono ne ripetu la provon.

Rilataj artikoloj