L2TP, GRE alebo IPsec: ktorá vrstva má niesť reláciu?

Dve otázky sa zamotajú vždy, keď sa L2TP, GRE a IPsec ocitnú v tej istej návrhovej poznámke: ktorú reláciu nesiem a ktorá vrstva ju chráni? Ak je prvá nesprávna, všetko nižšie zostáva vnútorne konzistentné, no rieši nesprávny problém — smerovaný prekryv postavený tam, kde sa používatelia potrebovali pripojiť, alebo koncentrátor pripojenia stojaci namiesto brány medzi lokalitami. Pracovný list nižšie vynúti tento rozdiel skôr, než sa niekto prihlási do zariadenia. Vyplňte ho v poradí a každý riadok sa stane niečím, čo môžete otestovať samostatne.

Začnite reláciou, nie zoznamom protokolov

Vzdialený používateľ s PPP reláciou a smerovaný prekryv medzi dvoma bránami sú dva odlišné sieťové vzťahy, aj keď oba nakoniec skončia zabalené v IPsec. Prvý ukončuje prepojenie pre každého používateľa a potrebuje prideľovanie adries, autentifikáciu osoby alebo zariadenia a politiku, ktorá vymenúva, ku ktorým interným sieťam sa ten používateľ dostane. Druhý preposiela pakety medzi lokalitami, do ktorých sa nikto nepripája.

Napíšte jednu vetu, ktorá pomenuje, ktorý z dvoch staviate, a potom si ju prečítajte tak, ako keby ste boli človek, ktorý ju má prevádzkovať. Ak veta potrebuje slovo „a“, staviate oba, a pracovný list potrebuje dva stĺpce namiesto jedného kompromisného stĺpca, ktorý každému slúži spolovice. Ak pomenuje používateľa, ale nie fond adries, alebo prefix, ale nie politiku preposielania, veta je stále neúplná. Formulácia znie byrokraticky, ale toto je najlacnejšie miesto, kde zachytiť návrh, ktorý by sa inak odhalil cez tikets podpory.

Dajte každej vrstve presne jednu úlohu

L2TPv2 nesie PPP relácie medzi svojimi dvoma koncovými bodmi. PPP vedie vyjednávanie prepojenia a, keď je vyjednané, autentifikáciu používateľa; L2TP nepridáva žiadnu kryptografiu, takže holý L2TP démon neimplementuje žiadnu časť bezpečnostného vzťahu IPsec a patrí len do prepojenia, ktorému už dôverujete.

GRE je zapuzdrenie medzi dvoma adresami. Prenáša pakety sieťovej vrstvy cez logický prekryv a sám o sebe neponúka ani dôvernosť, ani autentifikovanú identitu partnera. To nie je chyba: hlavička bola navrhnutá jednoducho, aby zostala lacná na spracovanie v preposielacom hardvéri. Dôsledkom je, že GRE odpovedá len na otázku, ako presunúť tento paket medzi dvoma adresami, a na nič iné, a to je presne otázka, ktorú by ste sa ho mali opýtať.

Zostáva IPsec ako vrstva, ktorá vyberá prevádzku, autentifikuje partnerov a šifruje to, čo jej bolo povedané chrániť. Ktorú prevádzku chráni, je konfiguračné rozhodnutie, ktoré musí zodpovedať zapuzdreniu, ktoré koncové body skutočne generujú, pretože politika napísaná pre vonkajšiu adresu GRE sa správa inak než tá napísaná pre interné prefixy. Špecifikácia GRE drží užitočné zaťaženie, hlavičku GRE a vonkajší doručovací protokol viditeľne oddelené a vaša politika potrebuje rovnaké oddelenie.

Napíšte cestu paketu pred konfiguráciou

Vezmite jeden paket a vymenujte každú hlavičku, ktorá sa pridá, v poradí, v akom sa pridá, a pomenujte zariadenie, ktoré ju pridáva. Pre pripájajúceho sa používateľa je to zvyčajne PPP vnútri L2TP vnútri IPsec; pre prekryv lokality je to vnútorný IP paket vnútri GRE vnútri IPsec. Ak dve zariadenia pridávajú rovnakú hlavičku, máte slučku alebo zdvojený tunel a žiadna úprava politiky to nespraví.

Ten istý zoznam určuje MTU, pretože použiteľná vnútorná veľkosť je namerané MTU cesty mínus práve vymenované hlavičky a nič iné. Nekopírujte číslo z príspevku na fóre: spočítajte režijné náklady vonkajšej IP, UDP a ESP, potom GRE alebo L2TP, potom PPP tam, kde platí, a odpočítajte od MTU cesty, ktoré ste skutočne namerali. Príznaky, ktoré sa objavia len pri veľkých prenosoch, alebo relácie, ktoré sa vytvoria a potom zomrú na prvej veľkej odpovedi, zvyčajne vedú späť k tomu, že toto sčítanie bolo urobené odhadom.

Skontrolujte každú vrstvu samostatne, zvonka dovnútra

Spustite kontroly v poradí a zastavte pri prvej, ktorá zlyhá. Každý riadok odpovedá na inú otázku, takže zlyhanie ukazuje na jeden stĺpec pracovného listu namiesto tvrdenia, že tunel je pokazený.

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 zostave Cisco je ekvivalent závislý od roly a presná syntax závisí od platformy a vydania: show crypto session pre partnerov IPsec, počítadlá rozhrania pre rozhranie GRE alebo tunela a overenie VPDN alebo PPP pre rolu pripájania. Sada príkazov, ktorá ukončí PPP, nič nedokazuje o podpore GRE a fungujúce rozhranie GRE nič nedokazuje o službe PPP, preto overte rolu, ktorú ste skutočne nakonfigurovali, a nie tú na diagrame.

Zapíšte každý výstup vedľa riadku pracovného listu, ku ktorému patrí. Poznámky urobené počas aktívnej poruchy majú väčšiu hodnotu než topológia neskôr prekreslená z pamäti.

Zoraďte rozobratie a potom znova overte

Rozobratie ide v opačnom poradí z nejakého dôvodu: vyberte chránenú prevádzku z politiky IPsec skôr, než odstránite zapuzdrenie, pre ktoré bola napísaná, inak politika ďalej ukazuje na rozhranie, ktoré už neexistuje, a nasledujúce načítanie konfigurácie zlyhá na mieste, ktoré vyzerá nesúvislo. Na Linuxe to znamená zmazať záznamy stavu a politiky pred rozhraním tunela; na smerovači odstrániť kryptografickú mapu alebo záznam profilu pred tunelom.

Po prestavbe zopakujte štyri pozorovania prijatia jedno po druhom: vonkajšia dostupnosť, vytvorené pridruženie IPsec, vytvorená PPP relácia tam, kde ju návrh zahŕňa, a vnútorné preposielanie na skutočnú cieľovú adresu. Jedno zelené svetlo nie je dôkazom pre ostatné tri a práve tá medzera je porucha, ktorá v produkcii prežíva najdlhšie — tunel, ktorý je hore, šifrovaný a nič nepreposiela, pretože vnútorná trasa nebola nikdy pridaná.

Uchovajte vyplnený pracovný list vedľa konfigurácie zariadenia. Každý stĺpec, ktorý nedokážete vyplniť, je vrstva bez priradenej úlohy a vrstva bez úlohy je zvyčajne vrstva, ktorá by v zásobníku nemala byť.