L2TP/IPsec nefunguje: izolujte IPsec, autentifikáciu tunela alebo prihlásenie PPP

V jednom pripojení L2TP/IPsec sa autentifikujú tri veci a iba jedna z nich sa týka človeka, ktorý vytáča. IPsec dokazuje koncové body tunela, riadiace pripojenie L2TP môže znova dokázať partnerov vlastným tajomstvom a potom PPP dokazuje používateľský účet v rámci relácie. Zlyhanie v ktoromkoľvek kroku vyzerá v dialógu klienta ako všeobecná chyba prihlásenia a v logu servera vyzerá úplne inak. Prechádzajte fázy v poradí a zastavte sa pri prvej, ktorá zlyhá, pretože každá fáza pod netestovanou je tiež netestovaná.

Tri fázy autentifikácie, tri rôzne identity

IPsec dokazuje, komu patria koncové body, pomocou vopred zdieľaného kľúča alebo certifikátu. Táto identita patrí strojom alebo bránam, nikdy nie človeku pri klávesnici. Keď sa partneri v tejto fáze nedohodnú, nevymení sa vôbec žiadny paket L2TP.

Riadiace pripojenie L2TP môže pridať druhú, samostatnú výmenu výzva-odpoveď, ktorú riadi spoločné tajomstvo, ktoré musia mať oba konce.

RFC 2661 robí túto autentifikáciu riadiaceho pripojenia voliteľnou, čo vysvetľuje, prečo tá istá chyba dáva na dvoch serveroch rôzne príznaky. Nasadenie, ktoré nikdy nenastavilo tajomstvo tunela, krok úplne preskočí; to, ktoré ho nastavilo iba na jednej strane, zlyhá skôr, než sa PPP vôbec ponúkne. Potom PPP autentifikuje používateľa pomocou PAP, CHAP alebo MSCHAPv2 a odovzdá meno úložisku účtov, ktoré môže byť lokálne, v chap-secrets alebo na RADIUS. Nesprávne heslo v tom bode vás stále nechá s fungujúcim tunelom a neúspešnou reláciou.

Prečítajte si miesto zastavenia, kým upravíte konfiguráciu

Začnite s ipsec --version, aby ste vedeli, či výstup stavu patrí strongSwan alebo Libreswan. Potom čítajte log servera, nie dialóg klienta, pretože server zaznamenáva, ktorá fáza odmietla.

Jedna riadok zvyčajne vyrieši tiket: sťažnosť na IKE alebo návrhy je prvá fáza, správa o riadiacom pripojení je druhá fáza a odmietnutie metódy PPP alebo účtu je tretia fáza. Skopírujte ten riadok do tiketu s časovou značkou. Hádanie z klientskej strany premrhá jediný dôkaz, ktorý už máte.

Držte kľúčový materiál a heslá mimo toho vloženia; názov fázy usmerňuje prácu a uniknutý vopred zdieľaný kľúč znova otvorí tiket s horšími následkami.

Prvá fáza: má IPsec asociáciu?

Spustite ipsec statusall na strongSwan alebo ipsec whack --status na Libreswan a hľadajte vytvorenú podradenú asociáciu s nenulovými počítadlami. ip xfrm state zobrazuje pohľad jadra na oboch. Nainštalovaná dvojica SA s rastúcimi počítadlami znamená, že prvá fáza je hotová a môžete pokračovať.

Úplná absencia asociácie ukazuje na adresu partnera, množinu návrhov alebo vopred zdieľaný kľúč a niekedy na zariadenie, ktoré prepisuje UDP 500, ale zahadzuje UDP 4500. Asociácia, ktorá sa vytvorí a potom po niekoľkých sekundách zmizne, je zvyčajne nesúlad životnosti medzi koncami, nie problém s prihlasovacími údajmi. Skontrolujte, či obe strany uvádzajú rovnaké návrhy šifrovania a hashu, kým čokoľvek znova napíšete. Ak nie, žiadny kľúč nikdy nebude fungovať.

Zastavte sa, kým asociácia chýba. Úprava možností PPP v tom bode nič nemení a skrýva skutočnú poruchu pred ďalším človekom.

Druhá fáza: autentifikovalo sa riadiace pripojenie L2TP?

Keď IPsec beží, sledujte démona L2TP, či riadiace pripojenie dosiahne vytvorený stav, pretože PPP nemôže začať skôr. Odmietnutie na riadiacom pripojení znamená, že tajomstvo tunela sa medzi koncami líši, alebo jeden koniec žiada tajomstvo, ktoré druhý nikdy neposiela. Klienti často zobrazujú jedno pole s označením shared secret a to zvyčajne patrí IPsec, nie L2TP. Vyplnenie ho nenastaví tajomstvo tunela a vymazanie ho nevypne.

Ak ani jedna strana nenastavila tajomstvo tunela, tento krok preskočte a zlyhanie riadiaceho pripojenia berte ako problém dostupnosti. Potvrďte, že UDP 1701 sa dostane k démonovi a oba konce sa zhodnú na rovnakom zapuzdrení. Pravidlo firewallu napísané pre jednu z týchto dvoch podmienok je častou príčinou spojenia, ktoré sa otvára len na polovicu.

Len relácia, ktorá začne vyjednávať PPP, skutočne prešla fázou tunela.

Tretia fáza: odmieta PPP účet?

Zlyhanie PPP vyzerá zvonku inak: tunel je vytvorený, relácia sa začína a démon zaznamená zlyhanie metódy autentifikácie alebo odmietnutie účtu. Prečítajte si metódu uvedenú v tej správe. PAP a CHAP zlyhávajú z rôznych dôvodov a server, ktorý jednu odmietne, odmietne klienta, ktorý ponúka iba tú.

Na serveri Linux skontrolujte súbor možností, ktorý démon odovzdáva PPP, zvyčajne /etc/ppp/options.xl2tpd, a potvrďte, ktoré metódy sú akceptované a kde sa účty riešia. Meno, ktoré existuje v RADIUS, ale nie v lokálnom súbore tajomstiev, zlyhá čisto a vyzerá ako nesprávne heslo. Potom skontrolujte, či klient ponúka metódu, ktorú server akceptuje, a nie silnejšiu, ktorej vyjednávanie server odmieta. Zmena vopred zdieľaného kľúča na opravu tejto fázy premrhá popoludnie a nič nezmení.

Keď relácia konečne nabehne, prideľovanie adries, DNS a trasy ešte nie sú overené, a každá zlyhá potichu po svojom. Držte tri vrstvy oddelene vo svojich poznámkach: správny kľúč s nesprávnym účtom vždy zlyhá a oprava jednej vrstvy nikdy neopraví inú.