L2TP NO_PROPOSAL_CHOSEN: kuri fazė iš tikrųjų nepavyko?
Pranešimas sako, kad pasiūlymas buvo atmestas, bet ne kuris. Perskaitykite backend žurnalą, kad nustatytumėte fazę, tada palyginkite rinkinius su tuo, kas administruoja šliuzą.
NO_PROPOSAL_CHOSEN ateina anksčiau, nei patikrinamas bet kuris PPP vartotojo vardas, o tai naudingas faktas ir kartu priežastis, kodėl pranešimas klaidina. Jis praneša, kad viena pusė atmetė pasiūlymą; jis nepraneša, kuris parametras nesutapo, ir nieko nesako apie tai, ar atmetimas įvyko kuriant IKE asociaciją, ar vėliau derantis dėl srauto apsaugos. Už šių dviejų galimybių slypi du skirtingi pataisymai, ir tik vienas jų susijęs su PFS žymimuoju langeliu, prie kurio žmonės pirmiausia griebiasi.
Vienas pranešimas, du pasiūlymų rinkiniai
IKEv1 L2TP/IPsec išdėstyme yra dvi derybos iš eilės. 1 fazė sukuria IKE saugos asociaciją iš šifravimo algoritmo, vientisumo algoritmo ir Diffie-Hellman grupės. Tada 2 fazė derasi dėl to, kaip bus apsaugotas srautas, o PFS reikalavimas priklauso tam antram pokalbiui.
| 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 |
Kadangi fazės eina iš eilės, gedimo vieta pasako, kurį sąrašą lyginti. Čia ir yra visa diagnostinė pranešimo vertė, ir verta ją išgauti prieš liečiant bet kokį nustatymą.
Kodėl PFS žymimasis langelis negali pataisyti 1 fazės
Išjungus PFS pasikeičia 2 fazės savybė. Jei šalys niekada nesusitarė dėl 1 fazės, ESP pokalbis iš viso nevyksta, todėl žymimasis langelis neturi jokios įtakos atmetimui, ir būtent todėl jį perjungus gaunama ta pati klaida su kitu laiko žyma.
Priešinga klaida taip pat paplitusi. Sėkminga IKE asociacija neįrodo, kad ESP pasiūlymas yra priimtinas, ir tikrai neįrodo, kad 2 fazės grupė sutampa. Įsitvirtinusį valdymo tunelį traktuokite kaip įrodymą tik apie 1 fazę. Žmonės žalią eilutę perskaito kaip „tunelis veikia“, o paskui praleidžia valandą ne toje fazėje, nes niekas jiems nepasakė, kad antrosios derybos neprasidėjo.
Perskaitykite žurnalą prieš rinkdamiesi algoritmus
Surinkite pranešimus, ėjusius prieš pat atmetimą, iš backend, kuris iš tikrųjų aptarnauja ryšį, ir susiekite juos su ta pačia užklausa. Be šio susiejimo jūs skaitote kito ryšio istoriją ir darote iš jos išvadas.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanIš tų eilučių atsakykite į du klausimus: ar susidarė 1 fazės asociacija ir kuri mainų dalis nepavyko. Šie du atsakymai susiaurina paiešką iki vieno atributų sąrašo. Nuogas pranešimas be aplinkinio konteksto to negali, kad ir kaip vilioja išbandyti pasiūlymą iš forumo temos. Veikiančios eilutės nukopijimas iš mašinos su kitu backend paprastai pakeičia vieną atmetimą kitu, kiek vėlesniu.
Backend sintaksė nekeliauja
Užrašykite NetworkManager-l2tp versiją ir IPsec backend versiją prieš ką nors lygindami. Libreswan ir strongSwan nesidalija pasiūlymų sintakse ar identiškais algoritmų rinkiniais, todėl eilutė, kuri veikia viename, kitame yra sintaksės klaida. Įdiegtas backend pagal politiką gali atsisakyti IKEv1, ir tada joks pasiūlymas niekada nebus priimtas.
Projekto README dokumentuoja šiuos backend skirtumus ir laiko 1 fazės bei 2 fazės laukus atskirai. Skaitykite jį kaip struktūros dokumentaciją, o ne kaip kvietimą įjungti kiekvieną istorinį šifrą ir silpną grupę, nes ryšys, kuris pavyksta tik taip, nėra tas ryšys, kurio jūsų prašė sukurti.
Sutarkite dėl rinkinio, tada patikrinkite etapus
Paklauskite šliuzo operatoriaus, kurie IKE ir ESP rinkiniai palaikomi ir patvirtinti, tada palyginkite šį atsakymą su faktiniais kliento pasiūlymais, o ne su jo konfigūracijos failu. Jei nesutarimas konkrečiai susijęs su 2 fazės PFS, sutarkite dėl palaikomos grupės arba aiškiai patvirtintos politikos be PFS. Nedarukite politikos iš klaidos pavadinimo.
Kai vienintelė sankirta reikalauja kriptografijos, kurios organizacija nebepriima, sprendimas priklauso šliuzui arba protokolo migracijai. Kliento eilutės platinimas tol, kol kažkas susitars, yra būdas pristatyti žinomą silpnybę su žalia varnelė šalia.
Ištaisę tikrąjį neatitikimą, patvirtinkite IPsec sukūrimą prieš tirdami L2TP ir PPP, o kiekvieną vėlesnį autentifikavimo atmetimą laikykite priklausančiu kitam etapui. Tada išbandykite atnaujinimą patvirtintame testavimo procese, nes pirmosios asociacijos sukūrimas nieko nesako apie likusį jos gyvavimo laiką.