L2TP NO_PROPOSAL_CHOSEN: koja je faza zapravo pala?

Obavještenje kaže da je predlog odbijen, ali ne koji. Pročitajte dnevnik pozadinskog sistema za fazu, pa uporedite skupove s onima koji upravljaju pristupnikom.

NO_PROPOSAL_CHOSEN stiže prije nego što se provjeri bilo koje PPP korisničko ime, što je korisna činjenica i ujedno razlog zašto poruka zavodi. Ona javlja da je jedna strana odbila predlog; ne javlja koji se parametar razišao i ne govori ništa o tome je li odbijanje nastupilo pri izgradnji IKE asocijacije ili kasnije pri pregovaranju o zaštiti saobraćaja. Iza te dvije mogućnosti stoje dva različita ispravka, a samo jedan od njih uključuje potvrdni okvir PFS koji ljudi prvo posežu.

Jedna poruka, dva skupa predloga

Raspored IKEv1 L2TP/IPsec ima dva pregovora uzastopno. Faza 1 gradi IKE sigurnosnu asocijaciju od algoritma šifrovanja, algoritma integriteta i Diffie-Hellman grupe. Faza 2 zatim pregovara kako se saobraćaj zaštićuje, a zahtjev za PFS pripada tom drugom razgovoru.

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

Budući da su faze uzastopne, mjesto neuspjeha vam kaže koji spisak da uporedite. U tome je cijela dijagnostička vrijednost poruke i vrijedi je izvući prije nego što dotaknete bilo koju postavku.

Zašto potvrdni okvir PFS ne može popraviti fazu 1

Isključivanje PFS-a mijenja svojstvo faze 2. Ako se strane nikada nisu saglasile o fazi 1, razgovor ESP se nikada ne odvija, pa potvrdni okvir nema nikakvog uticaja na odbijanje, i zato njegovo prebacivanje daje istu grešku s drugom vremenskom oznakom.

Obrnuta greška je jednako česta. Uspješna IKE asocijacija ne dokazuje da je ESP predlog prihvatljiv i sigurno ne dokazuje da se grupa faze 2 poklapa. Tretirajte uspostavljeni upravljački tunel kao dokaz samo o fazi 1. Ljudi čitaju zelenu liniju kao „tunel radi“, a zatim provedu sat na pogrešnoj fazi jer im ništa nije reklo da drugi pregovor nije počeo.

Pročitajte dnevnik prije nego što izaberete algoritme

Prikupljajte poruke koje neposredno prethode odbijanju s pozadinskog sistema koji stvarno obrađuje vezu i povežite ih s istim pokušajem. Bez te veze čitate historiju druge veze i iz nje izvlačite zaključke.

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

Iz tih redova odgovorite na dva pitanja: je li se uspostavila asocijacija faze 1 i koja je razmjena pala. Ta dva odgovora sužavaju pretragu na jedan spisak atributa. Golo obavještenje bez okolnog konteksta to ne može, koliko god bilo primamljivo isprobati predlog s forumske teme. Kopiranje radnog niza s računara s drugim pozadinskim sistemom obično zamjenjuje jedno odbijanje drugim, malo kasnijim.

Sintaksa pozadinskog sistema se ne prenosi

Zapišite verziju NetworkManager-l2tp i verziju IPsec pozadinskog sistema prije nego što bilo šta uporedite. Libreswan i strongSwan ne dijele sintaksu predloga ni identične skupove algoritama, pa je niz koji radi u jednom sintaksna greška u drugom. Instalirani pozadinski sistem može i po politici odbiti IKEv1, a tada nijedan predlog nikada neće biti prihvaćen.

README projekta dokumentuje te razlike među pozadinskim sistemima i drži polja faze 1 i faze 2 odvojenim. Čitajte ga kao dokumentaciju strukture, ne kao poziv da uključite svaku historijsku šifru i slabu grupu, jer veza koja uspijeva samo tako nije veza koju su vam tražili da izgradite.

Dogovorite skup, pa provjerite etape

Pitajte operatera pristupnika koji su IKE i ESP skupovi podržani i odobreni, pa uporedite taj odgovor sa stvarnim predlozima klijenta, a ne s njegovom konfiguracijskom datotekom. Ako se neslaganje odnosi upravo na PFS faze 2, odlučite se za podržanu grupu ili za izričito odobrenu politiku bez PFS-a. Ne zaključujte politiku iz naziva greške.

Kada jedino preklapanje zahtijeva kriptografiju koju organizacija više ne prihvata, odluka pripada pristupniku ili migraciji protokola. Širenje klijentskog niza dok se nešto ne dogovori način je da se poznata slabost isporuči sa zelenom kvačicom pored nje.

Nakon što ispravite stvarno neslaganje, potvrdite uspostavljanje IPsec-a prije nego što istražite L2TP i PPP, i tretirajte svako kasnije odbijanje autentifikacije kao da pripada sljedećoj etapi. Zatim isprobajte obnavljanje u odobrenom testnom procesu, jer uspostavljanje prve asocijacije ne govori ništa o ostatku njenog vijeka.

Povezani članci