L2TP NO_PROPOSAL_CHOSEN: care fază a eșuat de fapt?

Notificarea spune că o propunere a fost respinsă, nu care. Citiți jurnalul backendului pentru fază, apoi comparați suitele cu cel care administrează gatewayul.

NO_PROPOSAL_CHOSEN sosește înainte de a fi examinat orice nume de utilizator PPP, ceea ce este un fapt util și totodată motivul pentru care mesajul induce în eroare. Raportează că o parte a respins o propunere; nu raportează care parametru nu s-a potrivit și nu spune nimic despre dacă respingerea a avut loc în timpul construirii asocierii IKE sau mai târziu, în timpul negocierii protecției traficului. În spatele acestor două posibilități stau două corecții diferite, iar doar una dintre ele implică bifa PFS la care oamenii apelează mai întâi.

Un mesaj, două seturi de propuneri

Aranjamentul IKEv1 L2TP/IPsec are două negocieri în succesiune. Faza 1 construiește asocierea de securitate IKE dintr-un algoritm de criptare, un algoritm de integritate și un grup Diffie-Hellman. Faza 2 negociază apoi cum este protejat traficul, iar cerința PFS aparține acelei a doua conversații.

PhaseWhat is agreedWhat a rejection here means
Phase 1Encryption, integrity, DH group for the IKE SANo management tunnel exists, so nothing later can run
Phase 2ESP transforms plus the PFS group policyThe IKE SA negotiates, then child negotiation fails

Deoarece fazele sunt succesive, poziția eșecului vă spune ce listă să comparați. Acolo stă întreaga valoare de diagnostic a mesajului și merită extrasă înainte de a atinge vreo setare.

De ce o bifă PFS nu poate repara faza 1

Dezactivarea PFS schimbă o proprietate a fazei 2. Dacă părțile nu au căzut niciodată de acord asupra fazei 1, conversația ESP nu are loc deloc, deci bifa nu are niciun efect asupra respingerii, și de aceea comutarea ei produce aceeași eroare cu altă marcă de timp.

Eroarea inversă este la fel de frecventă. O asociere IKE reușită nu dovedește că propunerea ESP este acceptabilă și cu siguranță nu dovedește că grupul fazei 2 se potrivește. Tratați un tunel de administrare stabilit ca dovadă doar despre faza 1. Oamenii citesc linia verde ca «tunelul este activ» și apoi petrec o oră pe faza greșită pentru că nimic nu le-a spus că a doua negociere nu începuse.

Citiți jurnalul înainte de a alege algoritmi

Colectați mesajele imediat anterioare respingerii din backendul care se ocupă efectiv de conexiune și corelați-le cu aceeași încercare. Fără acea corelație citiți istoricul altei conexiuni și trageți concluzii din el.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Din acele linii, răspundeți la două întrebări: s-a stabilit o asociere de fază 1 și care schimb a eșuat. Aceste două răspunsuri restrâng căutarea la o singură listă de atribute. O notificare goală fără context în jur nu poate face asta, oricât de tentant ar fi să încercați o propunere dintr-un fir de forum. Copierea unui șir care funcționează de pe o mașină cu alt backend înlocuiește de obicei o respingere cu alta, puțin mai târziu.

Sintaxa backendului nu călătorește

Notați versiunea NetworkManager-l2tp și versiunea backendului IPsec înainte de a compara ceva. Libreswan și strongSwan nu împărtășesc sintaxa propunerilor sau seturi identice de algoritmi, așa că un șir care funcționează într-unul este o eroare de sintaxă în celălalt. Backendul instalat poate refuza și IKEv1 conform politicii, iar atunci nicio propunere nu va fi vreodată acceptată.

README-ul proiectului documentează aceste diferențe între backenduri și ține câmpurile fazei 1 și fazei 2 separate. Citiți-l ca documentație a structurii, nu ca invitație de a activa fiecare cifru istoric și un grup slab, pentru că o conexiune care reușește doar așa nu este conexiunea pe care vi s-a cerut să o construiți.

Stabiliți suita, apoi verificați etapele

Întrebați operatorul gatewayului ce suite IKE și ESP sunt acceptate și aprobate, apoi comparați acel răspuns cu propunerile efective ale clientului în loc de fișierul său de configurare. Dacă dezacordul este specific despre PFS din faza 2, alegeți un grup acceptat sau o politică fără PFS aprobată în mod explicit. Nu deduceți politica din numele erorii.

Când singura suprapunere cere criptografie pe care organizația nu o mai acceptă, decizia aparține gatewayului sau unei migrări de protocol. Lărgirea șirului clientului până când ceva negociază este o modalitate de a livra o slăbiciune cunoscută cu o bifă verde alături.

După ce corectați nepotrivirea reală, confirmați stabilirea IPsec înainte de a investiga L2TP și PPP, și tratați orice respingere ulterioară a autentificării ca aparținând etapei următoare. Apoi testați reînnoirea în procesul de testare aprobat, pentru că stabilirea primei asocieri nu spune nimic despre restul duratei ei de viață.

Articole similare