L2TP NO_PROPOSAL_CHOSEN: ktorá fáza vlastne zlyhala?

NO_PROPOSAL_CHOSEN prichádza skôr, než sa skontroluje akékoľvek používateľské meno PPP, čo je užitočný fakt a zároveň dôvod, prečo správa zavádza. Oznamuje, že jedna strana návrh zamietla; neoznamuje, ktorý parameter sa nezhodoval, a nehovorí nič o tom, či zamietnutie nastalo pri budovaní asociácie IKE alebo neskôr pri vyjednávaní ochrany prevádzky. Za týmito dvoma možnosťami stoja dve rôzne opravy a len jedna z nich sa týka zaškrtávacieho políčka PFS, po ktorom ľudia siahnu ako prvé.

Jedna správa, dve sady návrhov

Usporiadanie IKEv1 L2TP/IPsec má dve vyjednávania za sebou. Fáza 1 stavia asociáciu zabezpečenia IKE zo šifrovacieho algoritmu, algoritmu integrity a skupiny Diffie-Hellman. Fáza 2 potom vyjednáva, ako bude prevádzka chránená, a požiadavka PFS patrí do tohto druhého rozhovoru.

Keďže fázy idú za sebou, miesto zlyhania vám povie, ktorý zoznam porovnávať. V tom je celá diagnostická hodnota správy a stojí za to ju vytiahnuť skôr, než siahnete na akékoľvek nastavenie.

Prečo zaškrtávacie políčko PFS nedokáže opraviť fázu 1

Vypnutie PFS mení vlastnosť fázy 2. Ak sa strany nikdy nedohodli na fáze 1, rozhovor ESP vôbec neprebehne, takže políčko nemá na zamietnutie žiadny vplyv, a preto jeho prepnutie dáva rovnakú chybu s inou časovou pečiatkou.

Opačná chyba je rovnako častá. Úspešná asociácia IKE nedokazuje, že návrh ESP je prijateľný, a rozhodne nedokazuje, že skupina fázy 2 sedí. Berte zavedený riadiaci tunel ako dôkaz len o fáze 1. Ľudia čítajú zelený riadok ako „tunel beží“ a potom strávia hodinu na nesprávnej fáze, pretože im nič nepovedalo, že druhé vyjednávanie sa nezačalo.

Prečítajte si log, kým vyberiete algoritmy

Zozbierajte správy tesne pred zamietnutím z backendu, ktorý spojenie skutočne obsluhuje, a prepojte ich s tým istým pokusom. Bez tohto prepojenia čítate históriu iného spojenia a vyvodzujete z nej závery.

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

Z tých riadkov odpovedzte na dve otázky: vznikla asociácia fázy 1 a ktorá výmena zlyhala. Tieto dve odpovede zužujú hľadanie na jeden zoznam atribútov. Holé oznámenie bez okolitého kontextu to nedokáže, nech je vyskúšať návrh z vlákna na fóre akokoľvek lákavé. Skopírovanie funkčného reťazca zo stroja s iným backendom zvyčajne nahradí jedno zamietnutie iným, o niečo neskorším.

Syntax backendu sa neprenáša

Zapíšte verziu NetworkManager-l2tp a verziu backendu IPsec, kým čokoľvek porovnáte. Libreswan a strongSwan nezdieľajú syntax návrhov ani rovnaké sady algoritmov, takže reťazec, ktorý funguje v jednom, je v druhom syntaktická chyba. Nainštalovaný backend môže tiež odmietnuť IKEv1 podľa politiky, a potom nebude nikdy prijatý žiadny návrh.

README projektu dokumentuje tieto rozdiely medzi backendmi a drží polia fázy 1 a fázy 2 oddelené. Čítajte ho ako dokumentáciu štruktúry, nie ako pozvanie zapnúť každú historickú šifru a slabú skupinu, pretože spojenie, ktoré uspeje len tak, nie je spojenie, ktoré ste mali postaviť.

Dohodnite sadu, potom overte etapy

Opýtajte sa operátora brány, ktoré sady IKE a ESP sú podporované a schválené, a potom tento údaj porovnajte so skutočnými návrhmi klienta, nie s jeho konfiguračným súborom. Ak sa nezhoda týka konkrétne PFS fázy 2, zvoľte podporovanú skupinu alebo výslovne schválenú politiku bez PFS. Neodvodzujte politiku z názvu chyby.

Keď jediný prienik vyžaduje kryptografiu, ktorú organizácia už neprijíma, rozhodnutie patrí bráne alebo migrácii protokolu. Rozširovanie klientského reťazca, kým sa niečo nedohodne, je spôsob, ako dodať známu slabinu so zelenou fajkou vedľa.

Po oprave skutočnej nezhody potvrďte nadviazanie IPsec, kým začnete skúmať L2TP a PPP, a každé neskoršie zamietnutie autentifikácie berte ako patriace k ďalšej etape. Potom vyskúšajte obnovu v schválenom testovacom procese, pretože nadviazanie prvej asociácie nehovorí nič o zvyšku jej života.