ProHoster > Blogs > Administrācija > Ātra marÅ”rutÄ“Å”ana un NAT operētājsistēmā Linux

Ātra marÅ”rutÄ“Å”ana un NAT operētājsistēmā Linux

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 ziņojumi Šø Raksts 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 pārveidotāji 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).

Ātra marÅ”rutÄ“Å”ana un NAT operētājsistēmā Linux

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

Pievieno komentāru