L2TP/IPsec se připojí v jedné síti a v jiné vyprší

Stejný notebook, stejný profil a stejné heslo fungují v jedné budově a v jiné selžou. To srovnání je nejužitečnější důkaz v tiketu a obvykle je to první věc, která se zahodí. Mezi dvěma přístupovými sítěmi prochází výměna jiným překladem adres, jinými filtry a jinými pomocníky routeru. Ponechat klienta beze změny a změnit jen síť je způsob, jak zjistit, které z toho rozhoduje.

Nejprve zafixujte klienta, pak porovnávejte sítě

Něco na zařízení neměňte, dokud nemáte záznam o funkčním případě: verzi klienta, obsah profilu, název serveru a čas úspěšného připojení. Potom reprodukujte selhání v druhé síti během stejné relace, aby byl stav klienta co nejpodobnější. Profil upravený mezi oběma pokusy zneplatní celé srovnání. Cílem je jedna proměnná a tou proměnnou je síť.

Nejprve potvrďte běžný přístup k internetu v selhávající síti, včetně hostovského portálu, pokud nějaký je. Portál, který nebyl nikdy splněn, vytvoří vypršení, které vypadá přesně jako filtrovaný tunel, a tato kontrola zabere minutu.

Čtyři fáze, čtyři různé chybové zprávy

Připojení L2TP/IPsec prochází čtyřmi fázemi a RFC 3193 popisuje uspořádání, které spojuje první dvě. Vyjednávání IKE je místo, kde filtrovaná cesta vytváří tiché vypršení. Ověřování IPsec je místo, kde neshoda certifikátu nebo předem sdíleného klíče vytvoří místo toho výslovné odmítnutí. Nastavení tunelu L2TP je místo, kde zavedené bezpečnostní přidružení přesto nemusí nikam vést, a přihlášení PPP je místo, kde chybné přihlašovací údaje konečně vytvoří viditelné selhání. Čtěte log pro fázi, která se zastavila, ne pro poslední vytištěný řádek.

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, zda výměna IKE dosáhla návrhu a zda peer vůbec odpověděl, což odděluje dosažitelnost od politiky. Log xl2tpd navazuje tam, kde IPsec končí, takže zavedené bezpečnostní přidružení bez čehokoli v tomto logu ukazuje na fázi L2TP. Dotaz na trasu potvrzuje, že klient odesílá na adresu serveru, kterou předpokládáte, což zachytí zastaralou odpověď DNS zděděnou z předchozí sítě. Dohromady tři výstupy pojmenovávají fázi místo symptomu.

Porovnejte hloubku NAT a chování pomocníka

Průchod NAT přesouvá chráněný provoz do zapouzdření UDP při zjištění překladu, takže čísla portů nesoucí funkční relaci se mohou lišit od těch ve statickém diagramu. Povolení jediného konfiguračního paketu nic nedokazuje o zbytku výměny a externí sken portů vám neřekne, jak peer zachází s platným ověřeným provozem. Druhá vrstva překladu mění obraz znovu, protože mapování nyní existuje dvakrát a vyprší podle dvou různých plánů. Překlad na úrovni operátora u mobilního připojení je obvyklým důvodem, proč funkční kancelářský profil selže na hotspotu telefonu.

Pomocníci routeru se liší stejně jako sítě. Některé firmware zachytávají a přepisují výměnu, jiné jen přestanou provoz zahazovat a jiné uplatní nastavení pouze ve starším režimu. Přečtěte si vlastní popis zaškrtávacího pole od firmware a tam, kde existuje režim kompatibility, otestujte jej jako jednu záměrnou změnu, ne tři najednou.

Odchozí klient, příchozí server: dva různé problémy

Odchozí klient a příchozí server potřebují jinou dosažitelnost směrem nahoru a funkce průchodu, která pomáhá prvnímu, nedělá nic pro druhý. Domácí router, který nechá notebook dosáhnout vzdálené brány, tím nepřijímá příchozí připojení k serveru za ní. Záměna obou vás pošle hledat přesměrování portů, které nikdy nebylo problémem. Než cokoli porovnáte, uveďte, jakou roli selhávající zařízení hraje.

Po podporované změně zopakujte stejné připojení a poznamenejte fázi, které dosáhlo. Uchovávejte funkční profil a poznámku o selhávající síti pohromadě a neresetujte přihlašovací údaje ani přeinstalujte klienta, protože tím zahodíte důkaz, na kterém bylo srovnání postaveno.