L2TP NO_PROPOSAL_CHOSEN: kura fāze patiesībā cieta neveiksmi?
Paziņojums saka, ka priekšlikums tika noraidīts, bet ne kurš. Izlasiet backend žurnālu, lai noteiktu fāzi, pēc tam salīdziniet kopas ar to, kas pārvalda vārteju.
NO_PROPOSAL_CHOSEN pienāk pirms tam, kad tiek pārbaudīts jebkurš PPP lietotājvārds, kas ir noderīgs fakts un arī iemesls, kāpēc ziņojums maldina. Tas ziņo, ka viena puse noraidīja priekšlikumu; tas neziņo, kurš parametrs nesakrita, un neko nesaka par to, vai noraidījums notika IKE asociācijas veidošanas laikā vai vēlāk, sarunās par trafika aizsardzību. Aiz šīm divām iespējām stāv divi dažādi labojumi, un tikai viens no tiem attiecas uz PFS izvēles rūtiņu, pie kuras cilvēki ķeras vispirms.
Viens ziņojums, divas priekšlikumu kopas
IKEv1 L2TP/IPsec izkārtojumā ir divas sarunas pēc kārtas. 1 fāze veido IKE drošības asociāciju no šifrēšanas algoritma, integritātes algoritma un Diffie-Hellman grupas. Pēc tam 2 fāze vienojas par to, kā tiks aizsargāts trafiks, un PFS prasība pieder tieši šai otrajai sarunai.
| 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 |
Tā kā fāzes ir secīgas, kļūmes vieta parāda, kuru sarakstu salīdzināt. Tajā ir visa ziņojuma diagnostiskā vērtība, un to ir vērts izvilkt pirms jebkura iestatījuma aiztikšanas.
Kāpēc PFS izvēles rūtiņa nevar salabot 1 fāzi
PFS izslēgšana maina 2 fāzes īpašību. Ja puses nekad nav vienojušās par 1 fāzi, ESP saruna vispār nenotiek, tāpēc izvēles rūtiņai nav nekādas ietekmes uz noraidījumu, un tieši tāpēc tās pārslēgšana dod to pašu kļūdu ar citu laika zīmogu.
Pretējā kļūda ir tikpat izplatīta. Veiksmīga IKE asociācija nepierāda, ka ESP priekšlikums ir pieņemams, un noteikti nepierāda, ka 2 fāzes grupa sakrīt. Uzskatiet izveidoto pārvaldības tuneli par pierādījumu tikai par 1 fāzi. Cilvēki zaļo līniju nolasa kā «tunelis darbojas», un pēc tam pavada stundu nepareizajā fāzē, jo nekas viņiem nepateica, ka otrā saruna nav sākusies.
Izlasiet žurnālu pirms algoritmu izvēles
Savāciet ziņojumus tieši pirms noraidījuma no backend, kas patiešām apkalpo savienojumu, un sasaistiet tos ar to pašu mēģinājumu. Bez šīs sasaistes jūs lasāt cita savienojuma vēsturi un izdarāt no tās secinājumus.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanNo šīm rindām atbildiet uz diviem jautājumiem: vai izveidojās 1 fāzes asociācija un kura apmaiņa cieta neveiksmi. Šīs divas atbildes sašaurina meklēšanu līdz vienam atribūtu sarakstam. Kails paziņojums bez apkārtējā konteksta to nespēj, lai cik vilinoši būtu izmēģināt priekšlikumu no foruma pavediena. Strādājošas virknes kopēšana no mašīnas ar citu backend parasti aizstāj vienu noraidījumu ar citu, nedaudz vēlāku.
Backend sintakse neceļo
Pierakstiet NetworkManager-l2tp versiju un IPsec backend versiju pirms kaut kā salīdzināšanas. Libreswan un strongSwan nedala priekšlikumu sintaksi vai identiskas algoritmu kopas, tāpēc virkne, kas strādā vienā, otrā ir sintakses kļūda. Uzstādītais backend var arī atteikt IKEv1 pēc politikas, un tad neviens priekšlikums nekad netiks pieņemts.
Projekta README dokumentē šīs backend atšķirības un tur 1 fāzes un 2 fāzes laukus atsevišķi. Lasiet to kā struktūras dokumentāciju, nevis kā uzaicinājumu ieslēgt katru vēsturisko šifru un vāju grupu, jo savienojums, kas izdodas tikai tā, nav tas savienojums, ko jums lūdza uzbūvēt.
Vienojieties par kopu, pēc tam pārbaudiet posmus
Pajautājiet vārtejas operatoram, kuras IKE un ESP kopas tiek atbalstītas un apstiprinātas, pēc tam salīdziniet šo atbildi ar klienta faktiskajiem priekšlikumiem, nevis ar tā konfigurācijas failu. Ja domstarpības attiecas tieši uz 2 fāzes PFS, vienojieties par atbalstītu grupu vai skaidri apstiprinātu politiku bez PFS. Neizseciniet politiku no kļūdas nosaukuma.
Kad vienīgā pārklāšanās prasa kriptogrāfiju, ko organizācija vairs nepieņem, lēmums pieder vārtejai vai protokola migrācijai. Klienta virknes paplašināšana, līdz kaut kas vienojas, ir veids, kā piegādāt zināmu vājumu ar zaļu ķeksīti blakus.
Pēc īstās neatbilstības izlabošanas apstipriniet IPsec izveidi pirms L2TP un PPP izpētes, un uzskatiet jebkuru vēlāku autentifikācijas noraidījumu par piederošu nākamajam posmam. Pēc tam pārbaudiet atjaunošanu apstiprinātajā testēšanas procesā, jo pirmās asociācijas izveide neko nepasaka par pārējo tās mūžu.