Čo nám bránilo mať plnohodnotné IPv4 adresy u virtualizácie?
Pri zavedení nového virtualizačného riešenia Stratus.FI na začiatku tohto roku sme rozšírili možnosť využívať virtualizáciu na všetkých študentov s cieľom, aby si ho mohol vyskúšať každý záujemca a využiť pri tom i viac virtuálov súčasne. Vzhľadom na tento fakt by nebolo využívanie /24 bloku verejných IPv4 adries, ktorý máme vyhradené pre virtualizáciu, dostačujúce a ani potrebné, takže sme začali štandardným virtuálom prideľovať adresy z privátneho rozsahu 172.26.0.0/16. (U IPv6 tento problém nevzniká, keďže vyhradený blok verejných adries 2001:718:801:21a::/64 je fenomenálne veľký.)
Privátne adresy však samozrejme nie je možné používať pre plnohodnotnú komunikáciu s internetom bez technológie ako je NAT. Komunikácia týchto strojov bola možná len v rámci fakultnej siete (aisa, anxur, ftp.linux.cz, gitlab, ...). Dôvodom, prečo sme už pri uvedení virtualizácie NAT nenasadili, bola potreba byť schopný v prípade bezpečnostného problému, ktoré dostávame nahlasované od externých subjektov, spätne dohľadať konkrétny stroj spôsobujúci problém. To je však pri skrývaní mnohých strojov za jednu či niekoľko IP adries veľmi ťažko realizovateľné a samotný NAT, ktorý by sme nasadili na náš linuxový router, informácie o mapovaní privátnych adries/portov na verejné adresy/porty automaticky nesprístupňuje.
HTTP proxy a prechod na NAT s monitoringom
Ako náhradné riešenie (okrem plne funkčného IPv6) sme ponúkali možnosť využiť fakultnú HTTP proxy cache zachovávajúcu záznamy o klientoch, ktorí ju používajú. Využitie proxy servera je vo väčšine programov možné nastaviť, ale pridávalo to netriviálnu konfiguračnú prácu zoslabujúcu našu ideu "na pár kliknutí vytvoriť bežiaci virtuál s plnohodnotnou sieťou" a v niektorých prípadoch to nebolo použiteľné vôbec.
V posledných dňoch sme preto dokončili prípravu monitoringu, ktorý umožňuje priebežne ukladať informácie o mapovaní adries a portov v NATe, takže tým odpadla prekážka proti jeho nasadeniu a od dnešného dňa je možné bez špeciálnych úprav pristupovať z virtuálov do internetu ako po IPv4 tak po IPv6.
Pokiaľ na niektorých miestach vo virtualizácii naše HTTP proxy využívate, nemusíte na tom nič meniť. Konfiguráciu na nami predpripravených šablón virtuálov postupne upravíme, aby zbytočne proxy nevyužívali.
Technické riešenie
Konfigurácia NATu vo firewalle
Samotný NAT je realizovaný pomerne jednoducho pomocou iptables firewallu na našom linuxovom routeri (zopár informácií o ňom môžete nájsť v staršom blogovom príspevku) prekladom na jednu verejnú IPv4 adresu stratus-nat503.fi.muni.cz (147.251.58.11), kde relevantné pravidlá zodpovedajú nasledovným:
# paketom prichadzajucim z VLANu virtualizacie nastavime znacku (6. najmenej vyznamny bit)
-A FORWARD -i vlan503 -j MARK --set-mark 0x0020
# pred odchodom paketov z routera, ktore su oznacene, maju spravnu IPv4 adresu a smeruju mimo siet FI, nastavime source NAT, t.j. prepisovanie zdrojovej adresy
-A POSTROUTING -s 172.26.0.0/16 -m mark --mark 0x0020/0x0020 -o uplink -j SNAT --to-source 147.251.58.11
# nakoniec nastavime, aby z internetu prichadzajuca komunikacia na adresu zvolenu pre NAT sla na samotny router (okrem ineho umozni, aby adresa odpovedala na ping)
-A PREROUTING ! -i vlan58 -d 147.251.58.11 -j REDIRECT
Monitoring NATu — logovanie firewallu?
Od monitoringu NATu očakávame, že budeme vedieť zistiť, ktorá privátna adresa zodpovedá komunikácii adresy 147.251.58.11 a nejakého portu v konkrétnom čase. Následne sme schopní dohľadať konkrétny stroj a jeho vlastníka pomocou údajov z virtualizačného rozhrania Stratusu. To znamená, že musíme mať informácie o začiatku a konci všetkých spojení vrátane mapovaní portov.
Zvažovali sme logovanie NATovaných spojení firewallom, ktoré by bolo veľmi jednoduché pomocou jedného iptables pravidla s cieľom LOG a informácie o pakete by sa ukladali vo formáte obdobnom nasledujúcemu:
May 30 15:36:48 ares1 kernel: NAT-logging IN=vlan503 OUT=uplink MAC=00:0c:fc:00:f9:55:02:f1:01:f7:01:ac:08:00 SRC=172.26.2.172 DST=194.160.223.146
LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=57852 DF PROTO=TCP SPT=57026 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0 MARK=0x2
Toto riešenie má však problém, že neposkytuje informácie o mapovaní adries. Navyše logovanie firewallu je vždy vyvolané paketom, takže by sme síce mohli mať informáciu o začiatku spojenia, ale netriviálne by sa už zisťovala informácie o tom, kedy bolo spojenie ukončené.
Monitoring NATu — conntrack!
Preto sme využili možnosť už prítomného connection trackingu, ktorý umožňuje získavať potrebné informácie cez jadrové rozhranie Netfilter pomocou nástroja conntrack. Toto rozhranie už využívane pre synchronizáciu informácií o ustavených spojeniach pre prípad, že by došlo k výpadku aktívneho routera a jeho úlohu musel prevziať záložný router. V takej situácii je vďaka démonovi conntrackd na oboch routeroch tabuľka spojení online synchronizovaná a prípadne prehodenie prevádzky nie je v tomto smere postrehnuteľné.
Prehľad prebiehajúcich zmien v spojeniach je možné sledovať takýmto príkazom:
conntrack --event --src-nat --buffer-size 400000 -o id,timestamp
Špecificky si vyberieme sledovanie len spojení so source NATom, doplníme výstup o časové známky a interné identifikátory spojení. Počas testovania tohto riešenia sme narazili na problém s veľkosťou buffera pre udalosti z Netlinku, ktorý bol pre množstvo spojení, ktoré naším firewallom prechádza, príliš malý a často dochádzalo k ukončeniu conntracku s chybou WARNING: We have hit ENOBUFS! We are losing events. Sakra, čo teraz?!!?! Pokúsili sme sa to obmedziť zvýšením jeho veľkosť na štvornásobok pôvodnej hodnoty. Toto opatrenie ale iba znižuje frekvenciu výskytu týchto problémov, takže sme tento conntrack príkaz umiestnili do nekonečnej slučky, aby bol automaticky reštartovaný a bolo zaistené plynulé získavanie záznamov s minimálnym výpadkom do jednej sekundy.
Takto sme z conntracku sme schopní získať informácie už v dostačujúcom rozsahu. Dáta o životnom cykle jedného spojenia tak vyzerajú nasledovne:
[1496232483.935720] [NEW] tcp 6 120 SYN_SENT src=172.26.2.207 dst=94.75.223.121 sport=60688 dport=80 [UNREPLIED] src=94.75.223.121 dst=147.251.58.11 sport=80 dport=60688 id=1686242808
[1496232483.953208] [UPDATE] tcp 6 60 SYN_RECV src=172.26.2.207 dst=94.75.223.121 sport=60688 dport=80 src=94.75.223.121 dst=147.251.58.11 sport=80 dport=60688 id=1686242808
[1496232483.953408] [UPDATE] tcp 6 432000 ESTABLISHED src=172.26.2.207 dst=94.75.223.121 sport=60688 dport=80 src=94.75.223.121 dst=147.251.58.11 sport=80 dport=60688 [ASSURED] id=1686242808
[1496232483.953450] [UPDATE] tcp 6 250 FIN_WAIT src=172.26.2.207 dst=94.75.223.121 sport=60688 dport=80 src=94.75.223.121 dst=147.251.58.11 sport=80 dport=60688 [ASSURED] id=1686242808
[1496232483.970927] [UPDATE] tcp 6 120 LAST_ACK src=172.26.2.207 dst=94.75.223.121 sport=60688 dport=80 src=94.75.223.121 dst=147.251.58.11 sport=80 dport=60688 [ASSURED] id=1686242808
[1496232483.971071] [UPDATE] tcp 6 120 TIME_WAIT src=172.26.2.207 dst=94.75.223.121 sport=60688 dport=80 src=94.75.223.121 dst=147.251.58.11 sport=80 dport=60688 [ASSURED] id=1686242808
[1496232603.971567] [DESTROY] tcp 6 src=172.26.2.207 dst=94.75.223.121 sport=60688 dport=80 src=94.75.223.121 dst=147.251.58.11 sport=80 dport=60688 [ASSURED] id=1686242808
Riadok vždy obsahuje za unixovým timestampom informáciu o stave spojenia, adresy+porty videné lokálnou (našou) stranou spojenia a adresy+porty videné za hranicou našej siete z opačnej strany.
Záver
Réžia tohto riešenia je pomerne malá. Na našom primárnom routeri s dvomi CPU Intel Xeon E5-2650 využíva proces conntrack 10 % jedného jadra z celkovo 16 jadier na stroji, pričom conntrack generuje priemerne 4000 udalostí za sekundu, z toho 1000 udalostí je o novom ustavení spojenia. Pre predstavu ešte doplníme, že naším routerom prechádza počas bežnej prevádzky typicky 100 tisíc spojení v jednom momente, ako vidieť na grafe nižšie (oranžová plocha zodpovedá spojeniam, kde došlo ku komunikácii z oboch strán (ASSURED) a červený graf všetkým spojeniam):
Tak. Tento príspevok má veľmi dobrú šancu zapísať sa do nášho blogu ako zatiaľ najdlhší, ale na druhú stranu dúfame, že tým poodhalíme fungovanie našej infraštruktúry, použitých riešení a cesty k nim. :-)
