ProHoster > Blog > Stjórnsýsla > Hröð leið og NAT í Linux

Hröð leið og NAT í Linux

Þar sem IPv4 vistföng tæmast standa margir fjarskiptafyrirtæki frammi fyrir því að þurfa að veita viðskiptavinum sínum netaðgang með því að nota heimilisfangaþýðingu. Í þessari grein mun ég segja þér hvernig þú getur fengið NAT afköst Carrier Grade á vöruþjónum.

Smá saga

Þema IPv4 vistfangarýmisins er ekki lengur nýtt. Á einhverjum tímapunkti birtust biðlistar í RIPE, síðan komu upp kauphallir þar sem verslað var með heimilisföng og samningar voru gerðir um leigu á þeim. Smám saman fóru fjarskiptafyrirtæki að veita netaðgangsþjónustu með því að nota heimilisfang og hafnarþýðingu. Sumum tókst ekki að fá nógu mörg heimilisföng til að gefa út „hvítt“ heimilisfang til hvers áskrifanda á meðan aðrir fóru að spara peninga með því að neita að kaupa heimilisföng á eftirmarkaði. Framleiðendur netbúnaðar studdu þessa hugmynd vegna þess þessi virkni krefst venjulega viðbótarframlengingareininga eða leyfis. Til dæmis, í línu Juniper af MX beinum (fyrir utan nýjustu MX104 og MX204), geturðu framkvæmt NAPT á sérstöku MS-MIC þjónustukorti, Cisco ASR1k þarf CGN leyfi, Cisco ASR9k þarf sérstaka A9K-ISM-100 mát og A9K-CGN leyfi -LIC til hans. Almennt séð kostar ánægjan mikla peninga.

IPTables

Verkefnið við að framkvæma NAT krefst ekki sérhæfðra tölvuauðlinda; það er hægt að leysa með almennum örgjörvum, sem eru settir upp, til dæmis í hvaða heimabeini sem er. Á mælikvarða fjarskiptafyrirtækis er hægt að leysa þetta vandamál með því að nota vöruþjóna sem keyra FreeBSD (ipfw/pf) eða GNU/Linux (iptables). Við munum ekki íhuga FreeBSD, vegna þess að... Ég hætti að nota þetta stýrikerfi fyrir nokkuð löngu síðan, svo við höldum okkur við GNU/Linux.

Það er alls ekki erfitt að virkja heimilisfangaþýðingu. Fyrst þarftu að skrá reglu í iptables í nat töflunni:

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

Stýrikerfið mun hlaða nf_conntrack einingunni, sem mun fylgjast með öllum virkum tengingum og framkvæma nauðsynlegar umbreytingar. Það eru nokkrir fínleikar hér. Í fyrsta lagi, þar sem við erum að tala um NAT á mælikvarða fjarskiptafyrirtækis, er nauðsynlegt að stilla tímamörkin, vegna þess að með sjálfgefnum gildum mun stærð þýðingartöflunnar fljótt vaxa í skelfileg gildi. Hér að neðan er dæmi um stillingar sem ég notaði á netþjónum mínum:

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

Og í öðru lagi, þar sem sjálfgefin stærð þýðingartöflunnar er ekki hönnuð til að virka undir skilyrðum fjarskiptafyrirtækis, þarf að auka hana:

net.netfilter.nf_conntrack_max = 3145728

Það er líka nauðsynlegt að auka fjölda fötu fyrir kjötkássatöfluna sem geymir allar útsendingar (þetta er valkostur í nf_conntrack einingunni): 

options nf_conntrack hashsize=1572864

Eftir þessar einföldu meðhöndlun fæst fullkomlega vinnandi hönnun sem getur þýtt fjölda netföng viðskiptavina yfir í hóp af ytri. Hins vegar skilur árangur þessarar lausnar mikið eftir. Í fyrstu tilraunum mínum til að nota GNU/Linux fyrir NAT (um það bil 2013), tókst mér að ná frammistöðu um 7Gbit/s á 0.8Mpps á hvern netþjón (Xeon E5-1650v2). Frá þeim tíma hafa margar mismunandi fínstillingar verið gerðar í GNU/Linux kjarna netstaflanum, afköst eins netþjóns á sama vélbúnaði hefur aukist í næstum 18-19 Gbit/s við 1.8-1.9 Mpps (þetta voru hámarksgildin) , en eftirspurn eftir umferðarmagni, unnin af einum netþjóni, jókst mun hraðar. Í kjölfarið voru þróuð kerfi til að jafna álag á mismunandi netþjóna, en allt þetta jók flókið við að setja upp, viðhalda og viðhalda gæðum veittrar þjónustu.

NFT töflur

Nú á dögum er tíska stefna í hugbúnaði „að breyta töskum“ að nota DPDK og XDP. Margar greinar hafa verið skrifaðar um þetta efni, margar mismunandi ræður hafa verið fluttar og auglýsingavörur eru að birtast (td SKAT frá VasExperts). En miðað við takmarkað forritunarúrræði fjarskiptafyrirtækja, þá er það frekar erfitt að búa til hvaða „vöru“ sem er byggð á þessum ramma á eigin spýtur. Mun erfiðara verður að reka slíka lausn í framtíðinni, einkum þarf að þróa greiningartæki. Til dæmis, staðall tcpdump með DPDK mun ekki virka bara svona, og það mun ekki „sjá“ pakka sem eru sendir til baka til víranna með XDP. Innan um allt tal um nýja tækni til að senda pakkaframsendingu til notendarýmis fóru þeir óséðir skýrslur и Grein Pablo Neira Ayuso, umsjónarmaður iptables, um þróun flæðislosunar í nftables. Við skulum skoða þetta kerfi nánar.

Meginhugmyndin er sú að ef leiðin sendi pakka frá einni lotu í báðar áttir flæðisins (TCP lotan fór í STAÐLAÐ ástand), þá er engin þörf á að senda síðari pakka af þessari lotu í gegnum allar eldveggsreglur, vegna þess að allar þessar athuganir munu samt enda með því að pakkinn er fluttur lengra á leiðina. Og við þurfum í raun ekki að velja leið - við vitum nú þegar í hvaða viðmót og til hvaða gestgjafa við þurfum að senda pakka innan þessa lotu. Allt sem er eftir er að geyma þessar upplýsingar og nota þær til leiðar á frumstigi pakkavinnslu. Þegar NAT er framkvæmt er nauðsynlegt að til viðbótar geyma upplýsingar um breytingar á vistföngum og höfnum sem þýddar eru af nf_conntrack einingunni. Já, auðvitað, í þessu tilfelli hætta ýmsir lögreglumenn og aðrar upplýsingar og tölfræðireglur í iptables að virka, en innan ramma verkefnisins um sérstakt standandi NAT eða til dæmis landamæri, er þetta ekki svo mikilvægt, vegna þess að þjónustan er dreift yfir tæki.

Stillingar

Til að nota þessa aðgerð þurfum við:

  • Notaðu ferskan kjarna. Þrátt fyrir þá staðreynd að virknin sjálf birtist í kjarna 4.16, var hún í nokkuð langan tíma mjög „hrá“ og olli reglulega kjarna læti. Allt varð stöðugt í kringum desember 2019, þegar LTS kjarna 4.19.90 og 5.4.5 komu út.
  • Endurskrifaðu iptables reglur á nftables sniði með því að nota nokkuð nýlega útgáfu af nftables. Virkar nákvæmlega í útgáfu 0.9.0

Ef allt er í grundvallaratriðum skýrt með fyrsta lið, aðalatriðið er ekki að gleyma að taka eininguna með í uppsetningunni meðan á samsetningu stendur (CONFIG_NFT_FLOW_OFFLOAD=m), þá þarf seinni liðurinn skýringa. nftables reglum er lýst allt öðruvísi en í iptables. Skjöl sýnir næstum öll atriði, það eru líka sérstök breytir reglur frá iptables til nftables. Þess vegna mun ég aðeins gefa dæmi um uppsetningu NAT og flæðislosunar. Lítil goðsögn til dæmis: , - þetta eru netviðmótin sem umferð fer í gegnum; í raun geta þau verið fleiri en tvö. , — upphafs- og lokaföng sviðs „hvítra“ netfönga.

NAT uppsetning er mjög einföld:

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

Með flæðislosun er það aðeins flóknara, en alveg skiljanlegt:

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

Það er í rauninni allt skipulagið. Nú mun öll TCP/UDP umferð falla inn í fastnat töfluna og verða unnin mun hraðar.

Niðurstöður

Til að gera það ljóst hversu „miklu hraðar“ þetta er, mun ég hengja við skjáskot af álaginu á tveimur raunverulegum netþjónum, með sama vélbúnaði (Xeon E5-1650v2), eins stilltur, með sama Linux kjarna, en framkvæma NAT í iptables (NAT4) og í nftables (NAT5).

Hröð leið og NAT í Linux

Það er ekkert graf af pökkum á sekúndu í skjámyndinni, en í hleðslusniði þessara netþjóna er meðalpakkastærðin um 800 bæti, þannig að gildin ná allt að 1.5Mpps. Eins og þú sérð hefur netþjónninn með nftables gríðarlegan frammistöðuvara. Eins og er, vinnur þessi netþjónn allt að 30Gbit/s við 3Mpps og er greinilega fær um að uppfylla líkamlega nettakmörkunina 40Gbps, á sama tíma og hann hefur ókeypis CPU auðlindir.

Ég vona að þetta efni muni nýtast netverkfræðingum sem reyna að bæta afköst netþjóna sinna.

Heimild: www.habr.com

Bæta við athugasemd