Implementujeme Carrier Grade NAT: zálohování

V předchozím článku jsme v našich úvahách o CGN mlčky předpokládali, že síť ISP je připojená pouze prostřednictvím jednoho tranzitního poskytovatele a tím pádem putuje veškerý provoz ze sítě do Internetu a zpět vždy jedním zařízením. To je u rozsáhlejších sítí značně neobvyklé a každá středně velká nebo větší síť má zpravidla hned několik styčných bodů s okolním světem (EXITů), ať už s poskytovateli tranzitní konektivity anebo peeringové propoje s ostatními sítěmi.

Dříve, než se pustíme do řešení problematiky CGN na více EXITech, si však uděláme opět menší odbočku. Obecný princip doručování paketů v Internetu se často označuje termínem „Hot-potato routing“. Tento princip lze chápat tak, že paket z naší sítě předáme do cílové sítě pro nás tou nejkratší možnou cestou a na nejbližším možném EXITu. Nejkratší cestou se myslí nejkratší z hlediska logické topologie. Pakety s odpovědí, které mají dorazit zpět do naší sítě, jsou druhou stranou doručovány stejným principem, nicméně z pohledu druhé sítě může optimální cesta do naší sítě vypadat jinak. Výsledkem může být situace, kdy data od nás do cílové sítě tečou jinou cestou než zpět. Tomuto stavu říkáme asymetrické směrování a ve světě Internetu se jedná o naprosto běžný a přirozený stav.

Existence asymetrie ve směrování nám ovšem výrazným způsobem komplikuje implementaci CGN. Jak jsme si minule ukázali, CGN je stavové zařízení, které pro svou správnou funkci potřebuje mít kontrolu jak nad příchozími, tak i odchozími pakety. Jak z tohoto problému ven? Obecně existují dvě řešení, kde má každé trochu jiné vlastnosti a hodí se pro jinou situaci. Pojďme se na ně podívat detailněji.

Active-StandBy CGN s výměnou stavových informací

Představme si situaci, kdy máme dvě nezávislá zařízení realizující společně hraniční směrovač i CGN - CGN1 a CGN2. Pakety z naší sítě do vzdálené sítě putují ve výchozím stavu přes CGN1 a odpovědi se vrací přes CGN2. Zde nastává výše zmíněný problém. CGN1 totiž provede překlad adresy a portů a vloží záznam o způsobu překladu do své překladové tabulky. Paket s odpovědí ovšem přijde na CGN2, který ale nemá příslušnou stavovou informaci, tedy neví, jak zpětný překlad provést. Pro řešení problému se nabízí jisté přímočaré řešení. V okamžiku vzniku stavové informace na CGN1 se tato informace současně předá na CGN2, který si ji zařadí do své překladové tabulky. V okamžiku kdy na CGN2 dorazí ze vzdálené sítě paket s odpovědí, je na CGN2 již připravená stavová informace o překladu a tím pádem je možné zpětný překlad provést. Situaci zachycuje následující obrázek:

Již na první pohled je zřejmé, že tento přístup nebude zcela bezproblémový. Výměna stavových informací mezí CGN1 a CGN2 musí totiž probíhat dostatečně rychle, aby na CGN2 byla připravená stavová informace dříve, než dorazí paket s odpovědí. Splnění této podmínky může být v některých případech velmi obtížně zajistitelné. Na rozdíl od samotného překladu, který bývá realizován ve specializovaném hardware, je přenos stavových informací zpravidla realizován s účastí řídícího CPU, kde můžeme narážet na výkonnostní problémy. Tyto skutečnosti vedou k tomu, že implementace zálohovaného CGN v této podobě zůstává spíše teoretickým konceptem. Přestože je možné některá zařízení v tomto režimu provozovat, dokumentace vesměs nabádá se tomuto režimu vyhnout.

Tím ovšem tento koncept není vyloučen z praktického použití. Dobře se totiž dá použít v omezenější podobě, kdy zařízení provozujeme v režimu Active - Standby. V této konfigurací je jeden CGN určen jako hlavní (Active) a druhý (Standby) je připraven v řádech milisekund až sekund převzít jeho úlohu. Rychlost přenosu stavových informací již v tomto případě není až tak kritická, protože veškerý datový provoz pro oba směry je vždy veden jedním CGN. Vyhnuli jsme se tedy asymetrickému směrování, protože z pohledu logické topologie provozujeme pouze jedno zařízení. Samotný přenos stavových informací mezi CGN nám v tomto případě ale nestačí. Musíme jej doplnit vhodným mechanismem řešícím redundanci IP adres veřejného rozhraní CGN. Z vnějšího pohledu se totiž obě zařízení musí tvářit, že mají stejnou IP adresu. Zde záleží na výrobci CGN, který mechanismus poskytuje. Obecně se k tomuto účelu používají protokoly HSRP či VRRP v kombinaci s běžnými směrovacími protokoly. Přestože zde rychlost přenosu stavových informací už není tak kritická, výrobci doporučují mít CGN propojené jednou či dvěma linkami vyhrazenými čistě pro pro přenos stavových informací, čímž se značně omezují možností vzájemné geografické redundance. Pro vyměňování stavových informací mezi CGN navíc neexistuje žádný standardní protokol, takže je možné v tomto režimu propojovat pouze zařízení jednoho výrobce nebo v některých případech jednoho typu.

Autonomní CGN se specifickými adresními rozsahy

Dalším možným řešením problému zálohování je provozování CGN v podobě autonomních zařízení, kde každé zařízení provádí překlad adres na jiný veřejný adresní rozsah. Na následujícím obrázku si ukážeme, jak celá věc funguje.

V síti máme dva CGN, kde každý má přidělen svůj adresní rozsah. Prostřednictvím směrovacího protokolu zajistíme, že veřejný adresní rozsah použitý na jednotlivých CGN propagujeme do sítě vždy pouze z daného zařízení - např. adresní rozsah 147.229.63.0/24 je propagován do sítě pouze z CGN1. Tímto si prakticky vynutíme, že pakety s odpovědí vždy dorazí zpět přesně na ten CGN, který byl použit pro překlad adresy. V uvedeném příkladě jsme navíc pro jednotlivé CGN použili adresové rozsahy v délce 24 bitů. Důvod k tomu je prostý. Je obecným zvykem, že 24 bitů je maximální možná délka prefixu akceptována vetšinou sítí při výměně globálních směrovacích informací protokolem BGP. Použitím prefixu této délky si ve směrovací politice můžeme explicitně vynutit, aby vnější sítě zasílaly data s odpověďmi právě tím EXITem, který se nachází nejblíže příslušnému CGN.

Pokud například koncové zařízení zašle paket na cílovou adresu 195.113.144.230 přes CPE s s IP adresou 100.64.2.3, nejbližší cesta do dané sítě vede přes CGN1. CGN1 upraví položky paketu, jak jsme si popsali dříve, a odešle paket do cílové sítě. Díky tomu, že veřejná IP adresa, která se při překladu použije, je z rozsahu adres propagovaných pouze z CGN1, odpověď se vrátí na stejné zařízení.

Představme si nyní, že CGN1 postihl výpadek. Směrovací protokoly automaticky zajistí, že ve vnitřní síti nebude k dispozici cesta do Internetu skrz CGN1. Veškerý odchozí provoz tudíž poteče jinudy, například přes CGN2, jak je zachyceno na obrázku tečkovaným průběhem. Pakety z adresy 100.64.2.3 na cílovou adresu 195.113.144.230 tedy dorazí na CGN2, který provede překlad na adresu z prefixu přidělenému CGN2, například 147.229.64.10.

Zdá se, že zálohování tímto způsobem funguje a data jsou doručována tam, kam je třeba. Je zde ovšem jedna vada na kráse. V okamžiku překlopení provozu z CGN1 na CGN2 se změní rovněž veřejná adresa, na kterou je prováděn překlad. To ve světě protokolu TCP znamená, že dojde k přerušení příslušného TCP sezení. To nijak zásadně nevadí u valné většiny webových aplikací. Problém nastává u aplikací typu ssh nebo telnet, kde je nutno po změně znovu navázat příslušná sezení.

Další vlastnosti tohoto uspořádání CGN jsou už vcelku příjemné. Jednotlivé CGN mezi sebou nijak nekomunikují a je zcela lhostejné, jaké zvolíme jejich geografické rozmístění. Stran počtu CGN se nemusíme omezovat pouze na dvě instance, jako u režimu Active - Standby. Ve spolupráci se směrovacími protokoly můžeme rovněž snadno implementovat vyvažování zátěže mezi jednotlivými CGN, případně realizovat zálohované řešení v kombinaci 1+N. Vyvažování zátěže je zachyceno i na následujícím obrázku, kdy je komunikace z/do sítě označené „Poskytovatel obsahu 2“ vedena přes CGN3. V tomto případě je překlad prováděn na adresy z prefixu 147.229.65.0/24. Nezanedbatelným faktorem je rovněž snadnější a přehlednější konfigurace, což oceníme zejména při hledání problémů.

Jak jsme si ukázali, každý z uvedených přístupů má své klady a zápory. Rozhodujícím faktorem při volbě prvního nebo druhého řešení tak bude zřejmě podmínka zachování běžících TCP relací při přechodu na zálohu. V praxi samozřejmě nic nebrání kombinování jednotlivých principů. V každé lokalitě může být umístěna dvojice Active-Standby CGN, které navenek tvoří Autonomní CGN vůči jiné lokalitě.

Pro přehlednost uvádíme tabulku s výhodami a nevýhodami jednotlivých přístupů:

Závěr

V dnešním díle jsme popsali techniky, kterých lze použít pro zálohování CGN. Díky tomu, že CGN je kritické zařízení v síti, jehož výpadek postihne velké množství uživatelů, nějaká forma zálohování by měla být implementovaná vždy. Příště se podíváme na prostředky potřebné pro monitoring CGN, pokusíme se prozkoumat možná alternativní řešení a podíváme se na možnosti integrace CGN s protokolem IPv6.