ProHoster > Blog > Administrazioa > Bideratze azkarra eta NAT Linux-en

Bideratze azkarra eta NAT Linux-en

IPv4 helbideak agortzen diren heinean, telekomunikazio-operadore askok beren bezeroei sarerako sarbidea eskaintzeko beharra dute helbide-itzulpena erabiliz. Artikulu honetan esango dizut nola lor dezakezun Carrier Grade NAT errendimendua salgaien zerbitzarietan.

Historia apur bat

IPv4 helbide-espazioa agortzearen gaia jada ez da berria. Noizbait, itxaron-zerrendak agertu ziren RIPEn, gero trukeak sortu ziren zeinetan helbide-blokeetan negoziatzen ziren eta alokairurako akordioak egin ziren. Pixkanaka-pixkanaka, telekomunikazio-operadoreak Interneterako sarbide-zerbitzuak ematen hasi ziren helbidea eta portuen itzulpena erabiliz. Batzuk ez zuten lortu harpidedun bakoitzari helbide "zuria" igortzeko behar adina helbide lortzea, eta beste batzuk, berriz, bigarren merkatuan helbideak erosteari uko eginez dirua aurrezten hasi ziren. Sareko ekipoen fabrikatzaileek ideia hori onartzen zuten, zeren funtzionalitate honek luzapen modulu edo lizentzia osagarriak behar ditu normalean. Adibidez, Juniper-en MX bideratzaileen lerroan (azken MX104 eta MX204 izan ezik), MS-MIC zerbitzu-txartel bereizi batean NAPT egin dezakezu, Cisco ASR1k CGN lizentzia behar du, Cisco ASR9k A9K-ISM-100 modulu bereizia. eta A9K-CGN lizentzia -LIC berari. Oro har, plazerak diru asko kostatzen du.

iptables

NAT egiteko zereginak ez du baliabide informatiko espezializaturik behar; erabilera orokorreko prozesadoreen bidez konpondu daiteke, adibidez, etxeko edozein bideratzailetan instalatuta daudenak. Telekomunikazio-operadore baten eskalan, arazo hau FreeBSD (ipfw/pf) edo GNU/Linux (iptables) exekutatzen duten produktuen zerbitzariak erabiliz konpondu daiteke. Ez dugu FreeBSD kontuan hartuko, zeren... Duela dezente utzi nion OS hau erabiltzeari, beraz GNU/Linux-era jarraituko dugu.

Helbideen itzulpena gaitzea ez da batere zaila. Lehenik eta behin, arau bat erregistratu behar duzu iptables-en nat taulan:

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

Sistema eragileak nf_conntrack modulua kargatuko du, konexio aktibo guztiak kontrolatuko dituena eta beharrezko bihurketak egingo dituena. Hainbat Γ±abardura daude hemen. Lehenik eta behin, telekomunikazio-operadore baten eskalan NATari buruz ari garenez, beharrezkoa da denbora-mugak doitzea, balio lehenetsiekin itzulpen-taularen tamaina azkar haziko baita balio katastrofikoetara. Jarraian nire zerbitzarietan erabili ditudan ezarpenen adibide bat dago:

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

Eta bigarrenik, itzulpen-taularen tamaina lehenetsia telekomunikazio-operadore baten baldintzetan lan egiteko diseinatuta dagoenez, handitu egin behar da:

net.netfilter.nf_conntrack_max = 3145728

Emisio guztiak gordetzeko hash taularako kubo kopurua ere handitu behar da (nf_conntrack moduluko aukera bat da): 

options nf_conntrack hashsize=1572864

Manipulazio sinple horien ondoren, guztiz funtzionatzen duen diseinua lortzen da, bezeroen helbide kopuru handi bat kanpoko multzo batean itzul dezakeena. Hala ere, irtenbide honen errendimenduak asko uzten du desiratzeke. GNU/Linux NAT-erako erabiltzeko lehen saiakeretan (2013 inguruan), 7Gbit/s inguruko errendimendua lortu nuen zerbitzari bakoitzeko 0.8Mpps-an (Xeon E5-1650v2). Orduz geroztik, GNU/Linux kernel sareko pilan optimizazio desberdinak egin dira, hardware bereko zerbitzari baten errendimendua ia 18-19 Gbit/s-ra igo da 1.8-1.9 Mpps-tan (gehienezko balioak ziren). , baina zerbitzari batek prozesatutako trafiko-bolumenaren eskaera askoz azkarrago hazi zen. Ondorioz, zerbitzari ezberdinetako karga orekatzeko eskemak garatu ziren, baina horrek guztiak eskaintzen dituen zerbitzuen konfigurazio, mantentze eta kalitatea mantentzeko konplexutasuna areagotu du.

NFTtableak

Gaur egun, softwarearen "poltsak aldatzeko" modan dagoen joera DPDK eta XDP erabiltzea da. Artikulu asko idatzi dira gai honi buruz, hainbat hitzaldi egin dira eta produktu komertzialak agertzen ari dira (adibidez, VasExperts-eko SKAT). Baina telekomunikazio-operadoreen programazio baliabide mugatuak kontuan hartuta, nahiko problematikoa da marko hauetan oinarritutako edozein "produktu" sortzea zure kabuz. Askoz zailagoa izango da etorkizunean horrelako irtenbide bat martxan jartzea; bereziki, diagnostiko tresnak garatu beharko dira. Adibidez, DPDK-rekin tcpdump estandarrak ez du horrela funtzionatuko, eta ez ditu "ikusiko" XDP erabiliz harietara bidalitako paketeak. Erabiltzaile-espaziora paketeak birbidaltzeko teknologia berriei buruzko eztabaida guztien artean, oharkabean pasatu ziren txostenak ΠΈ Artikulua Pablo Neira Ayuso, iptables-en mantentzailea, nftables-en fluxu-deskargaren garapenari buruz. Ikus dezagun hurbilagotik mekanismo hau.

Ideia nagusia da bideratzaileak saio bateko paketeak fluxuaren bi noranzkoetan pasatu bazituen (TCP saioa ESTABLISHED egoerara joan zen), orduan ez dago zertan saio honen ondorengo paketeak suebaki-arau guztietatik pasatzea, izan ere. egiaztapen horiek guztiak paketea bideratzetik aurrera eramango direnean amaituko dira oraindik. Eta ez dugu ibilbide bat hautatu behar - dagoeneko badakigu zein interfazera eta zein ostalarira bidali behar ditugun paketeak saio honetan. Informazio hori gordetzea eta paketeen prozesamenduaren hasierako fasean bideratzeko erabiltzea besterik ez da geratzen. NAT egitean, beharrezkoa da nf_conntrack moduluak itzulitako helbide eta atakeen aldaketei buruzko informazioa ere gordetzea. Bai, noski, kasu honetan hainbat poliziak eta iptables-en beste informazio eta estatistika-arau batzuk funtzionatzeari uzten diote, baina zutik NAT edo, adibidez, muga baten zereginaren esparruan, hori ez da hain garrantzitsua, zerbitzuak zeren eta. gailuetan banatuta daude.

konfigurazioa

Funtzio hau erabiltzeko:

  • Erabili nukleo freskoa. Funtzionalitatea bera 4.16 nukleoan agertu zen arren, denbora luzez oso "gordina" izan zen eta aldian-aldian nukleoaren izua eragiten zuen. Dena egonkortu zen 2019ko abenduan, LTS kernelak 4.19.90 eta 5.4.5 kaleratu zirenean.
  • Berridatzi iptables arauak nftables formatuan nftables-en bertsio berri samarra erabiliz. Zehazki funtzionatzen du 0.9.0 bertsioan

Lehen puntuarekin printzipioz dena argi badago, gauza nagusia muntaian zehar modulua konfigurazioan sartzea ez ahaztea da (CONFIG_NFT_FLOW_OFFLOAD=m), orduan bigarren puntuak azalpena behar du. nftables arauak iptables-en baino guztiz ezberdin deskribatzen dira. Dokumentazioa ia puntu guztiak agerian uzten ditu, bereziak ere badaude bihurgailuak iptables-tik nftables-era arauak. Hori dela eta, NAT eta fluxua deskargatzeko adibide bat baino ez dut emango. Kondaira txiki bat adibidez: , - Hauek dira trafikoa igarotzen den sareko interfazeak; egia esan, bi baino gehiago izan daitezke. , β€” Helbide "zurien" sortaren hasierako eta amaierako helbidea.

NAT konfigurazioa oso erraza da:

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

Fluxua deskargarekin pixka bat konplexuagoa da, baina nahiko ulergarria:

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

Hori da, hain zuzen ere, konfigurazio osoa. Orain TCP/UDP trafiko guztia fastnat taulan eroriko da eta askoz azkarrago prozesatuko da.

Findings

Hau zein β€œaskoz azkarragoa” den argi uzteko, kargaren pantaila-argazkia erantsiko dut bi zerbitzari errealetan, hardware berdinarekin (Xeon E5-1650v2), berdin konfiguratuta, Linux kernel bera erabiliz, baina iptables-en NAT eginez. (NAT4) eta nfttableetan (NAT5).

Bideratze azkarra eta NAT Linux-en

Pantaila-argazkian ez dago segundoko pakete grafikorik, baina zerbitzari hauen karga-profilean paketeen batez besteko tamaina 800 byte ingurukoa da, beraz, balioak 1.5Mpps-ra iristen dira. Ikus dezakezunez, nftables dituen zerbitzariak errendimendu erreserba handia du. Gaur egun, zerbitzari honek 30Gbit/s-ra arte prozesatzen du 3Mpps-tan eta argi eta garbi gai da 40Gbps-ko sare fisikoaren muga betetzeko, CPU baliabideak doan dituen bitartean.

Material hau zerbitzarien errendimendua hobetzen saiatzen diren sare ingeniarientzat erabilgarria izatea espero dut.

Iturria: www.habr.com

Gehitu iruzkin berria