Implementujeme Carrier Grade NAT: zálohování

Tomáš Podermański 22. 6. 2015

V minulém článku jsme si popsali základní východiska implementace Carrier Grade NAT implementovaného poskytovatelem. Dnes se podíváme, jak nasadit CGN do sítě tak, aby netvořil SPoF (Single Point of Failure) a byl tedy implementován v redundantní podobě. Dále se podíváme, jak řešit distribuci zátěže mezi více CGN.

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ě.

widgety

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

Vlastnost Active-StandBy CGN Autonomní CGN
Narušení dříve ustavených TCP relací pří přechodu na záložní CGN
NE
ANO
Závislost všech CGN na konkrétním výrobci nebo typu zařízení
ANO
NE
Škálovatelnost a možnost distribuce zátěže
max. 2 CGN
neomezená
Možnost vzdálené geografické redundance
NE
ANO

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.

Našli jste v článku chybu?
120na80.cz: Poslední možnost změnit zdravotní pojišťovnu

Poslední možnost změnit zdravotní pojišťovnu

DigiZone.cz: Banaxi: videa kdekoli na světě

Banaxi: videa kdekoli na světě

DigiZone.cz: Na jaká videa se vlastně díváme

Na jaká videa se vlastně díváme

Vitalia.cz: Tesco nabízí desítky tun jídla zdarma

Tesco nabízí desítky tun jídla zdarma

Lupa.cz: Proč jsou firemní počítače pomalé?

Proč jsou firemní počítače pomalé?

DigiZone.cz: Rapl: seriál, který vás smíří s ČT

Rapl: seriál, který vás smíří s ČT

Lupa.cz: Jak levné procesory změnily svět?

Jak levné procesory změnily svět?

DigiZone.cz: Technisat připravuje trojici DAB

Technisat připravuje trojici DAB

Podnikatel.cz: Tyto pojmy k #EET byste měli znát

Tyto pojmy k #EET byste měli znát

Lupa.cz: Další Češi si nechali vložit do těla čip

Další Češi si nechali vložit do těla čip

Podnikatel.cz: ČSSZ posílá přehled o důchodovém kontě

ČSSZ posílá přehled o důchodovém kontě

Vitalia.cz: dTest odhalil ten nejlepší kečup

dTest odhalil ten nejlepší kečup

DigiZone.cz: Nova opět stahuje „milionáře“

Nova opět stahuje „milionáře“

Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?

Podnikatel.cz: Byla finanční manažerka, teď cvičí jógu

Byla finanční manažerka, teď cvičí jógu

Podnikatel.cz: Letáky? Lidi zuří, ale ony stále fungují

Letáky? Lidi zuří, ale ony stále fungují

DigiZone.cz: Světový pohár v přímém přenosu na ČT

Světový pohár v přímém přenosu na ČT

Podnikatel.cz: Udělali jsme velkou chybu, napsal Čupr

Udělali jsme velkou chybu, napsal Čupr

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?