🥇Kiire rooteerimine ja NAT Linuxis

IPv4 aadresside ammendumise tõttu seisavad paljud telekommunikatsiooniettevõtted silmitsi vajadusega korraldada oma klientide juurdepääs võrku aadresside tõlke abil. Selles artiklis räägin, kuidas saavutada Carrier Grade NAT tasemel jõudlus kommoditeediserveritel.

Enne kui liigume edasi

IPv4 aadressiruumide ammendumise teema ei ole enam uus. Teatud hetkel tekkisid RIPE'is ooteread (waiting list), seejärel ilmusid börsid, kus kaupleti aadressiblokke ning sõlmiti lepingud nende rentimiseks. Aja jooksul hakkasid telekommunikatsiooniettevõtted pakkuma interneti juurdepääsu aadresside ja portide tõlke abil. Mõned ei saanud piisavalt aadresse, et anda igale tellijale 'valget' aadressi, teised alustasid säästmist, loobudes aadresside ostmisest sekundaarsetelt turgudelt. Võrguseadmete tootjad toetasid seda ideed, kuna see funktsioon nõuab tavaliselt täiendavaid laiendusi või litsentse. Näiteks Juniperi MX marsruuteri seerias (välja arvatud viimased MX104 ja MX204) saab NAPT-i teostada eraldi teenusekaardil MS-MIC, Cisco ASR1k puhul on vajalik CGN litsents, Cisco ASR9k puhul on vajalik eraldi A9K-ISM-100 moodul ja litsents A9K-CGN-LIC selle jaoks. Üldiselt ei ole see odav lõbu.

IPTables

NAT-i teostamise ülesanne ei nõua spetsialiseeritud arvutivõimsust, see on suuteline lahendama tavalised protsessorid, mis on installitud näiteks igas koduses ruuteris. Telekommunikatsiooniettevõtte mastaabis saab selle ülesande lahendada, kasutades kommertservereid FreeBSD (ipfw/pf) või GNU/Linux (iptables) operatsioonisüsteemidega. FreeBSD-d ei käsitle, kuna ma olen juba pikka aega loobunud selle OS-i kasutamisest, seega peatume GNU/Linuxi peal.

Aadresside tõlke lubamine ei ole sugugi keeruline. Alustamiseks tuleb kirjutada reegel iptables'i nat tabelisse:

iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to - --persistent

Operatsioonisüsteem laadib sisse nf_conntrack mooduli, mis jälgib kõiki aktiivseid ühendusi ja teostab vajalikud muudatused. Siin on mõned nüansid. Esiteks, kuna tegemist on operaatori NAT-iga, tuleb ajutisi seadistusi kohandada, sest vaikeseaded võivad tabeli suuruse kiiresti katastroofiliseks muuta. Allpool on näide seadistustest, mida kasutasin oma serverites:

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

Ja teiseks, kuna vaikimisi tabeli suurus ei ole kohandatud operaatoritingimustele, tuleb seda suurendada:

net.netfilter.nf_conntrack_max = 3145728

Samuti tuleb suurendada ka päiste arvu hash-tabelis, mis sisaldab kõiki muundamisi (see on nf_conntrack mooduli valik):

options nf_conntrack hashsize=1572864

Pärast neid lihtsaid toiminguid tekib täiesti töökorras lahendus, mis suudab edastada suurt hulka klientide aadresse väliste aadresside kogusse. Siiski, selle lahenduse jõudlus jääb soovitust madalamaks. Oma esimestel katsetel kasutada GNU/Linuxi NAT-ina (umbes aastal 2013) sain ühe serveri (Xeon E5-1650v2) korral jõudluse umbes 7Gbit/s ja 0.8Mpps. Sellest ajast on GNU/Linuxi südamiku võrgustiku sisene tehtud palju erinevaid optimeerimisi, ühe serveri jõudlus samal riistvaral on tõusnud praktiliselt 18-19 Gbit/s ja 1.8-1.9 Mpps (need olid piiri väärtused), kuid ühe serveri käideldava liikluse maht on kasvanud palju kiiremini. Lõpuks on välja töötatud koormuse tasakaalustamise skeemid erinevate serverite vahel, kuid see kõik on suurendanud seadistamise, hooldamise ja teenuse kvaliteedi säilitamise keerukust.

NFTables

Praegu on moes programmide "pakettide ümberpanemise" suund DPDK ja XDP kasutamine. Sellel teemal on kirjutatud hulgaliselt artikleid, toimunud on palju erinevaid ettekandeid ja turule on ilmunud kaubanduslikke tooteid (näiteks SCAT firmalt VasExperts). Kuid piiratud inimressurssidega programmeerijatel on keeruline ise midagi sarnast nende raamistike baasil kokku panna. Sellise lahenduse kasutamine hiljem osutub palju keerulisemaks, sealhulgas tuleb välja töötada diagnostikavahendid. Näiteks tavapärane tcpdump DPDK-ga lihtsalt ei tööta, samuti ei "näe" ta pakette, mis saadetakse tagasi juhtmetesse XDP abil. Uute tehnoloogiate, mis edastavad pakette user-space'is, rääkimise taustal on tähelepanuta jäänud ettekanded ja artikleid Pablo Neira Ayuso, iptables'i hooldaja, rääkis flow offloading'i arendamisest nftables'is. Vaadakem seda mehhanismi lähemalt.

Peamine idee seisneb selles, et kui ruuter on lasknud sama sessiooni pakette mõlemas suunas voos (TCP sessioon on läinud ESTABLISHED olekusse), siis ei ole tarvis edasisi selle sessiooni pakette läbi kõigi tulemüürireeglite lasta, kuna kõik need kontrollid lõppevad igal juhul paketi edastamisega edasise suunamise juurde. Ja valiku tegemine marsruudi suhtes pole samuti vajalik — me teame juba, milliseks liideseks ja millisele hostile tuleb paketid selle sessiooni piires edastada. Jääb vaid see teave salvestada ja kasutada seda paketi varajases töötlemise etapis marsruudiks. NAT'i täitmisel on vajalik ka salvestada teave aadresside ja sadamate muudatuste kohta, mida transformaator nf_conntrack on teinud. Jah, muidugi, sel juhul lõpetavad töö mitmesugused poliitikavahendajad ja muud teabe-statistilised reeglid iptables'is, kuid eraldi NAT'i või näiteks piiriülese ülesande kontekstis ei ole see sugugi nii oluline, kuna teenused on jaotatud seadmete vahel.

Konfiguratsioon

Selle funktsiooni kasutamiseks peame:

Kasutama värsket kernelit. Kuigi see funktsioon ilmus juba kernelis 4.16, oli see üsna kaua väga "toores" ja põhjustas regulaarselt kernel panic'e. Kõik stabiliseerus umbes detsembris 2019, kui ilmusid LTS kernelid 4.19.90 ja 5.4.5.
Kirjutage iptables reeglid ümber nftables formaati, kasutades piisavalt värsket nftables versiooni. Töötab täpselt versioonis 0.9.0

Kui esimese punktiga on põhimõtteliselt selge, et peamine on unustada mitte lubada moodulit konfigureerimises (CONFIG_NFT_FLOW_OFFLOAD=m), siis teine punkt vajab selgitusi. Nftables reeglid on kirjeldatud täiesti teisiti kui iptables. Dokumentatsioon katab praktiliselt kõik aspektid, samuti on olemas spetsiaalsed konverterid reeglitest iptables-st nftables-sse. Seetõttu toon välja ainult NAT-i ja flow offloadi seadistuse näite. Väike legend näite jaoks: , — need on võrgu liidesed, mille kaudu läbib liiklus, neid võib olla tegelikult rohkem kui kaks. , — valgete aadresside vahemiku alg- ja lõpuaadress.

NAT konfiguratsioon on väga lihtne:

#! /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
        }
}

Flow offloadiga on veidi keerulisem, kuid täiesti arusaadav:

#! /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;
        }
}

Sedasi ongi kogu seadistus. Nüüd jõuab kogu TCP/UDP liiklus fastnat tabelisse ja seda töödeldakse palju kiiremini.

tulemused näitasid ainult nelja ebaolulise koodibloki kattuvust, mis olid tingitud POSIX ja ANSI C nõuetest.

Et mõista, kui palju "palju kiiremini", kasutan ekraanipilti kahe reaalse serveri koormusest, millel on sama konfiguratsioon (Xeon E5-1650v2), võrdne seadistamine, mis kasutavad sama Linuxi kernelit, kuid teostavad NAT-i iptables (NAT4) ja nftables (NAT5) abil.

Ekraanipildil ei ole pakettide sekundis graafikut, kuid nende serverite koormuse profiilis on paketi keskmine suurus umbes 800 baidi, seega väärtused ulatuvad 1.5Mpps. Nagu näha, on nftables serveri sooritusvõime reserv tohutu. Praegu suudab see server töödelda kuni 30Gbit/s kiirusel 3Mpps ja on selgelt võimeline saavutama füüsilise võrgu piirangu 40Gbps, omades samal ajal vabade CPU ressursside.