Me kalimin e adresave IPv4, shumë operatorë të telekomunikacionit janë ballafaquar me nevojën për të organizuar qasjen e klientëve të tyre në rrjet përmes përkthimit të adresave. Në këtë artikull do të flas për se si mund të arrihet performanca e nivelit Carrier Grade NAT në serverat e zakonshëm.
Pak histori
Tema e shterimit tĂ« hapĂ«sirĂ«s IP IPv4 nuk Ă«shtĂ« e re. NĂ« njĂ« moment, paraqitĂ«n lista pritjeje nĂ« RIPE, pastaj u shfaqĂ«n bursa ku tregoheshin blloqet e adresave dhe merren marrĂ«veshje pĂ«r qiradhĂ«nie. Gradually, operatorĂ«t e telekomunikacionit filluan tĂ« ofronin shĂ«rbime interneti pĂ«rmes pĂ«rkthimit tĂ« adresave dhe porteve. Disa nuk arritĂ«n tĂ« merrnin mjaft adresat pĂ«r tĂ« dhĂ«nĂ« njĂ« adresĂ« "tĂ« bardhĂ«" pĂ«r çdo abonent, ndĂ«rsa disa filluan tĂ« kursenin duke hequr dorĂ« nga blerja e adresave nĂ« tregun e dytĂ«. Prodhuesit e pajisjeve rrjetĂ«sore e mbĂ«shtetĂ«n kĂ«tĂ« ide, pasi ky funksionalitet zakonisht kĂ«rkon module shtesĂ« ose licenca. PĂ«r shembull, te Juniper, nĂ« linjĂ«n e routerave MX (pĂ«rveç MX104 dhe MX204 tĂ« fundit), kryerja e NAPT mund tĂ« bĂ«het nĂ« njĂ« kartĂ« shĂ«rbimi tĂ« veçantĂ« MS-MIC, te Cisco ASR1k kĂ«rkohet licence CGN, te Cisco ASR9k â njĂ« moduli tĂ« veçantĂ« A9K-ISM-100 dhe licenca A9K-CGN-LIC pĂ«r tĂ«. NĂ« pĂ«rgjithĂ«si, kĂ«naqĂ«sia kushton shumĂ«.
IPTables
Detyra e kryerjes së NAT nuk kërkon burime të specializuara të përpunimit, e cila mund të zgjidhet nga procesorët e zakonshëm, të cilët janë të instaluar, për shembull, në çdo router shtëpie. Në shkallën e operatorëve të telekomunikacionit, kjo detyrë mund të zgjidhet duke përdorur serverat e zakonshëm nën FreeBSD (ipfw/pf) ose GNU/Linux (iptables). Nuk do ta shqyrtojmë FreeBSD, pasi unë e kam hequr dorë që një kohë të gjatë nga përdorimi i këtij OS, kështu që do të fokusohemi në GNU/Linux.
Aktivizimi i përkthimit të adresave nuk është aspak e vështirë. Për fillim, duhet të shkruani një rregull në iptables në tabelën nat:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to - --persistent
Sistemi operativ do të ngarkojë moduline nf_conntrack, e cila do të monitorojë të gjitha lidhjet aktive dhe do të kryejë transformimet e nevojshme. Ka disa nuanca këtu. Së pari, pasi flasim për NAT në shkallë operatori të komunikimit, është e nevojshme të rregullohen timeout-t, sepse me vlerat e paracaktuara, madhësia e tabelës së përkthimit do të rritet mjaft shpejt në përmasa katastrofike. Më poshtë është një shembull i konfigurimeve që kam përdorur në serverët e mi:
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
Dhe së dyti, pasi madhësia e tabelës së përkthimit nuk është e llogaritur të funksionojë në kushte operatori të komunikimit, është e nevojshme që të rritet:
net.netfilter.nf_conntrack_max = 3145728
ĂshtĂ« gjithashtu e nevojshme tĂ« rritet edhe numri i buckets pĂ«r tabelĂ«n me hash, qĂ« ruan tĂ« gjitha pĂ«rkthimet (kjo Ă«shtĂ« njĂ« opsion i modulit nf_conntrack):
options nf_conntrack hashsize=1572864
Pas këtyre manovrave të thjeshta, krijohet një konstrukcion mjaft funksional, i cili mund të përkthejë një numër të madh të adresave të klientëve në një grup të jashtme. Sidoqoftë, performanca e këtij zgjidhjeje lë për të dëshiruar. Në përpjekjet e mia të para për të përdorur GNU/Linux për NAT (rreth vitit 2013) arrita të merrja një performancë rreth 7Gbit/s me 0.8Mpps në një server (Xeon E5-1650v2). Që nga atëherë, ka pasur shumë optimizime të ndryshme në grushtin e rrjetit të kernelit GNU/Linux, dhe performanca e një serveri me të njëjtin hardware është rritur pothuajse në 18-19 Gbit/s me 1.8-1.9 Mpps (këto ishin vlerat maksimale), por kërkesa për volum trafik që përpunonte një server erdhi duke u rritur shumë më shpejt. Si rezultat, u zhvilluan skema të balancimit të ngarkesës në serverë të ndryshëm, por gjithçka ka rritur kompleksitetin e konfigurimit, mbështetjes dhe ruajtjes së cilësisë së shërbimeve të ofruara.
NFTables
Aktualisht, një trend i njohur në "transferimin e paketave" është përdorimi i DPDK dhe XDP. Në këtë temë janë shkruar shumë artikuj, janë bërë shumë paraqitje të ndryshme dhe po shfaqen produkte komerciale (për shembull, SKAT nga VasExperts). Por në kushte të burimeve të kufizuara për programuesit e operatorëve të komunikimit, është mjaft problematike të zhvillosh ndonjë "ndarës" në bazë të këtyre kornizave. Eksplorimi i një zgjidhjeje të tillë më vonë do të jetë shumë më i komplikuar, sidomos për zhvillimin e mjeteve të diagnostikimit. Për shembull, tcpdump standard me DPDK nuk do të funksionojë lehtësisht, po ashtu as paketat e dërguara prapa në linjë me ndihmën e XDP nuk do të "shihen". Në kontekstin e të gjitha bisedave për teknologjitë e reja që kanë lidhje me forwarding-un e paketave në hapësirën e përdoruesit, janë mbetur të papërfillura dhe Pablo Neira Ayuso, mbajtësi i iptables, rreth zhvillimit të flow offloading në nftables. Le të shqyrtojmë këtë mekanizëm më në detaje.
Ideja kryesore Ă«shtĂ« se nĂ«se rrugĂ«zuesi i kalon paketat e njĂ« seance nĂ« tĂ« dyja anĂ«t e rrjedhĂ«s (seanca TCP ka kaluar nĂ« gjendjen ESTABLISHED), atĂ«herĂ« nuk ka nevojĂ« pĂ«r kalimin e paketave tĂ« mĂ«tejshme tĂ« kĂ«saj seance pĂ«rmes tĂ« gjitha rregullave tĂ« firewall-it, pasi tĂ« gjitha kĂ«to kontrollime pĂ«rfundimisht do tĂ« pĂ«rfundojnĂ« me kalimin e paketit nĂ« rrugĂ«zim. Po ashtu, zgjedhja e rrugĂ«s nuk duhet tĂ« bĂ«het â ne tashmĂ« e dimĂ« nĂ« cilin ndĂ«rfaqe dhe cilit host duhet t'i dĂ«rgohen paketat brenda kĂ«saj seance. Mbete vetĂ«m tĂ« ruash kĂ«tĂ« informacion dhe ta pĂ«rdorĂ«sh pĂ«r rrugĂ«zim nĂ« fazĂ«n e hershme tĂ« pĂ«rpunimit tĂ« paketĂ«ve. GjatĂ« realizimit tĂ« NAT-it duhet gjithashtu tĂ« ruhet informacioni mbi ndryshimet e adresave dhe porteve, tĂ« transformuara nga moduli nf_conntrack. Po, sigurisht, nĂ« kĂ«tĂ« rast ndalohen tĂ« punojnĂ« policerĂ«t e ndryshĂ«m dhe rregullat e tjera informativo-statistike nĂ« iptables, por nĂ« kuadĂ«r tĂ« detyrĂ«s sĂ« njĂ« NAT-i tĂ« veçantĂ« ose, pĂ«r shembull, tĂ« njĂ« interfejsi â kjo nuk Ă«shtĂ« kaq e rĂ«ndĂ«sishme, pasi shĂ«rbimet janĂ« tĂ« shpĂ«rndara nĂ« pajisje.
Konfigurimi
Për të shfrytëzuar këtë funksion na nevojitet:
- TĂ« pĂ«rdorim njĂ« kernel tĂ« ri. MegjithĂ«se funksionaliteti vetĂ« u shfaq nĂ« kernelin 4.16, ai ishte shumĂ« "i papjekur" pĂ«r njĂ« kohĂ« tĂ« gjatĂ« dhe rregullisht shkaktonte kernel panic. Ădo gjĂ« u stabilizua rreth dhjetorit 2019, kur dolĂ«n kernelat LTS 4.19.90 dhe 5.4.5.
- Riformuloni rregullat e iptables në formatin nftables, duke përdorur një version të mjaftueshëm të ri të nftables. Funksionon saktë në versionin 0.9.0
Nëse pika e parë është në parim e qartë, gjëja kryesore është të mos harrosh të aktivizosh modulin në konfigurim gjatë ndërtimit (CONFIG_NFT_FLOW_OFFLOAD=m), pika e dytë kërkon shpjegime. Rregullat e nftables përshkruhen krejt ndryshe nga ato në iptables. zbarton presque të gjitha momentet, gjithashtu ka konvertorë të veçantë Konfigurimi i NAT është shumë i thjeshtë:
Me flow offload është pak më e komplikuar, por plotësisht e qartë:
#! /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
}
}
Ja, në fakt, e gjithë konfigurimi. Tani, e gjithë trafiku TCP/UDP do të shkojë në tabelën fastnat dhe do të përpunohen shumë më shpejt.
#! /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;
}
}
Për të kuptuar sa "më ndjeshëm më shpejt", do të bashkëngjis një ekran të ngarkesës në dy servera realë, me të njëjtën konfigurim (Xeon E5-1650v2), të njëjtë të konfiguruar, duke përdorur të njëjtin bërthamë Linux, por duke e kryer NAT në iptables (NAT4) dhe në nftables (NAT5).
Rezultatet
Në ekran nuk ka grafiku të paketave për sekond, por në profilin e ngarkesës këta serverë kanë një madhësi mesatare të paketës rreth 800 bytes, prandaj vlerat arrijnë deri në 1.5Mpps. Siç duket, rezervat e performancës në serverin me nftables janë të mëdha. Në këtë moment, ky server përpunon deri në 30Gbit/s me 3Mpps dhe është qartë në gjendje të arrijë limitin fizik të rrjetit 40Gbps, duke pasur burime të lira CPU.
Shpresoj që ky material do të jetë i dobishëm për inxhinierët rrjetorë që përpiqen të përmirësojnë performancën e serverëve të tyre.
Ndërsa adresat IPv4 po përfundojnë, shumë operatorë të komunikimeve janë përballur me nevojën për të organizuar qasjen e klientëve të tyre në rrjet duke përdorur përkthimin e adresave.
Burimi: habr.com
