L2TP NO_PROPOSAL_CHOSEN: koja je faza zapravo pala?
Obavijest kaže da je prijedlog odbijen, ali ne koji. Pročitajte dnevnik pozadinskog sustava za fazu, pa usporedite skupove s onima koji upravljaju pristupnikom.
NO_PROPOSAL_CHOSEN stiže prije nego što se pregleda bilo koje PPP korisničko ime, što je korisna činjenica i ujedno razlog zašto poruka zavarava. Ona javlja da je jedna strana odbila prijedlog; ne javlja koji se parametar razlikovao i ne govori ništa o tome je li odbijanje nastupilo tijekom izgradnje IKE asocijacije ili kasnije tijekom pregovora o zaštiti prometa. Iza te dvije mogućnosti stoje dva različita ispravka, a samo jedan od njih uključuje potvrdni okvir PFS kojemu ljudi prvo posežu.
Jedna poruka, dva skupa prijedloga
Raspored IKEv1 L2TP/IPsec ima dva pregovora uzastopno. Faza 1 gradi IKE sigurnosnu asocijaciju od algoritma šifriranja, algoritma cjelovitosti i Diffie-Hellman grupe. Faza 2 zatim pregovara kako se promet štiti, a zahtjev za PFS pripada tom drugom razgovoru.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Budući da su faze uzastopne, mjesto neuspjeha govori vam koji popis usporediti. U tome je cjelokupna 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 složile o fazi 1, razgovor ESP se nikada ne odvija, pa potvrdni okvir nema nikakav utjecaj na odbijanje, i zato njegovo prebacivanje daje istu grešku s drugom vremenskom oznakom.
Obrnuta je greška jednako česta. Uspješna IKE asocijacija ne dokazuje da je ESP prijedlog prihvatljiv i zasigurno ne dokazuje da se grupa faze 2 podudara. 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 odaberete algoritme
Prikupite poruke koje neposredno prethode odbijanju s pozadinskog sustava koji stvarno obrađuje vezu i povežite ih s istim pokušajem. Bez te veze čitate povijest druge veze i iz nje izvlačite zaključke.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanIz tih redaka odgovorite na dva pitanja: je li se uspostavila asocijacija faze 1 i koja je razmjena pala. Ta dva odgovora sužavaju pretragu na jedan popis atributa. Gola obavijest bez okolnog konteksta to ne može, koliko god bilo primamljivo isprobati prijedlog s forumaške teme. Kopiranje radnog niza sa stroja s drugim pozadinskim sustavom obično zamjenjuje jedno odbijanje drugim, malo kasnijim.
Sintaksa pozadinskog sustava se ne prenosi
Zapišite verziju NetworkManager-l2tp i verziju IPsec pozadinskog sustava prije nego što bilo što usporedite. Libreswan i strongSwan ne dijele sintaksu prijedloga ni identične skupove algoritama, pa je niz koji radi u jednom sintaksna greška u drugom. Instalirani pozadinski sustav može i prema politici odbiti IKEv1, a tada nijedan prijedlog nikada neće biti prihvaćen.
README projekta dokumentira te razlike među pozadinskim sustavima i drži polja faze 1 i faze 2 odvojenima. Čitajte ga kao dokumentaciju strukture, ne kao poziv da uključite svaku povijesnu š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 usporedite taj odgovor sa stvarnim prijedlozima 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 prihvaća, 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 pokraj 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 njezina vijeka.