L2TP NO_PROPOSAL_CHOSEN: která fáze vlastně selhala?

NO_PROPOSAL_CHOSEN přichází dřív, než se zkontroluje jakékoli uživatelské jméno PPP, což je užitečný fakt a zároveň důvod, proč zpráva mate. Oznamuje, že jedna strana odmítla návrh; neoznamuje, který parametr se rozešel, a neříká nic o tom, zda k odmítnutí došlo při budování asociace IKE, nebo později při vyjednávání ochrany provozu. Za těmito dvěma možnostmi stojí dvě různé opravy a jen jedna z nich zahrnuje zaškrtávací políčko PFS, po kterém lidé sáhnou jako první.

Jedna zpráva, dvě sady návrhů

Uspořádání IKEv1 L2TP/IPsec má dvě vyjednávání za sebou. Fáze 1 staví asociaci zabezpečení IKE ze šifrovacího algoritmu, algoritmu integrity a skupiny Diffie-Hellman. Fáze 2 pak vyjednává, jak bude provoz chráněn, a požadavek PFS patří do tohoto druhého rozhovoru.

Protože fáze jdou po sobě, místo selhání vám řekne, který seznam porovnávat. V tom je celá diagnostická hodnota zprávy a stojí za to ji vytáhnout dřív, než sáhnete na nějaké nastavení.

Proč zaškrtávací políčko PFS nemůže opravit fázi 1

Vypnutí PFS mění vlastnost fáze 2. Pokud se strany nikdy nedohodly na fázi 1, rozhovor ESP vůbec neproběhne, takže políčko nemá na odmítnutí žádný vliv, a proto jeho přepnutí dává stejnou chybu s jiným časovým razítkem.

Opačná chyba je stejně častá. Úspěšná asociace IKE nedokazuje, že návrh ESP je přijatelný, a rozhodně nedokazuje, že skupina fáze 2 odpovídá. Berte zavedený řídicí tunel jako důkaz jen o fázi 1. Lidé čtou zelenou linku jako „tunel běží“ a pak stráví hodinu na špatné fázi, protože jim nic neřeklo, že druhé vyjednávání nezačalo.

Přečtěte si log, než vyberete algoritmy

Seberte zprávy bezprostředně před odmítnutím z backendu, který spojení skutečně obsluhuje, a propojte je se stejným pokusem. Bez tohoto propojení čtete historii jiného spojení a vyvozujete z ní závěry.

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

Z těch řádků odpovězte na dvě otázky: vznikla asociace fáze 1 a která výměna selhala. Tyto dvě odpovědi zužují hledání na jeden seznam atributů. Holé oznámení bez okolního kontextu to nedokáže, ať je vyzkoušet návrh z vlákna na fóru jakkoli lákavé. Zkopírování funkčního řetězce ze stroje s jiným backendem obvykle nahradí jedno odmítnutí jiným, o něco pozdějším.

Syntaxe backendu se nepřenáší

Zapište verzi NetworkManager-l2tp a verzi backendu IPsec, než cokoli porovnáte. Libreswan a strongSwan nesdílejí syntaxi návrhů ani shodné sady algoritmů, takže řetězec, který funguje v jednom, je v druhém syntaktická chyba. Nainstalovaný backend může také IKEv1 odmítnout podle politiky, a pak nebude nikdy přijat žádný návrh.

README projektu tyto rozdíly mezi backendy dokumentuje a pole fáze 1 a fáze 2 drží oddělená. Čtěte ho jako dokumentaci struktury, ne jako pozvání zapnout každou historickou šifru a slabou skupinu, protože spojení, které uspěje jen tím, není spojení, které jste měli postavit.

Dohodněte sadu, potom ověřte etapy

Zeptejte se operátora brány, které sady IKE a ESP jsou podporované a schválené, a pak tento odpis porovnejte se skutečnými návrhy klienta, ne s jeho konfiguračním souborem. Pokud se neshoda týká konkrétně PFS fáze 2, zvolte podporovanou skupinu nebo výslovně schválenou politiku bez PFS. Neodvozujte politiku z názvu chyby.

Když jediný překryv vyžaduje kryptografii, kterou organizace už nepřijímá, rozhodnutí patří bráně nebo migraci protokolu. Rozšiřování klientského řetězce, dokud se něco nedohodne, je způsob, jak dodat známou slabinu se zelenou fajfkou vedle.

Po opravě skutečné neshody potvrďte navázání IPsec, než začnete zkoumat L2TP a PPP, a každé pozdější odmítnutí autentizace berte jako patřící k další etapě. Potom vyzkoušejte obnovu ve schváleném testovacím procesu, protože navázání první asociace neříká nic o zbytku jejího života.