Kadangi IPv4 adresai išsenka, daugelis telekomunikacijų operatorių susiduria su poreikiu suteikti savo klientams prieigą prie tinklo naudojant adresų vertimą. Šiame straipsnyje aš jums pasakysiu, kaip galite gauti „Carrier Grade NAT“ našumą prekių serveriuose.
Truputis istorijos
IPv4 adresų erdvės išnaudojimo tema nebėra nauja. Tam tikru momentu RIPE atsirado laukiančiųjų sąrašai, tada atsirado biržos, kuriose buvo prekiaujama adresų blokais ir buvo sudaryti sandoriai dėl jų nuomos. Palaipsniui telekomunikacijų operatoriai pradėjo teikti interneto prieigos paslaugas naudodami adresų ir prievadų vertimą. Vieniems nepavyko gauti pakankamai adresų, kad kiekvienam abonentui išduotų „baltą“ adresą, o kiti ėmė taupyti pinigus atsisakydami pirkti adresus antrinėje rinkoje. Tinklo įrangos gamintojai palaikė šią idėją, nes šiai funkcijai paprastai reikia papildomų plėtinių modulių arba licencijų. Pavyzdžiui, Juniper MX maršrutizatorių linijoje (išskyrus naujausius MX104 ir MX204) galite atlikti NAPT atskiroje MS-MIC paslaugų kortelėje, Cisco ASR1k reikalinga CGN licencija, Cisco ASR9k – atskiras A9K-ISM-100 modulis. ir jam suteikta A9K-CGN licencija -LIC. Apskritai malonumas kainuoja daug pinigų.
IPTables
NAT vykdymo užduotis nereikalauja specializuotų skaičiavimo išteklių, ją gali išspręsti bendrosios paskirties procesoriai, kurie yra įdiegti, pavyzdžiui, bet kuriame namų maršrutizatoriuje. Telekomunikacijų operatoriaus mastu šią problemą galima išspręsti naudojant prekių serverius, kuriuose veikia FreeBSD (ipfw/pf) arba GNU/Linux (iptables). Mes nesvarstysime FreeBSD, nes... Šią OS nustojau naudoti gana seniai, todėl liksime prie GNU/Linux.
Įjungti adreso vertimą visai nėra sunku. Pirmiausia turite užregistruoti taisyklę iptables nat lentelėje:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent
Operacinė sistema įkels nf_conntrack modulį, kuris stebės visus aktyvius ryšius ir atliks reikiamas konversijas. Čia yra keletas subtilybių. Pirma, kadangi mes kalbame apie NAT telekomunikacijų operatoriaus mastu, būtina pakoreguoti skirtąjį laiką, nes esant numatytosioms reikšmėms vertimo lentelės dydis greitai išaugs iki katastrofiškų verčių. Žemiau pateikiamas serveriuose naudojamų nustatymų pavyzdys:
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
Antra, kadangi numatytasis vertimo lentelės dydis nėra skirtas veikti telekomunikacijų operatoriaus sąlygomis, jį reikia padidinti:
net.netfilter.nf_conntrack_max = 3145728
Taip pat būtina padidinti maišos lentelės, kurioje saugomos visos transliacijos, segmentų skaičių (tai yra modulio nf_conntrack parinktis):
options nf_conntrack hashsize=1572864
Po šių paprastų manipuliacijų gaunamas visiškai veikiantis dizainas, galintis paversti daugybę klientų adresų į išorinių adresų telkinį. Tačiau šio sprendimo našumas palieka daug norimų rezultatų. Pirmaisiais bandymais naudoti GNU/Linux NAT (apie 2013 m.) man pavyko pasiekti maždaug 7 Gbit/s našumą esant 0.8 Mpps vienam serveriui (Xeon E5-1650v2). Nuo to laiko GNU/Linux branduolio tinklo krūvoje buvo atlikta daug įvairių optimizacijų, vieno serverio našumas toje pačioje aparatinėje įrangoje išaugo iki beveik 18-19 Gbit/s esant 1.8-1.9 Mpps (tai buvo didžiausios reikšmės) , tačiau srauto, apdorojamo vienu serveriu, paklausa augo daug greičiau. Dėl to buvo sukurtos schemos, skirtos subalansuoti skirtingų serverių apkrovą, tačiau visa tai padidino teikiamų paslaugų nustatymo, priežiūros ir kokybės palaikymo sudėtingumą.
NF lentelės
Šiais laikais madinga programinės įrangos „perjungimo krepšių“ tendencija yra DPDK ir XDP naudojimas. Šia tema parašyta daug straipsnių, daug įvairių pasisakymų, atsiranda komercinių produktų (pavyzdžiui, SKAT iš VasExperts). Tačiau, atsižvelgiant į ribotus telekomunikacijų operatorių programavimo išteklius, pačiam sukurti bet kokį „produktą“ remiantis šiomis sistemomis yra gana problematiška. Ateityje tokį sprendimą naudoti bus daug sunkiau, visų pirma reikės sukurti diagnostikos priemones. Pavyzdžiui, standartinis tcpdump su DPDK neveiks taip ir „nematys“ paketų, siunčiamų atgal į laidus naudojant XDP. Visoms kalboms apie naujas technologijas, skirtas paketų persiuntimui į vartotojo erdvę, jie liko nepastebėti и Pablo Neira Ayuso, iptables prižiūrėtojas, apie srauto iškrovimo kūrimą nftables. Pažvelkime į šį mechanizmą atidžiau.
Pagrindinė idėja yra ta, kad jei maršrutizatorius perdavė paketus iš vienos sesijos abiem srauto kryptimis (TCP seansas perėjo į NUSTATYTA būseną), tada nereikia perduoti tolesnių šios sesijos paketų per visas ugniasienės taisykles, nes visi šie patikrinimai vis tiek baigsis, kai paketas bus perkeltas toliau į maršrutą. Ir mums iš tikrųjų nereikia pasirinkti maršruto – mes jau žinome, į kurią sąsają ir į kurį pagrindinį kompiuterį turime siųsti paketus šios sesijos metu. Belieka saugoti šią informaciją ir naudoti ją maršruto parinkimui ankstyvame paketų apdorojimo etape. Atliekant NAT, būtina papildomai saugoti informaciją apie nf_conntrack modulio išverstus adresų ir prievadų pasikeitimus. Taip, žinoma, tokiu atveju nustoja veikti įvairūs policininkai ir kitos informacijos bei statistikos taisyklės iptables, bet atskiro nuolatinio NAT ar, pavyzdžiui, sienos užduoties rėmuose tai nėra taip svarbu, nes tarnybos yra paskirstyti įrenginiuose.
Konfigūravimas
Norėdami naudoti šią funkciją, mums reikia:
- Naudokite šviežią branduolį. Nepaisant to, kad pats funkcionalumas pasirodė branduolyje 4.16, gana ilgą laiką jis buvo labai „neapdorotas“ ir reguliariai kėlė branduolio paniką. Viskas stabilizavosi apie 2019 m. gruodį, kai buvo išleisti LTS branduoliai 4.19.90 ir 5.4.5.
- Perrašykite iptables taisykles nftables formatu naudodami gana naujausią nftables versiją. Veikia tiksliai 0.9.0 versijoje
Jei su pirmuoju tašku iš principo viskas aišku, svarbiausia nepamiršti modulio įtraukti į konfigūraciją surinkimo metu (CONFIG_NFT_FLOW_OFFLOAD=m), tada antrasis punktas reikalauja paaiškinimo. nftables taisyklės aprašomos visiškai kitaip nei iptables. atskleidžia beveik visus taškus, yra ir specialių taisyklės nuo iptables iki nftables. Todėl pateiksiu tik NAT nustatymo ir srauto iškrovimo pavyzdį. Pavyzdžiui, maža legenda: , - Tai yra tinklo sąsajos, per kurias praeina srautas; iš tikrųjų jų gali būti daugiau nei dvi. , — „baltųjų“ adresų diapazono pradžios ir pabaigos adresai.
NAT konfigūracija yra labai paprasta:
#! /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
}
}
Su srauto iškrovimu viskas yra šiek tiek sudėtingesnė, bet gana suprantama:
#! /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;
}
}
Tiesą sakant, tai yra visa sąranka. Dabar visas TCP/UDP srautas pateks į „fastnat“ lentelę ir bus apdorojamas daug greičiau.
rezultatai
Kad būtų aišku, kiek tai yra „daug greitesnis“, pridėsiu dviejų tikrų serverių apkrovos ekrano kopiją su ta pačia technine įranga (Xeon E5-1650v2), sukonfigūruota identiškai, naudojant tą patį Linux branduolį, bet atliekant NAT iptables. (NAT4) ir nfttables (NAT5).
Ekrano kopijoje nėra paketų per sekundę grafiko, tačiau šių serverių apkrovos profilyje vidutinis paketo dydis yra apie 800 baitų, todėl reikšmės siekia iki 1.5 Mpps. Kaip matote, serveris su nftables turi didžiulį našumo rezervą. Šiuo metu šis serveris apdoroja iki 30 Gbit/s 3Mpps greičiu ir akivaizdžiai gali patenkinti fizinio tinklo apribojimą – 40 Gbps, turėdamas laisvus procesoriaus išteklius.
Tikiuosi, kad ši medžiaga bus naudinga tinklo inžinieriams, bandantiems pagerinti savo serverių našumą.
Šaltinis: www.habr.com