Keďže adresy IPv4 sa vyčerpávajú, mnohí telekomunikační operátori čelia potrebe poskytnúť svojim klientom prístup k sieti pomocou prekladu adries. V tomto článku vám poviem, ako môžete získať výkon Carrier Grade NAT na komoditných serveroch.
Trocha histórie
Téma vyčerpania adresného priestoru IPv4 už nie je nová. V určitom okamihu sa v RIPE objavili čakacie listiny, potom sa objavili burzy, na ktorých sa obchodovalo s blokmi adries a uzatvárali sa obchody na ich prenájom. Postupne začali telekomunikační operátori poskytovať služby prístupu na internet pomocou prekladu adries a portov. Niektorým sa nepodarilo získať dostatok adries na vydanie „bielej“ adresy každému účastníkovi, zatiaľ čo iní začali šetriť peniaze tým, že odmietli nakupovať adresy na sekundárnom trhu. Výrobcovia sieťových zariadení podporili túto myšlienku, pretože táto funkcia zvyčajne vyžaduje dodatočné rozširujúce moduly alebo licencie. Napríklad v rade MX routerov Juniper (okrem najnovších MX104 a MX204) môžete vykonávať NAPT na samostatnej servisnej karte MS-MIC, Cisco ASR1k vyžaduje licenciu CGN, Cisco ASR9k vyžaduje samostatný modul A9K-ISM-100 a licenciu A9K-CGN -LIC k nemu. Vo všeobecnosti potešenie stojí veľa peňazí.
iptables
Úloha vykonávania NAT si nevyžaduje špecializované výpočtové zdroje, dá sa vyriešiť univerzálnymi procesormi, ktoré sú nainštalované napríklad v akomkoľvek domácom routeri. Na úrovni telekomunikačného operátora je možné tento problém vyriešiť pomocou komoditných serverov so systémom FreeBSD (ipfw/pf) alebo GNU/Linux (iptables). O FreeBSD nebudeme uvažovať, pretože... Tento OS som prestal používať už pomerne dávno, takže zostaneme pri GNU/Linuxe.
Povoliť preklad adries nie je vôbec ťažké. Najprv musíte zaregistrovať pravidlo v iptables v tabuľke nat:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent
Operačný systém načíta modul nf_conntrack, ktorý bude sledovať všetky aktívne pripojenia a vykonávať potrebné konverzie. Je tu niekoľko jemností. Po prvé, keďže hovoríme o NAT na stupnici telekomunikačného operátora, je potrebné upraviť časové limity, pretože s predvolenými hodnotami veľkosť prekladovej tabuľky rýchlo narastie do katastrofálnych hodnôt. Nižšie je uvedený príklad nastavení, ktoré som použil na svojich serveroch:
net.ipv4.ip_forward = 1
net.ipv4.ip_local_port_range = 8192 65535
net.netfilter.nf_conntrack_generic_timeout = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 45
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_checksum=0
A po druhé, keďže predvolená veľkosť prekladovej tabuľky nie je navrhnutá tak, aby fungovala v podmienkach telekomunikačného operátora, je potrebné ju zvýšiť:
net.netfilter.nf_conntrack_max = 3145728
Taktiež je potrebné zvýšiť počet bucketov pre hašovaciu tabuľku, v ktorej sú uložené všetky vysielania (toto je možnosť v module nf_conntrack):
options nf_conntrack hashsize=1572864
Po týchto jednoduchých manipuláciách sa získa úplne funkčný dizajn, ktorý dokáže preložiť veľké množstvo klientskych adries do skupiny externých. Výkon tohto riešenia však ponecháva veľa požiadaviek. Pri mojich prvých pokusoch o použitie GNU/Linux pre NAT (približne 2013) som bol schopný dosiahnuť výkon okolo 7 Gbit/s pri 0.8 Mpps na server (Xeon E5-1650v2). Odvtedy sa v sieťovom zásobníku jadra GNU/Linux vykonalo mnoho rôznych optimalizácií, výkon jedného servera na rovnakom hardvéri sa zvýšil na takmer 18-19 Gbit/s pri 1.8-1.9 Mpps (to boli maximálne hodnoty) , ale dopyt po objeme prevádzky spracovanej jedným serverom rástol oveľa rýchlejšie. V dôsledku toho boli vyvinuté schémy na vyváženie zaťaženia rôznych serverov, ale to všetko zvýšilo zložitosť nastavenia, udržiavania a udržiavania kvality poskytovaných služieb.
Tabuľky NFT
V súčasnosti je módnym trendom v softvérových „prehadzovacích taškách“ používanie DPDK a XDP. Na túto tému bolo napísaných veľa článkov, odznelo veľa rôznych prejavov a objavujú sa komerčné produkty (napríklad SKAT od VasExperts). Ale vzhľadom na obmedzené programovacie zdroje telekomunikačných operátorov je dosť problematické vytvoriť svojpomocne akýkoľvek „produkt“ založený na týchto rámcoch. V budúcnosti bude prevádzka takéhoto riešenia oveľa náročnejšia, bude potrebné vyvinúť najmä diagnostické nástroje. Napríklad štandardný tcpdump s DPDK nebude fungovať len tak a „nevidí“ pakety odoslané späť do káblov pomocou XDP. Uprostred všetkých tých rečí o nových technológiách na odosielanie preposielania paketov do užívateľského priestoru zostali nepovšimnuté и Pablo Neira Ayuso, správca iptables, o vývoji vykladania toku v nftables. Pozrime sa na tento mechanizmus bližšie.
Hlavnou myšlienkou je, že ak smerovač odovzdal pakety z jednej relácie v oboch smeroch toku (relácia TCP prešla do stavu ESTABLISHED), potom nie je potrebné prechádzať ďalšie pakety tejto relácie cez všetky pravidlá brány firewall, pretože všetky tieto kontroly sa aj tak skončia prenosom paketu ďalej do smerovania. A v skutočnosti nemusíme vyberať trasu – už vieme, na ktoré rozhranie a na ktorý hostiteľ musíme posielať pakety v rámci tejto relácie. Zostáva len uložiť tieto informácie a použiť ich na smerovanie v ranom štádiu spracovania paketov. Pri vykonávaní NAT je potrebné dodatočne uchovávať informácie o zmenách adries a portov preložených modulom nf_conntrack. Áno, samozrejme, v tomto prípade prestávajú fungovať rôzni policajti a iné informačné a štatistické pravidlá v iptables, ale v rámci úlohy samostatného stojaceho NAT alebo napríklad hranice to nie je až také dôležité, lebo služby sú distribuované medzi zariadeniami.
konfigurácia
Na použitie tejto funkcie potrebujeme:
- Použite čerstvé jadro. Napriek tomu, že samotná funkcionalita sa objavila v jadre 4.16, pomerne dlho bola veľmi „surová“ a pravidelne spôsobovala v jadre paniku. Všetko sa stabilizovalo okolo decembra 2019, kedy boli vydané jadrá LTS 4.19.90 a 5.4.5.
- Prepíšte pravidlá iptables vo formáte nftables pomocou pomerne najnovšej verzie nftables. Funguje presne vo verzii 0.9.0
Ak je s prvým bodom v princípe všetko jasné, hlavné je nezabudnúť pri montáži zaradiť modul do konfigurácie (CONFIG_NFT_FLOW_OFFLOAD=m), tak druhý bod si vyžaduje vysvetlenie. pravidlá nftables sú popísané úplne inak ako v iptables. odhalí takmer všetky body, existujú aj špeciálne pravidlá od iptables po nftables. Preto uvediem len príklad nastavenia NAT a flow offload. Napríklad malá legenda: , - sú to sieťové rozhrania, cez ktoré prechádza prevádzka, v skutočnosti ich môže byť viac ako dve. , — počiatočná a koncová adresa rozsahu „bielych“ adries.
Konfigurácia NAT je veľmi jednoduchá:
#! /usr/sbin/nft -f
table nat {
chain postrouting {
type nat hook postrouting priority 100;
oif <o_if> snat to <pool_addr_start>-<pool_addr_end> persistent
}
}
S vyložením toku je to trochu komplikovanejšie, ale celkom pochopiteľné:
#! /usr/sbin/nft -f
table inet filter {
flowtable fastnat {
hook ingress priority 0
devices = { <i_if>, <o_if> }
}
chain forward {
type filter hook forward priority 0; policy accept;
ip protocol { tcp , udp } flow offload @fastnat;
}
}
To je vlastne celé nastavenie. Teraz bude všetka prevádzka TCP/UDP spadať do tabuľky fastnat a bude spracovaná oveľa rýchlejšie.
výsledky
Aby bolo jasné, ako je to „oveľa rýchlejšie“, pripojím snímku obrazovky zaťaženia dvoch skutočných serverov s rovnakým hardvérom (Xeon E5-1650v2), identicky nakonfigurovaným, používajúc rovnaké jadro Linuxu, ale vykonávajúce NAT v iptables (NAT4) a v nftables (NAT5).
Na snímke obrazovky nie je žiadny graf paketov za sekundu, ale v profile zaťaženia týchto serverov je priemerná veľkosť paketu okolo 800 bajtov, takže hodnoty dosahujú až 1.5 Mpps. Ako vidíte, server s nftables má obrovskú výkonnostnú rezervu. V súčasnosti tento server spracováva až 30 Gbit/s rýchlosťou 3 Mpps a je jednoznačne schopný splniť obmedzenie fyzickej siete 40 Gbps, pričom má voľné zdroje CPU.
Dúfam, že tento materiál bude užitočný pre sieťových inžinierov, ktorí sa snažia zlepšiť výkon svojich serverov.
Zdroj: hab.com