CGN před zákonem
Společně s implementací CGN vzniká v síti nový problém, a tím je identifikace koncových uživatelů nebo zařízení umístěných za CGN. Zatímco v sítích, kde se přidělují veřejné IP adresy, je nalezení vazby mezi uživatelem a IP adresou celkem přímočaré, v případě CGN tomu tak již není. Všichni uživatelé jsou totiž „skrytí“ za blokem veřejných IP adres. Tento fakt výrazným způsobem komplikuje například účtování (accounting) nebo řešení bezpečnostních incidentů. Pro operátory poskytující služby podle zákona o elektronických komunikacích, tedy „Právnické nebo fyzické osoby zajišťující veřejnou komunikační síť nebo poskytující veřejně dostupnou službu elektronických komunikací“, navíc určuje vyhláška č. 357/2012 Sb. (Vyhláška o uchovávání, předávání a likvidaci provozních a lokalizačních údajů) povinnost uchovávání provozních lokalizačních údajů pro provozovatele překladu adres. Podrobněji se před dvěma lety problematice věnoval na Lupě ve svém článku Jiří Peterka. Připomeňme pouze, že problematiku CGN řeší ve zmíněné vyhlášce § 2, odstavec 3, bod f), který říká:
§ 2
Rozsah uchovávání provozních a lokalizačních údajů
(3) U sítí elektronických komunikací s přepojováním paketů se uchovávají tyto údaje
f) u služby přístupu k internetu podle písmene a) nebo b) s překladem adres IP
1. privátní adresa IP,
2. veřejná adresa IP a číslo portu, nebo přidělený rozsah portů,
3. datum a čas zahájení překladu adres,
4. datum a čas ukončení překladu adres.
Jakým způsobem lze těmto požadavkům vyhovět? Jednou z možností je export potřebných informací přímo z CGN. Pro tyto účely se primárně používají protokoly Syslog nebo NetFlow. Který ze způsobu logování použít, záleží typicky na schopnostech CGN zařízení. Protokol Syslog má výhodu ve své jednoduchosti, nicméně ne všechna CGN zařízení umožňují tímto protokolem exportovat všechny potřebné informace (např. alokaci bloku portů, jak si popíšeme dále). V případě protokolu NetFlow byla jeho specifikace firmou Cisco rozšířena o mechanizmus s názvem NSEL (Network Secure Event Logging) nebo NEL (Network Event Logging), který se používá pro export celé řady dalších položek - např. události firewallu nebo právě monitorování CGN. Ostatní výrobci tento koncept víceméně převzali. Pro potřeby zpracování události z CGN jsou relevantní zejména následující položky:
NF_F_XLATE_SRC_ADDR_IPV4 - Post NAT Source IPv4 Address
NF_F_XLATE_DST_ADDR_IPV4 - Post NAT Destination IPv4 Address
NF_F_XLATE_SRC_PORT - Post NAT Source Transport Port
NF_F_XLATE_DST_PORT - Post NAT Destination Transport Port
Jednotlivé položky popisují, na jaké adresy a porty byl proveden vlastní překlad. V položkách bez prefixu
XLATE najdeme IP adresy a porty před překladem.
Je třeba ovšem upozornit, že samotné CGN zařízení typicky nezasílá informace o překladu adres společně se statistickými informacemi. Pokud byste tedy hledali, kolik která IP adresa přenesla bajtů nebo paketů, musíte informace o překladu doplnit dalším exportem statistik a následně všechny tyto informace zkombinovat na kolektoru. Následující obrázek ukazuje, jak vypadá export logovacích informací z Cisco CSR.
Kolektor tato data potom může zobrazit ve formě jednotlivých flow, nicméně pro celkový přehled se tyto informace musí zkombinovat s klasickými daty NetFlow. Příkladem může být následující komunikace:
V tomto případě zařízení s IP
adresou 100.64.10.1 posílalo ICMP Request (ping) na adresu 8.8.8.8. Provoz byl veden přes CGN adresou 147.229.64.10. Vidíme, že CGN exportuje údaje o vytvoření nebo smazání jednotlivých mapování. Statistické údaje o přeneseném počtu bajtů a paketů jsou již nicméně v samostatných záznamech NetFlow (řádky označené jako Event INVALID). Kolektor pak musí udělat případnou post-processing analýzu a data zpracovat do přijatelné podoby.
Strategie přidělování portů
S problematikou logování také úzce souvisí strategie přidělování TCP/UDP portů při překladu na CGN, kterou jsme už nakousli v předchozím díle. U většiny moderních NATů je obecně snaha v paketech pokud možno neměnit zdrojové porty, tj. pokud se v tabulce překladů již nevyskytuje unikátní pětice - protokol, zdrojová adresa (NATu), cílová adresa, zdrojový port a cílový port. Toto ne vždy platí pro CGN, kde se často ignoruje cílová adresa a cílový port, aby se nealokovalo tolik hardwarových prostředků. Pokud je uvedená pětice či trojice už obsazená, zvolí se na CGN jiný volný zdrojový port. To ovšem znamená, že z pohledu logování vzniknou pro každé např. TCP sezení dva záznamy - vytvoření nového záznamu v tabulce překladů a jeho zrušení. Všechny tyto informace je třeba někde skladovat a to u větších instalací může být skutečný problém. Jak jsme si ukázali v předchozím odstavci, na plnohodnotné logování jedné obousměrné komunikace může totiž připadat 4 a více záznamů - tj. začátek/konec překladu a vlastní záznamy o tocích, kterých může být u delších spojení hned několik. Z toho důvodu umožňují některé implementace CGN konfigurovat přidělování a alokaci portů v blocích (Bulk Logging and Port Block Allocation).
Mechanismus ve zjednodušené podobě funguje následovně: V okamžiku vzniku prvního požadavku klienta na vytvoření záznamu v tabulce překladů alokuje CGN ne jeden vhodný port, ale rovnou celý blok - typicky 512 a více portů. Tomuto prvnímu sezení přidělí první port z tohoto bloku a zároveň odešle informaci do logovacího systému o přidělení bloku portů a jeho velikosti. Při vytváření záznamů pro další sezení ze stejné zdrojové IP adresy se použije volný port z dříve přiděleného bloku. Logovací informace se už nikde neodesílá. Tímto dochází ke značné redukci záznamů nutných pro uchovávání. Při nutnosti identifikace uživatele na základě veřejné IP adresy CGN a čísla portu je možné podle bloku portů identifikovat IP adresu použitou uvnitř sítě. Příkladem může být následující obrázek.
Na obrázku vidíme, že provoz CPE zařízení s IP adresou 100.64.10.4 prochází skrz CGN a spojení je přeloženo na adresu 147.229.64.100. Pro zařízení byl alokován blok 512 portů začínající portem 1024. Port step size se využije při výpočtu portu pro další sezení. V našem případě by bylo pro další spojení daného zařízení použit port 1032. Pro toto nové sezení už ale nebude exportována žádná logovací událost (NetFlow záznam). Povšimněte si také, že v rámci exportovaných informací chybí IP adresa a port cíle, protože CGN si tyto informace neukládá a z hlediska blokového přidělování portů ani nedává žádný smysl.
Jakousi odlehčenou variantu výše popsaného mechanismu představuje řešení v podobě deterministického mapování portů popsaného v RFC 7422. Princip je stejný jako v předchozím případě, tj. pro každého klienta v privátní sítí je přidělen blok portů, které se pak použijí pro překlad. Rozdíl je v tom, že rozdělení portů jednotlivých klientů je dáno jednou provždy konfigurací CGN. Tím pádem není potřeba žádného dalšího logování, protože přiřazení portů klientům vyplývá z konfigurace CGN. Je možné, že předdefinovaný rozsah portů nemusí být v některých případech dostatečný. Pokud tato situace nastane, proběhne další, tentokrát už dynamická alokace bloku portů pro příslušného klienta. Tu je ovšem nutno zalogovat, čímž celý mechanismus jaksi ztrácí své původní kouzlo.
A proč ne rovnou IPv6?
Jak jste zřejmě vytušili, implementace CGN není zcela snadný úkol. Vše navíc komplikuje fakt, že se jedná o jakési dočasné řešení, mající překlenout dobu, než bude možné uvažovat o protokolu IPv6 jako o plnohodnotné náhradě IPv4. Z toho důvodu je vhodné při návrhu implementace CGN alespoň zvážit možnou integraci CGN s protokolem IPv6. Důvodů pro to je několik:
- IPv6 je považován za nosný protokol budoucího Internetu a je nesporným faktem, že množství služeb dostupných prostřednictvím protokolu IPv6 každým dnem roste. Dle našich měření je k dnešnímu dni celosvětově protokolem IPv6 dostupných přes 7 % webů. Za Českou republiku toto číslo přesahuje dokonce 20 %. Nezanedbatelným faktem rovněž je, že velké množství nejpopulárnějších a objemově náročných webů se nachází v této skupině.
- Pokud IPv6 funguje správně a protokol je implementován až k zařízení koncového uživatele, může být protokolem IPv6 odbavena nemalá část provozu. To významným způsobem může snížit zátěž na CGN, ať už z hlediska objemu dat, počtu sezení nebo logovacích informací, které je nutné skladovat. Pro tento režim se obecně používá termín IPv6 offload.
- Zařízení umístěná za CGN není možné napřímo adresovat. IPv6 v tomto směru může poskytnout kompenzaci za ztrátu této funkcionality. Na druhou stranu je třeba si uvědomit, že koncová CPE typicky blokují vnější příchozí spojení (RFC 6092), takže plnohodnotná end-to-end konektivita nemusí být aplikacím tak jak tak dostupná. Nicméně tímto krokem lze alespoň přenechat na uživateli, ať si sám rozhodne, zda na svém CPE „otevře“ firewall před okolním světem či nikoliv.
To, že plnohodnotná a kvalitní implementace IPv6 není zrovna procházkou růžovým sadem, jsme psali už dříve na Lupě a zde na Rootu. Pojďme se nicméně podívat, v čem nám může dnes reálně pomoci implementace IPv6, zejména z hlediska snížení zátěže CGN. Níže uvedená data jsme nasbírali v kolejní síti Vysokého učení technického v Brně, kde je IPv6 protokol dostupný ve 100% pokrytí. Z hlediska objemů dat se IPv6 provoz průměrne pohybuje kolem 25 % (červený průběh). Zajímavějším číslem však může být podíl toků (flow), které lze na CGN ušetřit. Zde je číslo o něco menší a pohybuje se kolem 15 % (zelený průběh). Velkou mírou se na této skladbě podílejí služby Google, zejména pak Youtube, které jsou už nějaký ten pátek dostupné po IPv6.
Pro korektnost je však třeba uvést, že uvedená data byla získána v síti, kde je většina uživatelů přímo připojená do přístupové sítě bez využití CPE. V prostředí sítě, kde se uživatelé ve větší míře připojují přes CPE, by tato čísla byla podstatně nižší, zejména díky absenci podpory IPv6 ve většině dnešních CPE.
A nešlo by to přeci jen bez CGN?
V tuto chvíli Vám možná přijde na mysl otázka, zda není přeci jen perspektivnější rovnou do sítě implementovat IPv6 a protokol IPv4 po dočasnou dobu vyřešit některým z přechodových mechanismů. Některé společnosti jako například T-Mobile US nebo polský Orange se skutečně vydaly touto cestou a snaží se ve své mobilní síti CGN pokud možno vypustit. Mobilním zařízením přidělují pouze IPv6 adresu a přístup na IPv4-only služby řeší kombinaci NAT64 + DNS64 a 464XLAT. Tyto technologie byly podrobně popsány již v článku Ondřeje Caletky.
Při použití těchto technologií se prakticky jedná o stejné množství překladů jako v případě CGN, jelikož IPv4 provoz je prvně přeložen z IPv4 do IPv6 (prostřednictvím 464XLAT) a potom zpět z IPv6 do IPv4 (NAT64). Přibývá navíc ještě překlad prostřednictvím DNS64, který má navíc tu nepříjemnou vlastnost, že narušuje DNSSEC. Na celé věci je pozoruhodné, že zatímco v případě CGN je dvojitý překlad chápán jako čisté zlo seslané snad samotným peklem, tak řešení v podobě 464XLAT, NAT64+DNS64 je části IPv6 komunity naopak vnímáno jako elegantní a perspektivní přechodový mechanismus, který má v budoucnu šetřit náklady díky eliminaci IPv4 protokolu z jádra sítě.
Bez ohledu na výhody a nevýhody stěžejním problémem zůstává, že mechanismus 464XLAT není podporován napříč výrobci a operačními systémy. V současné době je nativní implementace k dispozici pouze pro Windows Phone a Android. IOS ani ostatní operační systémy tuto technologii nepodporují a v dohledné době zřejmě ani nebudou, jak před časem informoval v IETF pracovní skupině v6ops David Schinazi, jeden z vývojářů Apple. V případě nemobilní sítě je situace ještě horší. K dispozici jsou pouze proof-of-concept opensource aplikace, ne zrovna v nejlepší kvalitě. Výsledkem je, že kombinaci těchto technologií je možné použít pouze pro klienty na vybraných platformách, protože ostatním klientům připojených do IPv6 only sítě zkrátka nebudou fungovat aplikace jako Skype, WhatsApp nebo Spotify, takže nakonec nějaká forma IPv4 je v síti tak jak tak nutná.
V souvislosti s přechodovými mechanismy využívající IPv6-only jádro sítě nelze také nezmínit technologie DS-Lite a MAP. Obě technologie pojí to, vyžadují podporu na domácích CPE. Nedají se tedy nasadit v mobilní síti nebo v síti, kde jsou uživatelé připojení přímo do přístupových portů. DS-Lite představuje pouhé tunelování IPv4 provozu po IPv6-only síti operátora. Domácí CPE zajistí zapouzdření IPv4 paketů do protokolu IPv6, provoz je poslán přes IPv6 síť operátora, kde je pak na hraničním směrovači vybalen a zaslán do světa s využitím CGN nebo napřímo předán do nativní IPv4 sítě. Technologii DS-Lite začal před časem implementovat německý poskytovatel Unitymedia (Německý ekvivalent UPC Česká republika), ne zrovna bez problémů, jak se lze dočíst ve článcích anebo diskusním fóru podpory.
Technologie MAP může vzdáleně připomínat DS-Lite. Uživatelské CPE zde musí zajistit, aby odchozí IPv4 komunikace měla TCP/UDP porty v rozsahu, který byl uživateli přidělen. Díky tomu, že MAP existuje ve dvou variantách (MAP-E, MAP-T), IPv4 hlavička je po NAT překladu na uživatelském CPE zabalena (encapsulation) nebo přímo přeložena (translation) do IPv6 a zaslána přes IPv6 síť operátora. Takto doputují pakety až k hraničnímu směrovači, který provede jejich další překlad, ale už do nativního IPv4. Díky tomu, že každý uživatel má přidělenou IP adresu a pevně definovaný rozsah portů, hraniční směrovač operátora nepotřebuje udržovat stavovou informaci. Tato stateless vlastnost technologie MAP je i její největší výhodou. Jinak je opět nutné mít vlastní software na koncových CPE. Technologie MAP je primárně navržená a tedy i propagována firmou Cisco. Nemáme zatím informace, že by byla někde použitá v nějaké rozsáhlejší instalaci. Chybí také rozumná implementace v CPE zařízeních. Pro bližší seznámení a porovnání jednotlivých přechodových mechanismů doporučujeme práci, kterou zpracoval Edwin Cordeiro.
Snad poslední možnost, jak se efektivně vyhnout CGN, je získání bloku veřejných IPv4 adres. Byť v době, kde obecně panuje povědomí, že IPv4 adresy už došly a není kde brát, ani tato možnost nemusí být nutně zcela mimo hru. V současné době se poměrně intenzivně rozvíjí trh s IP adresami, takže adresové bloky je možné nakupovat nebo pronajímat. Na stránkách RIPE lze nalézt seznam oficiálních Address Brokerů, kteří se specializují na tento typ obchodování. Dle tvrzení některých zástupců je volných adres údajně dost, zejména díky organizacím, které se jich zavčasu chtějí zbavit, dokud ještě mají nějakou hodnotu. Příkladem z nedávné doby může být prodej realizovaný britskou vládou. Ani zde však není vše zcela bez problémů. Adresové bloky jsou mnohdy neoprávněně propagovány jinými subjekty nebo špatně zařazeny v geolokačních databázích jak prezentoval zástupce jednoho z Address Brokerů na posledním setkání RIPE.
Závěr
V dnešním závěrečném díle jsem si popsali způsob, jak realizovat logování CGN. V řadě zemí, ČR nevyjímaje, je ukládání informací o překladu povinností ISP vyplývajícího ze zákona. Logování je tedy důležitou součásti nasazení CGN. Společně s implementací CGN je určitě na místě zvážit i implementaci IPv6. Samotný protokol IPv6 bohužel v současné době v zásadě neřeší problém nedostatku IPv4 adres a tak je i v tomto případě nutné síť provozovat v režimu dualstack anebo společně s některým z přechodových mechanismů. Společná implementace CGN s IPv6 je ostatně cesta, kterou se před několika lety vydala Telefonica O2.
