NO_PROPOSAL_CHOSEN la L2TP? Scanați mai întâi gateway-ul

Un client L2TP/IPsec care eșuează înainte de promptul pentru numele de utilizator nu a convenit niciodată asupra fazei 1. Scanați setul de propuneri al gateway-ului în loc să lipiți șiruri de cifrare.

Promptul pentru numele de utilizator nu apare niciodată, iar clientul raportează NO_PROPOSAL_CHOSEN. În acel moment, acreditările și cheia partajată în prealabil sunt irelevante, deoarece cele două capete nu au convenit cum să protejeze faza 1. Cei mai mulți oameni reacționează lipind un șir de cifrare găsit online. O scanare a gateway-ului răspunde la aceeași întrebare cu dovezi și durează aproximativ la fel de mult.

Ce exclude mesajul

Respingerea are loc în modul principal, înainte de orice schimb L2TP sau PPP, așa că nici tunelul, nici baza de date de utilizatori nu au fost consultate. Faza 1 negociază criptarea, integritatea și un grup Diffie-Hellman. Faza 2 negociază propunerea ESP pentru date. O defecțiune în faza 1 nu se remediază schimbând o setare PFS din faza 2, iar o asociere IKE finalizată nu dovedește că propunerea ESP se potrivește.

Notați backend-ul înainte de a edita sintaxa: ipsec --version. libreswan și strongSwan acceptă ortografieri diferite ale propunerii pentru aceiași algoritmi.

Apoi citiți respingerea în context cu journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Scanați gateway-ul pentru setul său de transformări

Un scanner întreabă direct gateway-ul ce transformări va negocia. Opriți mai întâi serviciul IPsec local, ca sonda să nu concureze cu propriul client, apoi citiți liniile SA. Tratați lista ca dovadă despre cealaltă parte, nu ca pe un meniu de activat în întregime.

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

Aparatele mai vechi oferă adesea 3DES, SHA1 și MODP1024, pentru că acestea erau valorile implicite la livrarea produsului și nimeni nu le-a revizuit. Păstrați ieșirea brută a scanării, pentru că este singura înregistrare a ceea ce a oferit cealaltă parte în acea zi. Dacă aceasta este cea mai puternică suprapunere disponibilă, escaladarea corectă este către proprietarul gateway-ului, nu către o configurație de client care reactivează criptografia slabă pentru toată lumea.

Potriviți suprapunerea fără a dezactiva siguranța

Introduceți doar transformările care apar atât în scanare, cât și în politica dumneavoastră. Exemplul de mai jos reflectă un gateway care oferă 3DES, SHA1 și MODP1024 în faza 1. Observați rezerva privind backend-ul: libreswan 4.x nu compilează grupul modp1024, așa că acest lucru se aplică pentru strongSwan sau pentru o compilare libreswan cu suport DH2. Verificați versiunea înainte de a concluziona că clientul este defect.

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

Un semn de exclamare la final fixează o singură propunere. Folosiți-l pentru a izola un test, apoi eliminați-l ca gateway-ul să poată negocia ceva mai puternic mai târziu.

Verificați daemonul și portul înainte de a reîncerca

NetworkManager-l2tp pornește propria instanță xl2tpd. Dacă serviciul de sistem deține deja UDP 1701, clientul trece pe un port sursă efemer, ceea ce RFC 3193 permite și unii servere îl aruncă în tăcere. Verificați proprietarul socketului înainte de următoarea încercare.

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

Secretele generate învechite sunt o altă cauză tăcută. Fișierele din /etc/ipsec.d/ numite după o conexiune veche pot supraviețui profilului care le-a creat, așa că ștergeți-le pe cele la care nimic nu face referire și încercați din nou.

În final, verificați de unde vine sfatul. Un ipsec.conf scris pentru IKEv1 XAuth descrie alt tip de VPN, iar propunerea sa nu este singura linie care va fi greșită într-un profil L2TP. Notați setul de transformări introdus lângă profil, ca următoarea persoană să nu repete sonda.

Articole similare