Kuna IPv4-aadressid ammenduvad, seisavad paljud telekommunikatsioonioperaatorid silmitsi vajadusega pakkuda oma klientidele aadressi tõlkimise abil juurdepääsu võrgule. Selles artiklis räägin teile, kuidas saada kaubaserverites operaatoritaseme NAT-i jõudlust.
Veidi ajalugu
IPv4 aadressiruumi ammendumise teema pole enam uus. Mingil hetkel tekkisid RIPE-sse ootenimekirjad, siis tekkisid börsid, millel kaubeldi aadressiplokkidega ja sõlmiti tehinguid nende liisimiseks. Järk-järgult hakkasid telekommunikatsioonioperaatorid pakkuma Interneti-juurdepääsu teenuseid aadresside ja pordi tõlke abil. Mõnel ei õnnestunud hankida piisavalt aadresse, et igale tellijale “valge” aadress väljastada, teised aga hakkasid raha kokku hoidma, keeldudes aadresse järelturult ostmast. Võrguseadmete tootjad toetasid seda ideed, kuna see funktsioon nõuab tavaliselt täiendavaid laiendusmooduleid või litsentse. Näiteks Juniperi MX-ruuterite sarjas (v.a uusimad MX104 ja MX204) saate NAPT-i teha eraldi MS-MIC teeninduskaardil, Cisco ASR1k nõuab CGN-litsentsi, Cisco ASR9k nõuab eraldi A9K-ISM-100 moodulit. ja talle A9K-CGN litsents -LIC. Üldiselt maksab rõõm palju raha.
IPTables
NAT-i täitmise ülesanne ei nõua spetsiaalseid arvutusressursse, seda saab lahendada üldotstarbeliste protsessorite abil, mis on installitud näiteks igasse koduruuterisse. Telekommunikatsioonioperaatori mastaabis saab selle probleemi lahendada, kasutades FreeBSD-d (ipfw/pf) või GNU/Linuxit (iptables) kasutavaid kaubaservereid. Me ei kaalu FreeBSD-d, sest... Lõpetasin selle OS-i kasutamise üsna kaua aega tagasi, seega jääme GNU/Linuxi juurde.
Aadressi tõlkimise lubamine pole sugugi keeruline. Kõigepealt peate nat-tabelis iptablesis reegli registreerima:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent
Operatsioonisüsteem laadib mooduli nf_conntrack, mis jälgib kõiki aktiivseid ühendusi ja teostab vajalikud teisendused. Siin on mitmeid nüansse. Esiteks, kuna me räägime NAT-ist telekommunikatsioonioperaatori skaalal, on vaja ajalõppe kohandada, sest vaikeväärtuste korral kasvab tõlketabeli suurus kiiresti katastroofiliste väärtusteni. Allpool on näide seadetest, mida oma serverites kasutasin:
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 tõlketabeli vaikesuurus ei ole mõeldud telekommunikatsioonioperaatori tingimustes töötamiseks, tuleb seda suurendada:
net.netfilter.nf_conntrack_max = 3145728
Samuti on vaja suurendada kõiki ülekandeid salvestava räsitabeli ämbrite arvu (see on mooduli nf_conntrack valik):
options nf_conntrack hashsize=1572864
Pärast neid lihtsaid manipuleerimisi saadakse täiesti töötav disain, mis suudab tõlkida suure hulga kliendiaadresse väliste aadresside kogumiks. Selle lahenduse jõudlus jätab aga soovida. Minu esimestel katsetel kasutada GNU/Linuxi NAT-i jaoks (umbes 2013. aastal) suutsin saavutada kiirusega umbes 7 Gbit/s 0.8 Mpps serveri kohta (Xeon E5-1650v2). Sellest ajast peale on GNU/Linuxi kerneli võrgupinus tehtud palju erinevaid optimeerimisi, ühe serveri jõudlus samal riistvaral on tõusnud ligi 18-19 Gbit/s kiirusel 1.8-1.9 Mpps (need olid maksimumväärtused) , kuid nõudlus ühe serveri poolt töödeldava liiklusmahu järele kasvas palju kiiremini. Selle tulemusena töötati välja skeemid erinevate serverite koormuse tasakaalustamiseks, kuid see kõik suurendas pakutavate teenuste seadistamise, hooldamise ja kvaliteedi säilitamise keerukust.
NFTable
Tänapäeval on tarkvara „vahetuskottide” moes trend DPDK ja XDP kasutamine. Sellel teemal on kirjutatud palju artikleid, peetud palju erinevaid sõnavõtte, ilmuvad kommertstooted (näiteks SKAT firmalt VasExperts). Kuid arvestades telekommunikatsioonioperaatorite piiratud programmeerimisressursse, on nende raamistike põhjal mis tahes "toote" ise loomine üsna problemaatiline. Sellist lahendust on tulevikus palju keerulisem kasutada, eelkõige tuleb välja töötada diagnostikavahendid. Näiteks tavaline tcpdump koos DPDK-ga ei tööta niisama ega näe XDP abil juhtmetesse tagasi saadetud pakette. Keset kogu juttu uutest tehnoloogiatest pakettide edastamiseks kasutajaruumi, jäid need märkamatuks и Pablo Neira Ayuso, iptablesi hooldaja, voo mahalaadimise arendamise kohta nftablesis. Vaatame seda mehhanismi lähemalt.
Põhiidee seisneb selles, et kui ruuter läbis ühest seansist pakette voo mõlemas suunas (TCP seanss läks olekusse ESTABLISHED), siis ei ole vaja selle seansi järgnevaid pakette läbida kõik tulemüürireeglid, sest kõik need kontrollid lõppevad ikkagi sellega, et pakett suunatakse edasi marsruutimisse. Ja me ei pea tegelikult marsruuti valima – me juba teame, millisele liidesele ja millisele hostile peame selle seansi jooksul pakette saatma. Jääb vaid see teave salvestada ja kasutada marsruutimiseks pakettide töötlemise varases staadiumis. NAT-i teostamisel on vaja täiendavalt salvestada teavet mooduli nf_conntrack tõlgitud aadresside ja portide muutuste kohta. Jah, muidugi, sel juhul lakkavad töötamast erinevad politseinikud ja muud info- ja statistikareeglid iptablesis, aga eraldiseisva NAT või näiteks piiri ülesande raames pole see nii oluline, sest teenused on jagatud seadmete vahel.
Konfiguratsioon
Selle funktsiooni kasutamiseks vajame:
- Kasutage värsket tuuma. Hoolimata asjaolust, et funktsionaalsus ise ilmus kernelis 4.16, oli see üsna pikka aega väga "toores" ja põhjustas regulaarselt kerneli paanikat. Kõik stabiliseerus 2019. aasta detsembri paiku, kui välja anti LTS-i tuumad 4.19.90 ja 5.4.5.
- Kirjutage iptablesi reeglid ümber nftables-vormingus, kasutades nftablesi üsna värsket versiooni. Töötab täpselt versioonis 0.9.0
Kui esimese punktiga on põhimõtteliselt kõik selge, peaasi, et moodulit monteerimisel konfiguratsiooni ei unustataks (CONFIG_NFT_FLOW_OFFLOAD=m), siis teine punkt vajab selgitust. nftablesi reegleid kirjeldatakse hoopis teisiti kui iptablesis. paljastab peaaegu kõik punktid, on ka erilisi reeglid iptables-ist nftable-ni. Seetõttu toon ainult näite NAT-i seadistamise ja voo mahalaadimise kohta. Väike legend näiteks: , - need on võrguliidesed, mida liiklus läbib; tegelikkuses võib neid olla rohkem kui kaks. , — valgete aadresside vahemiku algus- ja lõppaadress.
NAT-i konfigureerimine 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
}
}
Voolu mahalaadimisega on see veidi keerulisem, kuid üsna 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;
}
}
See on tegelikult kogu seadistus. Nüüd langeb kogu TCP/UDP-liiklus fastnat-tabelisse ja seda töödeldakse palju kiiremini.
Järeldused
Et teha selgeks, kui "palju kiirem" see on, lisan ekraanipildi kahe päris serveri koormusest, millel on sama riistvara (Xeon E5-1650v2), mis on identselt konfigureeritud ja kasutavad sama Linuxi tuuma, kuid täidavad iptablesis NAT-i. (NAT4) ja nftables (NAT5).
Ekraanipildil pole pakettide graafikut sekundis, kuid nende serverite laadimisprofiilis on paketi keskmine suurus umbes 800 baiti, seega ulatuvad väärtused kuni 1.5 Mpps. Nagu näete, on nftablesiga serveril tohutu jõudlusreserv. Praegu töötleb see server kiirusega kuni 30 Gbit/s kiirusel 3Mpps ja on selgelt suuteline täitma füüsilise võrgu piirangut 40 Gbps, omades samal ajal tasuta protsessoriressursse.
Loodan, et see materjal on kasulik võrguinseneridele, kes üritavad oma serverite jõudlust parandada.
Allikas: www.habr.com