L2TP, GRE nebo IPsec: která vrstva má nést relaci?

Dvě otázky se zamotají, jakmile se L2TP, GRE a IPsec ocitnou ve stejné návrhové poznámce: kterou relaci nesu a která vrstva ji chrání? Chyba v první nechá všechno níže vnitřně konzistentní, zatímco se řeší špatný problém — směrovaný překryv postavený tam, kde se uživatelé měli připojovat vytáčením, nebo koncentrátor vytáčeného přístupu místo brány mezi lokalitami. Pracovní list níže vynutí toto rozlišení dřív, než se někdo přihlásí do zařízení. Vyplňte ho popořadě a každý řádek se stane něčím, co lze otestovat samostatně.

Začněte u relace, ne u seznamu protokolů

Vzdálený uživatel s relací PPP a směrovaný překryv mezi dvěma branami jsou různé síťové vztahy, i když oba nakonec skončí zabalené v IPsec. První ukončuje spojení na uživatele a potřebuje přidělení adres, ověření osoby nebo zařízení a politiku, která pojmenuje interní sítě, kam se tento uživatel smí dostat. Druhý přeposílá pakety mezi lokalitami, kam nikdo nevytáčí.

Napište jednu větu, která pojmenuje, kterou ze dvou stavíte, a pak si ji přečtěte, jako byste byl člověk, který ji má provozovat. Pokud věta potřebuje slovo „a“, stavíte obě a pracovní list potřebuje dva sloupce místo jednoho kompromisního, který každé slouží napůl. Pokud uvádí uživatele, ale ne fond adres, nebo prefix, ale ne politiku předávání, věta je stále neúplná. Formulace zní byrokraticky, ale je to nejlevnější místo, kde chytit návrh, který by jinak objevil tiket na podporu.

Dejte každé vrstvě přesně jeden úkol

L2TPv2 nese relace PPP mezi svými dvěma koncovými body. PPP vede vyjednávání odkazu a, když se vyjednává, ověření uživatele; L2TP nepřidává žádnou kryptografii, takže holý daemon L2TP neimplementuje nic ze vztahu zabezpečení IPsec a patří jen dovnitř odkazu, kterému už důvěřujete.

GRE je zapouzdření mezi dvěma adresami. Nese pakety síťové vrstvy přes logický překryv a sám o sobě nenabízí ani důvěrnost, ani ověřenou identitu protistrany. To není vada: hlavička byla navržena jednoduše, aby zůstala levná na zpracování v přeposílacím hardwaru. Důsledkem je, že GRE odpovídá na otázku „jak přenesu tento paket mezi dvěma adresami“ a na nic jiného — přesně na tu otázku, kterou mu máte klást.

Tím zůstává IPsec jako vrstva, která vybírá provoz, ověřuje protistrany a šifruje to, co jí bylo uloženo chránit. Který provoz chrání, je konfigurační rozhodnutí, které musí odpovídat zapouzdření, jež koncové body skutečně vytvářejí, protože politika napsaná pro vnější adresu GRE se chová jinak než politika pro vnitřní prefixy. Specifikace GRE drží užitečné zatížení, hlavičku GRE a vnější doručovací protokol viditelně oddělené a vaše politika potřebuje stejné oddělení.

Napište cestu paketu před konfigurací

Vezměte jeden paket a vypište každou přidávanou hlavičku v pořadí, v jakém se přidává, a pojmenujte zařízení, které ji přidává. Pro uživatele vytáčeného přístupu to bývá PPP uvnitř L2TP uvnitř IPsec; pro překryv lokalit vnitřní paket IP uvnitř GRE uvnitř IPsec. Pokud dvě zařízení přidávají stejnou hlavičku, máte smyčku nebo duplikovaný tunel a žádná úprava politiky to nespraví.

Stejný seznam rozhoduje o MTU, protože použitelná vnitřní velikost je naměřené MTU cesty minus právě vyjmenované hlavičky a nic jiného. Neopisujte číslo z příspěvku na fóru: sečtěte režii vnějšího IP, UDP a ESP, pak GRE nebo L2TP, pak PPP, kde se uplatní, a odečtěte od MTU cesty, které jste skutečně naměřili. Příznaky, které se objeví jen při velkých přenosech, nebo relace, které se navážou a pak zemřou na první velké odpovědi, obvykle vedou k tomu, že se tento součet odhadl.

Kontrolujte každou vrstvu zvlášť, zvenčí dovnitř

Provádějte kontroly popořadě a zastavte se u první, která selže. Každý řádek odpovídá na jinou otázku, takže selhání ukazuje na sloupec pracovního listu, místo aby říkalo, že tunel je rozbitý.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Na zařízení Cisco je ekvivalent závislý na roli a přesná syntaxe závisí na platformě a verzi: show crypto session pro protistrany IPsec, počítadla rozhraní pro rozhraní GRE nebo tunelu a ověření VPDN nebo PPP pro roli vytáčeného přístupu. Sada příkazů, která ukončí PPP, nic nedokazuje o podpoře GRE, a fungující rozhraní GRE nic nedokazuje o službě PPP, proto ověřujte roli, kterou jste skutečně nakonfigurovali, a ne tu z diagramu.

Zapisujte každý výstup vedle řádku pracovního listu, ke kterému patří. Poznámky pořízené, dokud je závada aktivní, mají větší cenu než topologie překreslená potom z paměti.

Uspořádejte demontáž, pak ověřte znovu

Demontáž probíhá v opačném pořadí z nějakého důvodu: vyjměte chráněný provoz z politiky IPsec dřív, než odstraníte zapouzdření, pro které byla napsána, jinak politika dál ukazuje na rozhraní, které už neexistuje, a následné načtení konfigurace selže na místě, které vypadá nesouvisele. V Linuxu to znamená smazat položky stavu a politiky před rozhraním tunelu; na routeru odstranit položku crypto map nebo profilu před tunelem.

Po přestavbě zopakujte čtyři přejímací pozorování jedno po druhém: vnější dosažitelnost, navázané přidružení IPsec, navázaná relace PPP tam, kde ji návrh obsahuje, a vnitřní předávání na skutečnou cílovou adresu. Jedno zelené světlo není důkazem pro ostatní tři a tato mezera je závada, která v provozu přežívá nejdéle — tunel, který je nahoře, šifrovaný a nic nepředává, protože vnitřní trasa nebyla nikdy přidána.

Uchovávejte vyplněný pracovní list vedle konfigurace zařízení. Každý sloupec, který nemůžete vyplnit, je vrstva bez přiděleného úkolu a vrstva bez přiděleného úkolu obvykle nemá ve stohu co dělat.