Nopea reititys ja NAT Linuxissa

IPv4-osoitteiden ehtyessä monet teleoperaattorit joutuvat tarjoamaan asiakkailleen verkkoyhteyden osoitteenmuunnoksen avulla. Tässä artikkelissa kerron sinulle, kuinka voit saada Carrier Grade NAT -suorituskyvyn hyödykepalvelimilla.

Vähän historiaa

IPv4-osoitetilan tyhjentäminen ei ole enää uusi aihe. Jossain vaiheessa RIPEen ilmestyi jonotuslistoja, sitten syntyi pörssit, joissa käytiin kauppaa osoitelohkoilla ja solmittiin sopimuksia niiden vuokraamisesta. Vähitellen teleoperaattorit alkoivat tarjota Internet-yhteyspalveluita osoite- ja porttikäännösten avulla. Jotkut eivät onnistuneet saamaan tarpeeksi osoitteita antaakseen "valkoisen" osoitteen jokaiselle tilaajalle, kun taas toiset alkoivat säästää rahaa kieltäytymällä ostamasta osoitteita jälkimarkkinoilta. Verkkolaitteiden valmistajat tukivat tätä ajatusta, koska Tämä toiminto vaatii yleensä lisälaajennusmoduuleja tai -lisenssejä. Esimerkiksi Juniperin MX-reitittimien sarjassa (paitsi uusimmat MX104 ja MX204) voit suorittaa NAPT:n erillisellä MS-MIC-palvelukortilla, Cisco ASR1k vaatii CGN-lisenssin, Cisco ASR9k vaatii erillisen A9K-ISM-100-moduulin. ja A9K-CGN-lisenssi -LIC hänelle. Yleensä ilo maksaa paljon rahaa.

iptables

NAT:n suorittaminen ei vaadi erityisiä laskentaresursseja, se voidaan ratkaista yleiskäyttöisillä prosessoreilla, jotka asennetaan esimerkiksi mihin tahansa kotireitittimeen. Teleoperaattorin mittakaavassa tämä ongelma voidaan ratkaista käyttämällä hyödykkeitä, joissa on FreeBSD (ipfw/pf) tai GNU/Linux (iptables). Emme harkitse FreeBSD:tä, koska... Lopetin tämän käyttöjärjestelmän käytön jo kauan sitten, joten pysymme GNU/Linuxissa.

Osoitteen kääntäminen ei ole ollenkaan vaikeaa. Ensin sinun on rekisteröitävä sääntö iptablesissa nat-taulukossa:

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

Käyttöjärjestelmä lataa nf_conntrack-moduulin, joka valvoo kaikkia aktiivisia yhteyksiä ja suorittaa tarvittavat muunnokset. Tässä on useita hienouksia. Ensinnäkin, koska puhumme NAT:sta teleoperaattorin mittakaavassa, on tarpeen säätää aikakatkaisuja, koska oletusarvoilla käännöstaulukon koko kasvaa nopeasti katastrofaalisiin arvoihin. Alla on esimerkki asetuksista, joita käytin palvelimillani:

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

Ja toiseksi, koska käännöstaulukon oletuskokoa ei ole suunniteltu toimimaan teleoperaattorin olosuhteissa, sitä on lisättävä:

net.netfilter.nf_conntrack_max = 3145728

On myös tarpeen lisätä kaikki lähetykset tallentavan hash-taulukon segmenttien määrää (tämä on vaihtoehto nf_conntrack-moduulissa):

options nf_conntrack hashsize=1572864

Näiden yksinkertaisten manipulointien jälkeen saadaan täysin toimiva malli, joka voi muuntaa suuren määrän asiakasosoitteita joukkoon ulkoisia osoitteita. Tämän ratkaisun suorituskyky jättää kuitenkin paljon toivomisen varaa. Ensimmäisissä yrityksissäni käyttää GNU/Linuxia NAT:lle (noin 2013) pystyin saavuttamaan noin 7 Gbit/s nopeudella 0.8 Mpps per palvelin (Xeon E5-1650v2). Siitä lähtien GNU/Linux-ytimen verkkopinoon on tehty monia erilaisia ​​optimointeja, yhden palvelimen suorituskyky samalla laitteistolla on noussut lähes 18-19 Gbit/s nopeudella 1.8-1.9 Mpps (nämä olivat maksimiarvot) , mutta yhden palvelimen käsittelemän liikennemäärän kysyntä kasvoi paljon nopeammin. Tämän seurauksena kehitettiin järjestelmiä eri palvelimien kuormituksen tasapainottamiseksi, mutta kaikki tämä lisäsi tarjottujen palvelujen määrittämisen, ylläpidon ja laadun ylläpitämisen monimutkaisuutta.

NFT-taulukot

Nykyään muodikas trendi ohjelmistojen "vaihtolaukuissa" on DPDK:n ja XDP:n käyttö. Aiheesta on kirjoitettu paljon artikkeleita, monia erilaisia ​​puheenvuoroja on pidetty ja kaupallisia tuotteita ilmestyy (esim. VasExpertsin SKAT). Mutta kun otetaan huomioon teleoperaattoreiden rajalliset ohjelmointiresurssit, on melko ongelmallista luoda mitään "tuotetta" näiden kehysten pohjalta yksin. Tällaisen ratkaisun käyttö tulee olemaan tulevaisuudessa paljon vaikeampaa, erityisesti diagnostisia työkaluja on kehitettävä. Esimerkiksi tavallinen tcpdump DPDK:n kanssa ei toimi samalla tavalla, eikä se "näe" paketteja, jotka lähetetään takaisin johtoihin XDP:n avulla. Keskellä kaikkea puhetta uusista teknologioista pakettien edelleenlähettämiseksi käyttäjätilaan, ne jäivät huomaamatta raportteja и Artikkeli Pablo Neira Ayuso, iptables-ylläpitäjä, kertoo virtauksen purkamisen kehittämisestä nftablesissa. Tarkastellaanpa tätä mekanismia tarkemmin.

Pääajatuksena on, että jos reititin välitti paketteja yhdestä istunnosta molempiin kulkusuuntaan (TCP-istunto meni ESTABLISHED-tilaan), tämän istunnon myöhempiä paketteja ei tarvitse kuljettaa kaikkien palomuurisääntöjen läpi, koska kaikki nämä tarkistukset päättyvät silti siihen, että paketti siirretään edelleen reitittimeen. Ja meidän ei itse asiassa tarvitse valita reittiä - tiedämme jo, mihin käyttöliittymään ja mille isännälle meidän on lähetettävä paketteja tämän istunnon aikana. Jäljelle jää vain tallentaa nämä tiedot ja käyttää niitä reitittämiseen pakettien käsittelyn varhaisessa vaiheessa. NAT:ia suoritettaessa on lisäksi tarpeen tallentaa tietoja nf_conntrack-moduulin kääntämistä osoitteiden ja porttien muutoksista. Kyllä, tietysti tässä tapauksessa eri poliisit ja muut tiedot ja tilastosäännöt iptablesissa lakkaavat toimimasta, mutta erillisen pysyvän NATin tai esimerkiksi rajan tehtävän puitteissa tämä ei ole niin tärkeää, koska palvelut jaetaan laitteille.

kokoonpano

Tämän toiminnon käyttämiseksi tarvitsemme:

• Käytä tuoretta ydintä. Huolimatta siitä, että itse toiminnallisuus ilmestyi ytimeen 4.16, se oli melko pitkään erittäin "raaka" ja aiheutti säännöllisesti ytimen paniikkia. Kaikki vakiintui joulukuussa 2019, kun LTS-ytimet 4.19.90 ja 5.4.5 julkaistiin.
• Kirjoita iptables-säännöt uudelleen nftables-muodossa käyttämällä melko tuoretta nftables-versiota. Toimii täsmälleen versiossa 0.9.0

Jos periaatteessa kaikki on selvää ensimmäisestä kohdasta, tärkeintä ei ole unohtaa sisällyttää moduulia kokoonpanoon kokoonpanon aikana (CONFIG_NFT_FLOW_OFFLOAD=m), niin toinen kohta vaatii selitystä. nftables-säännöt on kuvattu täysin eri tavalla kuin iptablesissa. Asiakirjat paljastaa lähes kaikki kohdat, on myös erityisiä muuntimet säännöt iptablesista nftablesiin. Siksi annan vain esimerkin NAT:n asettamisesta ja virtauksen purkamisesta. Pieni legenda esimerkiksi: , - nämä ovat verkkorajapintoja, joiden kautta liikenne kulkee, todellisuudessa niitä voi olla enemmän kuin kaksi. , — ”valkoisten” osoitealueen aloitus- ja loppuosoite.

NAT-määritys on hyvin yksinkertainen:

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

Virtauksen purkamisen kanssa se on hieman monimutkaisempi, mutta täysin ymmärrettävä:

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

Se on itse asiassa koko kokoonpano. Nyt kaikki TCP/UDP-liikenne putoaa fastnat-taulukkoon ja käsitellään paljon nopeammin.

Tulokset

Tehdäkseni selväksi, kuinka "paljon nopeampi" tämä on, liitän mukaan kuvakaappauksen kahdesta todellisesta palvelimesta, joissa on sama laitteisto (Xeon E5-1650v2), identtisesti konfiguroitu ja jotka käyttävät samaa Linux-ydintä, mutta suorittavat NAT:n iptablesissa. (NAT4) ja nftablesissa (NAT5).

Kuvakaappauksessa ei ole kaaviota paketeista sekunnissa, mutta näiden palvelimien kuormitusprofiilissa keskimääräinen pakettikoko on noin 800 tavua, joten arvot yltävät jopa 1.5 Mpps:iin. Kuten näet, nftables-palvelimella on valtava suorituskykyreservi. Tällä hetkellä tämä palvelin käsittelee jopa 30 Gbit/s nopeudella 3Mpps ja pystyy selvästi täyttämään fyysisen verkon rajoituksen 40 Gbps, samalla kun sillä on ilmaisia ​​prosessoriresursseja.

Toivon, että tästä materiaalista on hyötyä verkkoinsinööreille, jotka yrittävät parantaa palvelimiensa suorituskykyä.

Lähde: will.com