L2TP/IPsec selhává: oddělte IPsec, autentizaci tunelu nebo přihlášení PPP

Uvnitř jednoho připojení L2TP/IPsec se autentizují tři věci a jen jedna z nich se týká člověka, který se připojuje. IPsec prokazuje koncové body tunelu, řídicí připojení L2TP může znovu prokázat protějšky vlastním tajemstvím a potom PPP prokazuje uživatelský účet uvnitř relace. Selhání v kterékoli fázi vypadá v dialogu klienta jako obecná chyba přihlášení a v logu serveru vypadá úplně jinak. Projděte fáze popořadě a zastavte se u první, která selže, protože každá fáze pod neotestovanou je také neotestovaná.

Tři fáze autentizace, tři různé identity

IPsec prokazuje, komu patří koncové body, pomocí předem sdíleného klíče nebo certifikátu. Ta identita patří strojům nebo branám, nikdy ne člověku u klávesnice. Když se protějšky v této fázi nedohodnou, nevymění se vůbec žádný paket L2TP.

Řídicí připojení L2TP může přidat druhou, samostatnou výměnu výzvy a odpovědi řízenou sdíleným tajemstvím, které musí mít oba konce.

RFC 2661 činí tuto autentizaci řídicího připojení volitelnou, což vysvětluje, proč stejná chyba dává na dvou serverech různé příznaky. Nasazení, které nikdy nenastavilo tajemství tunelu, fázi úplně přeskakuje; to, které ho nastavilo jen na jedné straně, selže dřív, než je PPP vůbec nabídnuto. Potom PPP autentizuje uživatele pomocí PAP, CHAP nebo MSCHAPv2 a předá jméno úložišti účtů, které může být místní, v chap-secrets nebo na RADIUS. Špatné heslo v tu chvíli vám stále nechá fungující tunel a neúspěšnou relaci.

Přečtěte si bod zastavení, než začnete upravovat konfiguraci

Začněte s ipsec --version, abyste věděli, zda výstup stavu patří strongSwanu, nebo Libreswanu. Potom čtěte log serveru, ne dialog klienta, protože server zaznamenává, která fáze odmítla.

Obvykle to vyřeší jeden řádek: stížnost na IKE nebo na návrhy je první fáze, zpráva řídicího připojení je druhá a odmítnutí metody PPP nebo účtu je třetí. Zkopírujte ten řádek do tiketu s časovým razítkem. Hádání z klientské strany plýtvá jediným důkazem, který už máte.

Držte klíčový materiál a hesla mimo tuto vložku; název fáze vede práci a uniklý předem sdílený klíč otevře tiket znovu s horšími následky.

První krok: má IPsec asociaci?

Spusťte ipsec statusall na strongSwanu nebo ipsec whack --status na Libreswanu a hledejte navázanou podřízenou asociaci s nenulovými počítadly. ip xfrm state ukazuje pohled jádra na obou. Nainstalovaná dvojice SA s rostoucími počítadly znamená, že první fáze je hotová a můžete jít dál.

Úplná absence asociace ukazuje na adresu protějšku, sadu návrhů nebo předem sdílený klíč a občas na zařízení, které přepisuje UDP 500 a přitom zahazuje UDP 4500. Asociace, která se naváže a po několika sekundách zmizí, je obvykle nesoulad životnosti mezi oběma konci, ne problém s přihlašovacími údaji. Než cokoli přepíšete, zkontrolujte, zda obě strany uvádějí stejné návrhy šifrování a hashování. Pokud ne, žádný klíč nikdy nebude fungovat.

Zastavte se, dokud asociace chybí. Úprava voleb PPP v tu chvíli nic nezmění a skutečnou závadu před dalším člověkem skryje.

Druhý krok: autentizovalo se řídicí připojení L2TP?

Jakmile IPsec běží, sledujte démona L2TP, zda řídicí připojení dosáhne navázaného stavu, protože PPP předtím začít nemůže. Odmítnutí na řídicím připojení znamená, že se tajemství tunelu mezi konci liší, nebo že jeden konec vyžaduje tajemství, které druhý nikdy nepošle. Klienti často nabízejí jediné pole označené jako sdílené tajemství a to obvykle patří IPsecu, ne L2TP. Vyplnění tunelové tajemství nenastaví a vymazání ho nevypne.

Pokud žádná strana nemá nastavené tajemství tunelu, tuto fázi přeskočte a selhání řídicího připojení berte jako dostupnost. Ověřte, že UDP 1701 dorazí k démonovi a že se oba konce shodují na stejném zapouzdření. Pravidlo firewallu napsané pro jednu z těchto dvou podmínek je častou příčinou připojení, které se otevře napůl.

Pouze relace, která začne vyjednávat PPP, skutečně prošla fází tunelu.

Třetí krok: odmítá PPP účet?

Selhání PPP vypadá zvenčí jinak: tunel je navázán, relace začíná a démon zaloguje selhání metody autentizace nebo odmítnutí účtu. Přečtěte si metodu uvedenou v té zprávě. PAP a CHAP selhávají z různých důvodů a server, který jednu odmítá, odmítne klienta, který nabízí jen ji.

Na serveru s Linuxem prohlédněte soubor voleb, který démon předává PPP, obvykle /etc/ppp/options.xl2tpd, a ověřte, které metody se přijímají a kde se účty vyhodnocují. Jméno, které existuje v RADIUS, ale ne v místním souboru tajemství, selže čistě a vypadá jako špatné heslo. Potom zkontrolujte, zda klient nabízí metodu, kterou server přijímá, a ne silnější, o které server odmítá vyjednávat. Změna předem sdíleného klíče kvůli opravě této fáze ztratí odpoledne a nic nezmění.

Když relace konečně naběhne, přidělování adres, DNS a trasy zůstávají neověřené a každé z nich tiše selhává po svém. Držte tři vrstvy v poznámkách oddělené: správný klíč se špatným účtem selže vždy a oprava jedné vrstvy nikdy neopraví jinou.