Tā kā IPv4 adreses izsīkst, daudzi telekomunikāciju operatori saskaras ar nepieciešamību nodrošināt saviem klientiem piekļuvi tīklam, izmantojot adrešu tulkošanu. Šajā rakstā es jums pastāstīšu, kā jūs varat iegūt Carrier Grade NAT veiktspēju preču serveros.
Nedaudz vēstures
IPv4 adrešu telpas izsmelšanas tēma vairs nav jauna. Kādā brīdī RIPE parādījās gaidīšanas saraksti, tad radās biržas, kurās tika tirgoti adrešu bloki un noslēgti darījumi par to nomu. Pamazām telekomunikāciju operatori sāka nodrošināt interneta piekļuves pakalpojumus, izmantojot adrešu un portu tulkošanu. Dažiem neizdevās iegūt pietiekami daudz adrešu, lai katram abonentam izsniegtu “balto” adresi, savukārt citi sāka taupīt naudu, atsakoties iegādāties adreses otrreizējā tirgū. Tīkla iekārtu ražotāji atbalstīja šo ideju, jo šai funkcionalitātei parasti ir nepieciešami papildu paplašinājumu moduļi vai licences. Piemēram, Juniper MX maršrutētāju līnijā (izņemot jaunākos MX104 un MX204) NAPT var veikt atsevišķā MS-MIC servisa kartē, Cisco ASR1k nepieciešama CGN licence, Cisco ASR9k ir nepieciešams atsevišķs A9K-ISM-100 modulis. un viņam A9K-CGN licence -LIC. Kopumā prieks maksā daudz naudas.
IPTables
NAT veikšanas uzdevumam nav nepieciešami specializēti skaitļošanas resursi, to var atrisināt ar vispārējas nozīmes procesoriem, kas tiek uzstādīti, piemēram, jebkurā mājas maršrutētājā. Telekomunikāciju operatora mērogā šo problēmu var atrisināt, izmantojot preču serverus, kuros darbojas FreeBSD (ipfw/pf) vai GNU/Linux (iptables). Mēs neapsvērsim FreeBSD, jo... Es pārtraucu lietot šo OS diezgan sen, tāpēc mēs paliksim pie GNU/Linux.
Adreses tulkošanas iespējošana nepavisam nav grūta. Vispirms nat tabulā ir jāreģistrē kārtula iptables:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent
Operētājsistēma ielādēs moduli nf_conntrack, kas uzraudzīs visus aktīvos savienojumus un veiks nepieciešamās konvertācijas. Šeit ir vairāki smalkumi. Pirmkārt, tā kā mēs runājam par NAT telekomunikāciju operatora mērogā, ir nepieciešams pielāgot taimautus, jo ar noklusējuma vērtībām tulkošanas tabulas lielums ātri pieaugs līdz katastrofālām vērtībām. Tālāk ir sniegts savos serveros izmantoto iestatījumu piemērs:
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
Un, otrkārt, tā kā tulkošanas tabulas noklusējuma lielums nav paredzēts darbam telekomunikāciju operatora apstākļos, tas ir jāpalielina:
net.netfilter.nf_conntrack_max = 3145728
Ir arī jāpalielina segmentu skaits hash tabulai, kurā tiek glabāti visi raidījumi (šī ir opcija modulī nf_conntrack):
options nf_conntrack hashsize=1572864
Pēc šīm vienkāršajām manipulācijām tiek iegūts pilnībā funkcionējošs dizains, kas var pārvērst lielu skaitu klientu adrešu ārējo adrešu pūlā. Tomēr šī risinājuma veiktspēja atstāj daudz ko vēlēties. Pirmajos mēģinājumos izmantot GNU/Linux operētājsistēmai NAT (apmēram 2013. gadā), man izdevās iegūt veiktspēju aptuveni 7 Gbit/s ar ātrumu 0.8 Mpps uz vienu serveri (Xeon E5-1650v2). Kopš tā laika GNU/Linux kodola tīkla stekā ir veiktas daudzas dažādas optimizācijas, viena servera veiktspēja uz vienas aparatūras ir palielinājusies līdz gandrīz 18-19 Gbit/s pie 1.8-1.9 Mpps (tās bija maksimālās vērtības) , taču pieprasījums pēc trafika apjoma, ko apstrādā viens serveris, pieauga daudz straujāk. Rezultātā tika izstrādātas shēmas dažādu serveru slodzes līdzsvarošanai, taču tas viss palielināja sniegto pakalpojumu iestatīšanas, uzturēšanas un kvalitātes uzturēšanas sarežģītību.
NFTabulas
Mūsdienās programmatūras “pārslēgšanās somu” modes tendence ir DPDK un XDP izmantošana. Par šo tēmu ir rakstīts daudz rakstu, izteiktas dažādas runas, parādās komercprodukti (piemēram, SKAT no VasExperts). Bet, ņemot vērā telekomunikāciju operatoru ierobežotos programmēšanas resursus, ir diezgan problemātiski patstāvīgi izveidot jebkuru “produktu”, pamatojoties uz šiem ietvariem. Nākotnē ar šādu risinājumu darboties būs daudz grūtāk, jo īpaši būs jāizstrādā diagnostikas instrumenti. Piemēram, standarta tcpdump ar DPDK nedarbosies tāpat vien, un tas "neredzēs" paketes, kas tiek nosūtītas atpakaļ uz vadiem, izmantojot XDP. Visās runās par jaunajām tehnoloģijām pakešu pārsūtīšanas izvadīšanai lietotāja telpā tās palika nepamanītas и Pablo Neira Ayuso, iptables uzturētājs, par plūsmas izkraušanas attīstību nftables. Apskatīsim šo mehānismu tuvāk.
Galvenā ideja ir tāda, ka, ja maršrutētājs nodod paketes no vienas sesijas abos plūsmas virzienos (TCP sesija pārgāja stāvoklī ESTABLISHED), tad nav nepieciešams nodot nākamās šīs sesijas paketes caur visiem ugunsmūra noteikumiem, jo visas šīs pārbaudes joprojām beigsies ar paketes pārsūtīšanu tālāk uz maršrutēšanu. Un mums faktiski nav jāizvēlas maršruts — mēs jau zinām, uz kuru saskarni un uz kuru resursdatoru mums ir jānosūta paketes šīs sesijas laikā. Atliek tikai saglabāt šo informāciju un izmantot to maršrutēšanai agrīnā pakešu apstrādes stadijā. Veicot NAT, nepieciešams papildus glabāt informāciju par moduļa nf_conntrack tulkotajām adrešu un portu izmaiņām. Jā, protams, šajā gadījumā iptables pārstāj darboties dažādi policisti un citi informācijas un statistikas noteikumi, bet atsevišķa pastāvīgā NAT vai, piemēram, robežas uzdevuma ietvaros tas nav tik svarīgi, jo dienesti tiek izplatīti starp ierīcēm.
Konfigurācija
Lai izmantotu šo funkciju, mums ir nepieciešams:
- Izmantojiet svaigu kodolu. Neskatoties uz to, ka pati funkcionalitāte parādījās kodolā 4.16, diezgan ilgu laiku tā bija ļoti “neapstrādāta” un regulāri izraisīja kodola paniku. Viss stabilizējās ap 2019. gada decembri, kad tika izlaisti LTS kodoli 4.19.90 un 5.4.5.
- Pārrakstiet iptables noteikumus nftables formātā, izmantojot diezgan jaunāku nftables versiju. Darbojas tieši versijā 0.9.0
Ja ar pirmo punktu principā viss ir skaidrs, galvenais neaizmirst montējot moduli iekļaut konfigurācijā (CONFIG_NFT_FLOW_OFFLOAD=m), tad otrais punkts prasa paskaidrojumu. nftables noteikumi ir aprakstīti pavisam savādāk nekā iptables. atklāj gandrīz visus punktus, ir arī īpaši noteikumi no iptables uz nftables. Tāpēc es sniegšu tikai piemēru NAT iestatīšanai un plūsmas izkraušanai. Piemēram, neliela leģenda: , - šīs ir tīkla saskarnes, caur kurām notiek satiksme; patiesībā to var būt vairāk nekā divas. , — “balto” adrešu diapazona sākuma un beigu adrese.
NAT konfigurācija ir ļoti vienkārša:
#! /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
}
}
Ar plūsmas noslodzi ir nedaudz sarežģītāk, bet diezgan saprotami:
#! /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;
}
}
Tas patiesībā ir viss uzstādījums. Tagad visa TCP/UDP trafika nonāks fastnat tabulā un tiks apstrādāta daudz ātrāk.
rezultātus
Lai būtu skaidrs, cik tas ir “daudz ātrāk”, pievienošu ekrānuzņēmumu, kurā redzama slodze uz diviem reāliem serveriem ar vienādu aparatūru (Xeon E5-1650v2), identiski konfigurētu, izmantojot to pašu Linux kodolu, bet veic NAT iptables. (NAT4) un nftables (NAT5).
Ekrānuzņēmumā nav pakešu diagrammas sekundē, taču šo serveru slodzes profilā vidējais pakešu lielums ir aptuveni 800 baiti, tāpēc vērtības sasniedz pat 1.5 Mpps. Kā redzat, serverim ar nftables ir milzīga veiktspējas rezerve. Pašlaik šis serveris apstrādā līdz 30Gbit/s ar ātrumu 3Mpps un nepārprotami spēj izpildīt fiziskā tīkla ierobežojumu 40Gbps, vienlaikus nodrošinot brīvus CPU resursus.
Ceru, ka šis materiāls būs noderīgs tīkla inženieriem, kuri cenšas uzlabot savu serveru veiktspēju.
Avots: www.habr.com
