L2TP NO_PROPOSAL_CHOSEN: katera faza je pravzaprav spodletela?

NO_PROPOSAL_CHOSEN prispe, preden se pregleda katero koli uporabniško ime PPP, kar je koristno dejstvo in tudi razlog, da sporočilo zavaja. Poroča, da je ena stran zavrnila predlog; ne poroča, kateri parameter se ni ujemal, in ne pove ničesar o tem, ali se je zavrnitev zgodila med gradnjo asociacije IKE ali pozneje med pogajanji o zaščiti prometa. Za tema dvema možnostma stojita dve različni popravki in le ena od njiju zadeva potrditveno polje PFS, po katerem ljudje najprej segajo.

Eno sporočilo, dva niza predlogov

Postavitev IKEv1 L2TP/IPsec ima dve pogajanji zaporedoma. Faza 1 zgradi asociacijo za varnost IKE iz algoritma za šifriranje, algoritma za celovitost in skupine Diffie-Hellman. Faza 2 nato pogaja, kako bo promet zaščiten, in zahteva PFS spada k temu drugemu pogovoru.

Ker si faze sledijo, mesto okvare pove, kateri seznam primerjati. V tem je vsa diagnostična vrednost sporočila in vredno jo je izluščiti, preden se dotaknete kakšne nastavitve.

Zakaj potrditveno polje PFS ne more popraviti faze 1

Izklop PFS spremeni lastnost faze 2. Če se strani nikoli nista dogovorili o fazi 1, do pogovora ESP sploh ne pride, zato polje nima nobenega vpliva na zavrnitev, in zato njegov preklop vrne isto napako z drugo časovno oznako.

Nasprotna napaka je prav tako pogosta. Uspešna asociacija IKE ne dokazuje, da je predlog ESP sprejemljiv, in zagotovo ne dokazuje, da se skupina faze 2 ujema. Vzpostavljeni upravljalni tunel obravnavajte kot dokaz le o fazi 1. Ljudje zeleno vrstico preberejo kot »tunel deluje« in nato porabijo uro za napačno fazo, ker jim nič ni povedalo, da se drugo pogajanje ni začelo.

Preberite dnevnik, preden izberete algoritme

Zberite sporočila tik pred zavrnitvijo iz backend-a, ki dejansko obdeluje povezavo, in jih povežite z istim poskusom. Brez te povezave berete zgodovino druge povezave in iz nje sklepate.

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

Iz teh vrstic odgovorite na dve vprašanji: ali je nastala asociacija faze 1 in katera izmenjava je spodletela. Ta dva odgovora zožita iskanje na en seznam atributov. Golo obvestilo brez okoliškega konteksta tega ne zmore, naj bo preizkusiti predlog iz forumaške niti še tako vabljivo. Kopiranje delujočega niza s stroja z drugim backend-om običajno zamenja eno zavrnitev z drugo, malo pozneje.

Sintaksa backend-a ne potuje

Zapišite različico NetworkManager-l2tp in različico backend-a IPsec, preden karkoli primerjate. Libreswan in strongSwan si ne delita sintakse predlogov niti enakih nizov algoritmov, zato je niz, ki deluje v enem, v drugem skladenjska napaka. Nameščeni backend lahko tudi zavrne IKEv1 po politiki, in takrat noben predlog ne bo nikoli sprejet.

README projekta dokumentira te razlike med backend-i in drži polji faze 1 in faze 2 ločeni. Berite ga kot dokumentacijo strukture, ne kot vabilo, da vklopite vsako zgodovinsko šifro in šibko skupino, kajti povezava, ki uspe le tako, ni povezava, ki so vam jo naročili zgraditi.

Dogovorite se o nizu in nato preverite stopnje

Vprašajte operaterja prehoda, kateri nizi IKE in ESP so podprti in odobreni, nato pa ta odgovor primerjajte z dejanskimi predlogi odjemalca in ne z njegovo konfiguracijsko datoteko. Če se nesoglasje nanaša posebej na PFS faze 2, se odločite za podprto skupino ali izrecno odobreno politiko brez PFS. Politike ne sklepajte iz imena napake.

Ko edino prekrivanje zahteva kriptografijo, ki je organizacija ne sprejema več, odločitev pripada prehodu ali migraciji protokola. Širjenje odjemalčevega niza, dokler se kaj ne dogovori, je način, da dostavite znano šibkost z zeleno kljukico ob strani.

Po popravku resničnega neskladja potrdite vzpostavitev IPsec, preden raziščete L2TP in PPP, in vsako poznejšo zavrnitev preverjanja pristnosti obravnavajte kot tisto, ki spada k naslednji stopnji. Nato preizkusite obnovitev v odobrenem preskusnem postopku, ker vzpostavitev prve asociacije ne pove ničesar o preostanku njene življenjske dobe.