L2TP/IPsec sa pripojí v jednej sieti a v inej vyprší

Rovnaký notebook, rovnaký profil a rovnaké heslo fungujú v jednej budove a v inej zlyhajú. To porovnanie je najužitočnejší dôkaz v tikete a zvyčajne je to prvá vec, ktorá sa zahodí. Medzi dvoma prístupovými sieťami prechádza výmena iným prekladom adries, inými filtrami a inými pomocníkmi routera. Ponechať klienta bez zmeny a zmeniť len sieť je spôsob, ako zistiť, ktoré z toho rozhoduje.

Najprv zafixujte klienta, potom porovnávajte siete

Nič na zariadení nemeňte, kým nemáte záznam o fungujúcom prípade: verziu klienta, obsah profilu, názov servera a čas úspešného pripojenia. Potom reprodukujte zlyhanie v druhej sieti počas tej istej relácie, aby bol stav klienta čo najpodobnejší. Profil upravený medzi oboma pokusmi zneplatní celé porovnanie. Cieľom je jedna premenná a tou premennou je sieť.

Najprv potvrďte bežný prístup na internet v zlyhávajúcej sieti, vrátane hosťovského portálu, ak nejaký je. Portál, ktorý nebol nikdy splnený, vytvorí vypršanie, ktoré vyzerá presne ako filtrovaný tunel, a táto kontrola zaberie minútu.

Štyri fázy, štyri rôzne chybové správy

Pripojenie L2TP/IPsec prechádza štyrmi fázami a RFC 3193 opisuje usporiadanie, ktoré spája prvé dve. Rokovanie IKE je miesto, kde filtrovaná cesta vytvára tiché vypršanie. Overovanie IPsec je miesto, kde nezhoda certifikátu alebo vopred zdieľaného kľúča vytvorí namiesto toho výslovné odmietnutie. Nastavenie tunela L2TP je miesto, kde zavedené bezpečnostné pridruženie predsa len nemusí nikam viesť, a prihlásenie PPP je miesto, kde nesprávne prihlasovacie údaje konečne vytvoria viditeľné zlyhanie. Čítajte log pre fázu, ktorá sa zastavila, nie pre posledný vytlačený riadok.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

Log strongSwan ukazuje, či výmena IKE dosiahla návrh a či peer vôbec odpovedal, čo oddeľuje dosiahnuteľnosť od politiky. Log xl2tpd nadväzuje tam, kde IPsec končí, takže zavedené bezpečnostné pridruženie bez čohokoľvek v tomto logu ukazuje na fázu L2TP. Dotaz na trasu potvrdzuje, že klient odosiela na adresu servera, ktorú predpokladáte, čo zachytí zastaranú odpoveď DNS zdedenú z predchádzajúcej siete. Dohromady tri výstupy pomenúvajú fázu namiesto symptómu.

Porovnajte hĺbku NAT a správanie pomocníka

Prechod NAT presúva chránenú prevádzku do zapuzdrenia UDP pri zistení prekladu, takže čísla portov nesúcich fungujúcu reláciu sa môžu líšiť od tých v statickom diagrame. Povolenie jediného konfiguračného paketu nič nedokazuje o zvyšku výmeny a externé skenovanie portov vám nepovie, ako peer zaobchádza s platnou overenou prevádzkou. Druhá vrstva prekladu mení obraz znova, pretože mapovanie teraz existuje dvakrát a vyprší podľa dvoch rôznych plánov. Preklad na úrovni operátora pri mobilnom pripojení je obvyklým dôvodom, prečo funkčný kancelársky profil zlyhá na hotspote telefónu.

Pomocníci routera sa líšia rovnako ako siete. Niektoré firmvéry zachytávajú a prepisujú výmenu, iné len prestanú prevádzku zahadzovať a iné uplatnia nastavenie iba v staršom režime. Prečítajte si vlastný opis zaškrtávacieho poľa od firmvéru a tam, kde existuje režim kompatibility, otestujte ho ako jednu zámernú zmenu, nie tri naraz.

Odchádzajúci klient, prichádzajúci server: dva rôzne problémy

Odchádzajúci klient a prichádzajúci server potrebujú inú dosiahnuteľnosť smerom nahor a funkcia priechodu, ktorá pomáha prvému, nerobí nič pre druhý. Domáci router, ktorý nechá notebook dosiahnuť vzdialenú bránu, tým neprijíma prichádzajúce pripojenia k serveru za ňou. Zámena oboch vás pošle hľadať presmerovanie portov, ktoré nikdy nebolo problémom. Skôr než čokoľvek porovnáte, uveďte, akú úlohu zlyhávajúce zariadenie hrá.

Po podporovanej zmene zopakujte rovnaké pripojenie a poznačte fázu, ktorú dosiahlo. Uchovávajte funkčný profil a poznámku o zlyhávajúcej sieti pohromade a neresetujte prihlasovacie údaje ani nepreinštalujte klienta, pretože tým zahodíte dôkaz, na ktorom bolo porovnanie postavené.