Wéi IPv4 Adressen ofgeschaaft ginn, sinn vill Telekomoperateuren konfrontéiert mat der Bedierfnes fir hire Clienten Netzzougang mat Adressiwwersetzung ze bidden. An dësem Artikel wäert ech Iech soen wéi Dir Carrier Grade NAT Leeschtung op Commodity Server kritt.
E bësse vun der Geschicht
D'Thema vun der IPv4 Adressraumausschöpfung ass net méi nei. Irgendwann sinn d'Waardelëschten am RIPE opgetaucht, dunn sinn Austausch entstanen op deenen d'Blocke vun Adressen gehandelt goufen an Deals ofgeschloss goufen fir se ze lounen. Lues a lues hunn d'Telekomoperateuren ugefaang Internetzougangservicer mat Adress- a Port Iwwersetzung ze bidden. E puer hunn et net fäerdeg bruecht genuch Adressen ze kréien fir eng "wäiss" Adress un all Abonnent auszeginn, anerer hunn ugefaang Suen ze spueren andeems se refuséiert Adressen um Secondaire Maart ze kafen. Hiersteller vun Reseau Equipement ënnerstëtzt dës Iddi, well dës Funktionalitéit verlaangt normalerweis zousätzlech Extensioun Moduler oder Lizenzen. Zum Beispill, an Juniper Linn vun MX routers (ausser fir déi neisten MX104 an MX204), Dir kënnt NAPT op eng separat MS-MIC Service Kaart Leeschtung, Cisco ASR1k verlaangt CGN Lizenz, Cisco ASR9k verlaangt eng separat A9K-ISM-100 Modul an eng A9K-CGN Lizenz -LIC him. Am Allgemengen kascht de Genoss vill Suen.
IPTables
D'Aufgab fir NAT auszeféieren erfuerdert keng spezialiséiert Rechenressourcen; et kann duerch allgemeng Zweck Prozessoren geléist ginn, déi zum Beispill an all Heemrouter installéiert sinn. Op der Skala vun engem Telekomoperateur kann dëse Problem mat Hëllef vu Commodity-Server geléist ginn, déi FreeBSD (ipfw/pf) oder GNU/Linux (iptables) lafen. Mir wäerten FreeBSD net berücksichtegen, well ... Ech hunn d'Benotzung vun dësem OS viru laanger Zäit opgehalen, sou datt mir op GNU/Linux bleiwen.
D'Adress Iwwersetzung aktivéieren ass guer net schwéier. Als éischt musst Dir eng Regel an iptables an der nat Tabell registréieren:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent
De Betribssystem lued de Modul nf_conntrack, deen all aktiv Verbindungen iwwerwaacht an déi néideg Konversioune mécht. Et gi verschidde Subtletien hei. Als éischt, well mir iwwer NAT op der Skala vun engem Telekomoperateur schwätzen, ass et néideg d'Timeouts unzepassen, well mat Standardwäerter wäert d'Gréisst vum Iwwersetzungstabell séier op katastrophal Wäerter wuessen. Drënner ass e Beispill vun den Astellungen déi ech op meng Server benotzt hunn:
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
An zweetens, well d'Standardgréisst vun der Iwwersetzungstabell net entwéckelt ass fir ënner de Bedéngungen vun engem Telekomoperateur ze schaffen, muss se erhéicht ginn:
net.netfilter.nf_conntrack_max = 3145728
Et ass och noutwendeg fir d'Zuel vun den Eemer fir den Hash-Tabelle ze erhéijen, deen all Sendungen späichert (dëst ass eng Optioun am nf_conntrack Modul):
options nf_conntrack hashsize=1572864
No dësen einfache Manipulatioune gëtt e komplett funktionnéierenden Design kritt deen eng grouss Zuel vu Clientadressen an e Pool vun externen iwwersetzt. Wéi och ëmmer, d'Leeschtung vun dëser Léisung léisst vill ze wënschen. A mengen éischte Versuche fir GNU / Linux fir NAT ze benotzen (circa 2013), konnt ech Leeschtung vu ronn 7Gbit / s bei 0.8Mpps pro Server (Xeon E5-1650v2) kréien. Zënter där Zäit sinn vill verschidden Optimisatiounen am GNU / Linux Kernel Netzwierkstack gemaach ginn, d'Performance vun engem Server op der selwechter Hardware ass op bal 18-19 Gbit / s bei 1.8-1.9 Mpps eropgaang (dëst waren déi maximal Wäerter) , awer d'Demande fir de Verkéiersvolumen, veraarbecht vun engem Server ass vill méi séier gewuess. Als Resultat goufen Schemaen entwéckelt fir d'Laascht op verschiddene Serveren ze balanséieren, awer all dëst huet d'Komplexitéit vun der Ariichten, Erhalen an Erhalen vun der Qualitéit vun de geliwwerte Servicer erhéicht.
NTFables
Hautdesdaags ass e fashionable Trend a Software "Shifting Bags" d'Benotzung vun DPDK an XDP. Vill Artikelen goufen iwwer dëst Thema geschriwwen, vill verschidde Rieden goufen gemaach, a kommerziell Produkter sinn erschéngen (Zum Beispill SKAT aus VasExperts). Awer mat de limitéierte Programméierungsressourcen vun Telekomoperateuren ass et zimmlech problematesch all "Produkt" op Basis vun dëse Kaderen eleng ze kreéieren. Et wäert vill méi schwéier ginn esou eng Léisung an Zukunft ze bedreiwen, virun allem Diagnostice Tools mussen entwéckelt ginn. Zum Beispill, Standard tcpdump mat DPDK funktionnéiert net esou, an et wäert net "gesinn" Päckchen, déi zréck op d'Drähten mat XDP geschéckt ginn. Am Zesummenhang mat all de Gespréicher iwwer nei Technologien fir d'Output vu Package Forwarding op de Benotzerraum, si si onnotéiert и Pablo Neira Ayuso, iptables Ënnerhalter, iwwer d'Entwécklung vu Flow Offloading an nftables. Loosst eis dëse Mechanismus méi no kucken.
D'Haaptidee ass datt wann de Router Pakete vun enger Sessioun a béid Richtunge vum Flux passéiert (TCP Sessioun ass an den ESTABLISHED Staat gaang), da brauch et net weider Pakete vun dëser Sessioun duerch all Firewall Regelen ze passéieren, well all dës Schecken wäerten ëmmer nach ophalen mam Paket, dee weider op de Routing transferéiert gëtt. A mir brauchen net tatsächlech e Wee ze wielen - mir wësse schonn op wéi eng Interface a wéi en Host mir Pakete bannent dëser Sessioun schécken. Alles wat bleift ass dës Informatioun ze späicheren an se fir Routing an enger fréicher Stuf vun der Paketveraarbechtung ze benotzen. Wann Dir NAT ausféiert, ass et néideg zousätzlech Informatiounen iwwer Ännerungen an Adressen an Häfen ze späicheren, déi vum nf_conntrack Modul iwwersat ginn. Jo, natierlech, an dësem Fall verschidde Polizisten an aner Informatiouns- a statistesch Regelen an iptables stoppen ze schaffen, awer am Kader vun der Aufgab vun enger separater Stand NAT oder, zum Beispill, enger Grenz, ass dat net sou wichteg, well d'Servicer sinn iwwer Apparater verdeelt.
Configuratioun
Fir dës Funktioun ze benotzen brauche mir:
- Benotzt e frësche Kär. Trotz der Tatsaach, datt d'Funktionalitéit selwer am Kernel 4.16 erschéngt, war et fir eng laang Zäit ganz "raw" an huet regelméisseg Kernel Panik verursaacht. Alles stabiliséiert ronderëm Dezember 2019, wéi LTS Kernel 4.19.90 a 5.4.5 verëffentlecht goufen.
- Rewrite iptables Regelen am nftables Format mat enger zimlech rezenter Versioun vun nftables. Wierker genau an der Versioun 0.9.0
Wann alles am Prinzip kloer mam éischte Punkt ass, ass den Haapt Saach net ze vergiessen de Modul an der Konfiguratioun während der Montage opzehuelen (CONFIG_NFT_FLOW_OFFLOAD=m), da erfuerdert den zweete Punkt Erklärung. nftables Regele ginn komplett anescht beschriwwe wéi an iptables. verréid bal all Punkten, et sinn och speziell Regele vun iptables zu nftables. Dofir wäert ech nëmmen e Beispill ginn fir NAT opzemaachen a Flow Offload. Eng kleng Legend zum Beispill: , - dëst sinn d'Netzschnëttplazen duerch déi de Verkéier passéiert; an der Realitéit kënne et méi wéi zwee vun hinnen sinn. , - d'Start- an Ennadress vun der Gamme vu "wäiss" Adressen.
NAT Konfiguratioun ass ganz einfach:
#! /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
}
}
Mat Flow Offload ass et e bësse méi komplizéiert, awer ganz verständlech:
#! /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;
}
}
Dat ass tatsächlech de ganze Setup. Elo fällt all TCP / UDP Traffic an de Fastnat Dësch a gëtt vill méi séier veraarbecht.
Resultater
Fir et kloer ze maachen wéi "vill méi séier" dëst ass, befestegt ech e Screenshot vun der Belaaschtung op zwee real Serveren, mat der selwechter Hardware (Xeon E5-1650v2), identesch konfiguréiert, mam selwechten Linux Kernel, awer NAT an iptables. (NAT4) an an nftables (NAT5).
Et gëtt keng Grafik vu Pakete pro Sekonn am Screenshot, awer am Laaschtprofil vun dëse Serveren ass déi duerchschnëttlech Paketgréisst ongeféier 800 Bytes, sou datt d'Wäerter bis zu 1.5Mpps erreechen. Wéi Dir kënnt gesinn, huet de Server mat nftables eng rieseg Leeschtungsreserve. De Moment veraarbecht dëse Server bis zu 30Gbit / s bei 3Mpps an ass kloer fäeg déi kierperlech Netzwierklimitatioun vu 40Gbps z'erreechen, wärend gratis CPU Ressourcen.
Ech hoffen dat Material wäert nëtzlech sinn fir Netzwierkingenieuren déi probéieren d'Performance vun hire Serveren ze verbesseren.
Source: will.com