🥇Rapida vojigo kaj NAT enigo Linux

Ĉar IPv4-adresoj malpleniĝas, multaj teleentreprenistoj alfrontas la bezonon provizi siajn klientojn per retaliro uzante adrestradukon. En ĉi tiu artikolo mi rakontos al vi kiel vi povas akiri Carrier Grade NAT-agadon sur varaj serviloj.

Iom da historio

La temo pri elĉerpiĝo de adresspaco IPv4 ne plu estas nova. En iu momento, atendlistoj aperis en RIPE, tiam aperis interŝanĝoj, sur kiuj blokoj de adresoj estis komercitaj kaj interkonsentoj estis finitaj por lui ilin. Iom post iom, teleentreprenistoj komencis disponigi retalirservojn uzante adreson kaj haventradukon. Iuj ne sukcesis akiri sufiĉe da adresoj por doni "blankan" adreson al ĉiu abonanto, dum aliaj komencis ŝpari monon rifuzante aĉeti adresojn sur la malĉefa merkato. Fabrikistoj de retaj ekipaĵoj subtenis ĉi tiun ideon, ĉar ĉi tiu funkcio kutime postulas pliajn etendaĵojn aŭ licencojn. Ekzemple, en la linio de MX-enkursigiloj de Juniper (krom la plej novaj MX104 kaj MX204), vi povas plenumi NAPT sur aparta MS-MIC-servokarto, Cisco ASR1k postulas CGN-licencon, Cisco ASR9k postulas apartan A9K-ISM-100-modulon. kaj A9K-CGN-licenco -LIC al li. Ĝenerale, la plezuro kostas multe da mono.

IPTables

NAT-efektivigo ne postulas specialajn komputilajn rimedojn; ĝin povas pritrakti ĝeneraluzeblaj procesoroj, kiel tiuj troveblaj en iu ajn hejma enkursigilo. Ĉe la skalo de telekomunika funkciigisto, ĉi tiu tasko povas esti plenumita uzante ordinarajn servilojn funkciantajn per FreeBSD (ipfw/pf) aŭ GNU/Linux (iptables). Ni ne rigardos FreeBSD, ĉar mi ĉesis uzi tiun operaciumon antaŭ iom da tempo, do ni restu ĉe GNU/Linux.

Ebligi adrestradukadon tute ne estas malfacila. Unue vi devas registri regulon en iptables en la nat-tabelo:

iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent

La operaciumo ŝarĝos la modulon nf_conntrack, kiu kontrolos ĉiujn aktivajn konektojn kaj faros la necesajn konvertiĝojn. Estas pluraj subtilecoj ĉi tie. Unue, ĉar ni parolas pri NAT laŭ la skalo de telekomunika operatoro, necesas ĝustigi la tempodaŭrojn, ĉar kun defaŭltaj valoroj la grandeco de la traduktabelo rapide kreskos al katastrofaj valoroj. Malsupre estas ekzemplo de la agordoj, kiujn mi uzis sur miaj serviloj:

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

Kaj due, ĉar la defaŭlta grandeco de la traduktabelo ne estas desegnita por funkcii sub la kondiĉoj de telekomunika operatoro, ĝi devas esti pliigita:

net.netfilter.nf_conntrack_max = 3145728

Necesas ankaŭ pliigi la nombron da siteloj por la hashtabelo stokanta ĉiujn elsendojn (ĉi tio estas opcio en la modulo nf_conntrack):

options nf_conntrack hashsize=1572864

Post ĉi tiuj simplaj manipuladoj, oni akiras plene funkcian dezajnon, kiu povas dissendi grandan nombron da klientaj adresoj al aro da eksteraj adresoj. Tamen, la efikeco de ĉi tiu solvo lasas multe por deziri. En miaj unuaj provoj uzi GNU/Linux Por NAT (ĉirkaŭ 2013), mi sukcesis atingi rendimenton de ĉirkaŭ 7Gbit/s je 0.8Mpps sur unuopa servilo (Xeon E5-1650v2). Ekde tiam, la GNU-kerna retstako/Linux Multnombraj optimumigoj estis faritaj, kaj la rendimento de unuopa servilo sur la sama aparataro pliiĝis al preskaŭ 18-19 Gbit/s je 1.8-1.9 Mpps (ĉi tiuj estis la maksimumaj valoroj), sed la postulo je trafiko pritraktita de unuopa servilo kreskis multe pli rapide. Fine, ŝarĝekvilibrigaj skemoj estis evoluigitaj por malsamaj serviloj, sed ĉio ĉi pliigis la kompleksecon de agordo, bontenado kaj konservado de la kvalito de la provizitaj servoj.

NTFables

Nuntempe, moda tendenco en programaro "ŝanĝaj sakoj" estas la uzo de DPDK kaj XDP. Multaj artikoloj estis verkitaj pri ĉi tiu temo, multaj diversaj paroladoj estis faritaj, kaj komercaj produktoj aperas (ekzemple SKAT de VasExperts). Sed konsiderante la limigitajn programajn rimedojn de telekomunikaj telefonistoj, estas sufiĉe probleme krei ajnan "produkton" bazitan sur ĉi tiuj kadroj memstare. Estos multe pli malfacile funkciigi tian solvon en la estonteco; precipe, diagnozaj iloj devos esti evoluigitaj. Ekzemple, norma tcpdump kun DPDK ne funkcios ĝuste tiel, kaj ĝi ne "vidos" pakaĵetojn senditajn reen al la dratoj uzante XDP. Inter ĉiuj paroladoj pri novaj teknologioj por eligi pakaĵeton al uzantspaco, ili pasis nerimarkitaj raportoj и artikoloj Pablo Neira Ayuso, prizorganto de iptables, pri la evoluo de fluo-malŝarĝado en nftables. Ni rigardu pli detale ĉi tiun mekanismon.

La ĉefa ideo estas, ke se la enkursigilo pasis pakaĵetojn de unu sesio en ambaŭ direktoj de la fluo (TCP-sesio eniris la staton ESTABLISHED), tiam ne necesas pasi postajn pakaĵetojn de ĉi tiu sesio tra ĉiuj fajroŝirmigaj reguloj, ĉar ĉiuj ĉi tiuj kontroloj ankoraŭ finiĝos kun la pakaĵeto translokigita plu al la vojigo. Kaj ni fakte ne bezonas elekti itineron - ni jam scias al kiu interfaco kaj al kiu gastiganto ni devas sendi pakaĵojn ene de ĉi tiu sesio. Restas nur stoki ĉi tiun informon kaj uzi ĝin por vojigo en frua etapo de paka pretigo. Farante NAT, necesas aldone konservi informojn pri ŝanĝoj en adresoj kaj pordoj tradukitaj per la modulo nf_conntrack. Jes, kompreneble, ĉi-kaze diversaj policistoj kaj aliaj informaj kaj statistikaj reguloj en iptables ĉesas funkcii, sed kadre de la tasko de aparta staranta NAT aŭ ekzemple limo, tio ne tiom gravas, ĉar la servoj estas distribuitaj tra aparatoj.

Agordo

Por uzi ĉi tiun funkcion ni bezonas:

Uzu freŝan kernon. Malgraŭ tio, ke la funkcieco mem aperis en kerno 4.16, dum sufiĉe longa tempo ĝi estis tre "kruda" kaj regule kaŭzis kernan panikon. Ĉio stabiliĝis ĉirkaŭ decembro 2019, kiam LTS-kernoj 4.19.90 kaj 5.4.5 estis liberigitaj.
Reskribi regulojn de iptables en formato nftables uzante sufiĉe lastatempan version de nftables. Funkcias ĝuste en versio 0.9.0

Se ĉio principe estas klara kun la unua punkto, la ĉefa afero estas ne forgesi inkluzivi la modulon en la agordo dum kunigo (CONFIG_NFT_FLOW_OFFLOAD=m), tiam la dua punkto postulas klarigon. nftables reguloj estas priskribitaj tute malsame ol en iptables. Dokumentado malkaŝas preskaŭ ĉiujn punktojn, ekzistas ankaŭ specialaj konvertiloj reguloj de iptables ĝis nftables. Tial mi nur donos ekzemplon pri agordo de NAT kaj fluo-malŝarĝo. Eta legendo ekzemple: , - ĉi tiuj estas la retaj interfacoj tra kiuj trafiko pasas; fakte povas esti pli ol du el ili. , — la komenca kaj fina adreso de la gamo de "blankaj" adresoj.

NAT-agordo estas tre simpla:

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

Kun flua malŝarĝo ĝi estas iom pli komplika, sed sufiĉe komprenebla:

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

Tio, fakte, estas la tuta aranĝo. Nun ĉiuj TCP/UDP-trafiko falos en la fastnat-tabelon kaj estos prilaborita multe pli rapide.

Результаты

Por klarigi kiom pli rapide ĉi tio estas, mi alkroĉos ekranfoton de la ŝarĝo sur du realaj serviloj, kun la sama aparataro (Xeon E5-1650v2), agorditaj idente, uzante la saman kernon. Linux, sed plenumante NAT-on en iptables (NAT4) kaj en nftables (NAT5).

Ne estas grafikaĵo de pakoj sekundo en la ekrankopio, sed en la ŝarĝa profilo de ĉi tiuj serviloj la meza paka grandeco estas ĉirkaŭ 800 bajtoj, do la valoroj atingas ĝis 1.5Mpps. Kiel vi povas vidi, la servilo kun nftables havas grandegan rendimentan rezervon. Nuntempe, ĉi tiu servilo procesas ĝis 30Gbit/s je 3Mpps kaj klare kapablas renkonti la fizikan retan limigon de 40Gbps, havante senpagajn CPU-resursojn.