Rêvekirina bilez û NAT di Linux de

Ji ber ku navnîşanên IPv4 qels dibin, gelek operatorên telekomê bi hewcedariyê re rû bi rû dimînin ku bi karanîna wergera navnîşan re gihîştina torê ji xerîdarên xwe re peyda bikin. Di vê gotarê de ez ê ji we re vebêjim ka hûn çawa dikarin performansa NAT-a Carrier Grade li ser serverên hilberê bistînin.

Hinek dîrok

Mijara westandina cîhê navnîşana IPv4 êdî ne nû ye. Di hin xalan de, lîsteyên bendewariyê di RIPE de xuya bûn, dûv re danûstendin derketin holê ku li ser wan blokên navnîşanan bazirganî kirin û ji bo kirêkirina wan danûstandin hatin kirin. Hêdî hêdî, operatorên telekomê dest bi peydakirina karûbarên gihîştina Înternetê bi karanîna wergera navnîşan û portê kirin. Hinan nekarîn têra navnîşanan bidest bixin da ku navnîşek "spî" ji her aboneyê re derxînin, hinên din jî bi redkirina kirîna navnîşanan li ser bazara duyemîn dest bi teserûfa drav kirin. Hilberînerên amûrên torê piştgirî da vê ramanê, ji ber ev fonksiyon bi gelemperî modulên dirêjkirinê an destûrnameyên zêde hewce dike. Mînakî, di rêza routerên MX-ê yên Juniper de (ji bilî MX104 û MX204-a herî dawî), hûn dikarin NAPT-ê li ser qerta karûbarê MS-MIC-ê ya cihêreng bicîh bînin, Cisco ASR1k destûrnameyek CGN hewce dike, Cisco ASR9k modulek A9K-ISM-100 veqetandî hewce dike. û lîsansek A9K-CGN -LIC ji wî re. Bi gelemperî, kêfê gelek drav dike.

IPTables

Karê pêkanîna NAT-ê hewcedariya çavkaniyên komputerê yên pispor nake; ew dikare ji hêla pêvajoyên gelemperî-armanc ve, yên ku, mînakî, di her routerê malê de têne saz kirin, were çareser kirin. Li ser pîvana operatorek telekomê, ev pirsgirêk dikare bi karanîna pêşkêşkerên hilberê yên ku FreeBSD (ipfw/pf) an GNU/Linux (iptables) dimeşînin çareser bibe. Em ê FreeBSD nehesibînin, ji ber ... Min demek dirêj berê dev ji karanîna vê OS-ê berda, ji ber vê yekê em ê li ser GNU/Linux bisekinin.

Çalakkirina wergera navnîşanê qet ne dijwar e. Pêşî hûn hewce ne ku di tabloya nat de qaîdeyek di iptables de tomar bikin:

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

Pergala xebitandinê dê modula nf_conntrack bar bike, ku dê hemî girêdanên çalak bişopîne û veguheztinên pêwîst pêk bîne. Li vir çend hûrgulî hene. Pêşîn, ji ber ku em li ser pîvana operatorek telekomê li ser NAT-ê diaxivin, pêdivî ye ku meriv deman biguhezîne, ji ber ku bi nirxên xwerû re mezinahiya tabloya wergerê dê zû bigihîje nirxên felaketê. Li jêr mînakek mîhengên ku min li ser serverên xwe bikar anîn hene:

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

Ya duyemîn jî, ji ber ku mezinahiya xwerû ya tabloya wergerandinê ne hatî sêwirandin ku di bin şert û mercên operatorek telekomê de bixebite, pêdivî ye ku ew were zêde kirin:

net.netfilter.nf_conntrack_max = 3145728

Di heman demê de pêdivî ye ku ji bo tabloya hash-ê ku hemî weşanan hilîne hejmara kepçeyan zêde bike (ev vebijarkek di modula nf_conntrack de ye):

options nf_conntrack hashsize=1572864

Piştî van manîpulasyonên hêsan, sêwiranek bi tevahî xebitîn tê bidestxistin ku dikare hejmareke mezin ji navnîşanên xerîdar wergerîne hewzek derveyî. Lêbelê, performansa vê çareseriyê pir xwestek dihêle. Di hewildanên min ên yekem de ji bo karanîna GNU/Linux-ê ji bo NAT (dora 2013), min karîbû performansa li dora 7Gbit/s bi 0.8Mpps per server (Xeon E5-1650v2) bistînim. Ji wê demê û vir ve, di stûna tora kernelê ya GNU/Linux de gelek xweşbîniyên cûda hatine çêkirin, performansa serverek li ser heman hardware hema hema 18-19 Gbit/s li 1.8-1.9 Mpps zêde bûye (ev nirxên herî zêde bûn) , lê daxwaza qebareya trafîkê, ku ji hêla yek serverê ve hatî hilberandin, pir zûtir mezin bû. Wekî encamek, pîlan hatin pêşve xistin da ku barkirina li ser serverên cihêreng hevseng bikin, lê ev hemî tevliheviya sazkirin, parastin û domandina kalîteya karûbarên pêşkêşkirî zêde kir.

NTFables

Naha, meylek moda di nermalava "veguheztina çenteyên" de karanîna DPDK û XDP ye. Li ser vê mijarê gelek gotar hatine nivîsandin, gelek axaftinên cihêreng hatine kirin, û hilberên bazirganî xuya dibin (mînak, SKAT ji VasExperts). Lê ji ber çavkaniyên bernamesaz ên tixûbdar ên operatorên telekomê, pir pirsgirêk e ku meriv "hilberek" li ser bingeha van çarçoweyan bi tena serê xwe biafirîne. Dê di pêşerojê de xebitandina çareseriyek wusa pir dijwartir be; bi taybetî, pêdivî ye ku amûrên tespîtkirinê werin pêşve xistin. Mînakî, tcpdump standard bi DPDK-ê re dê bi vî rengî nexebite, û ew ê pakêtên ku bi karanîna XDP-ê vedigerin têlên têne şandin "nebîne". Di nav hemî axaftinên li ser teknolojiyên nû de ji bo derxistina paketan berbi cîhê bikarhêner, ew nedîtî çûn. rapor dike и gotar Pablo Neira Ayuso, parêzgerê iptables, di derbarê pêşkeftina barkirina herikînê de di nftables de. Werin em ji nêz ve li vê mekanîzmayê binêrin.

Fikra sereke ev e ku ger router ji yek danişînê pakêtan di her du aliyên herikînê de derbas bike (danişîna TCP çû rewşa ESTABLISHED), wê hingê ne hewce ye ku pakêtên paşîn ên vê danişînê di hemî qaîdeyên dîwarê agir de derbas bikin, ji ber ku Hemî van kontrolan dê hîn jî bi pakêta ku bêtir ber bi rêvekirinê ve were veguheztin biqede. Û em bi rastî ne hewce ne ku rêyek hilbijêrin - em jixwe dizanin ku em hewce ne ku di vê danişînê de ji kîjan navbeynê û ji kîjan mêvandar re pakêtan bişînin. Tiştê ku dimîne ev e ku meriv vê agahiyê hilîne û wê ji bo rêvekirinê di qonaxek destpêkê ya hilberandina pakêtê de bikar bîne. Dema ku NAT-ê pêk tîne, pêdivî ye ku ji hêla modula nf_conntrack ve hatî wergerandin agahdariya di derbarê guhertinên navnîşan û portan de jî hilînin. Erê, bê guman, di vê rewşê de polîsên cihêreng û agahdarî û rêgezên statîstîkî yên din ên di iptables de dixebitin rawestin, lê di çarçoweya peywira NAT-ek cihêreng an, mînakî, sînorek, ev ne ew qas girîng e, ji ber ku karûbar li ser cîhazan têne belav kirin.

Guhertin

Ji bo ku em vê fonksiyonê bikar bînin hewce ne:

  • Kernelek nû bikar bînin. Tevî vê rastiyê ku fonksiyon bi xwe di kernel 4.16 de xuya bû, ji bo demek dirêj ew pir "xav" bû û bi rêkûpêk bû sedema panîkê kernel. Her tişt li dora Kanûna 2019-an aram bû, dema ku kernelên LTS 4.19.90 û 5.4.5 hatin berdan.
  • Bi karanîna guhertoyek pir nû ya nftables qaîdeyên iptables di forma nftables de ji nû ve binivîsin. Tam di guhertoya 0.9.0 de dixebite

Ger her tişt di prensîbê de bi xala yekem re zelal e, ya sereke ev e ku meriv ji bîr neke ku di dema berhevkirinê de modulê di veavakirinê de bihewîne (CONFIG_NFT_FLOW_OFFLOAD=m), wê hingê xala duyemîn ravekirinê hewce dike. qaîdeyên nftables ji yên iptables bi tevahî cûda têne diyar kirin. Dokumentasyonê hema hema hemû xalan eşkere dike, taybet jî hene converters qaîdeyên ji iptables heta nftables. Ji ber vê yekê, ez ê tenê mînakek sazkirina NAT û barkirina barkirinê bidim. Mînak efsaneyek piçûk: , - ev navgînên torê ne ku seyrûsefer di nav wan re derbas dibe; di rastiyê de dikare ji duyan zêdetir hebin. , - Navnîşana destpêk û dawiya rêza navnîşanên "spî".

Veavakirina NAT pir hêsan e:

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

Bi barkirina herikînê re ew hinekî tevlihevtir e, lê pir tê fêm kirin:

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

Ew, bi rastî, tevahiya sazkirinê ye. Naha hemî seyrûsefera TCP/UDP dê têkeve tabloya fastnat û pir zûtir were pêvajoyê.

Encam

Ji bo ku ez zelal bikim ka ev çiqas "gelek zûtir" e, ez ê dîmenek barkirinê li ser du serverên rastîn, bi heman hardware (Xeon E5-1650v2) ve girêbidim, bi heman rengî hatî mîheng kirin, bi karanîna heman kernel Linux, lê NAT-ê di iptables de pêk tîne. (NAT4) û di nftables (NAT5).

Rêvekirina bilez û NAT di Linux de

Di dîmenderê de grafika pakêtan di çirkeyê de tune, lê di profîla barkirina van serveran de mezinahiya navînî ya pakêtê li dora 800 byte ye, ji ber vê yekê nirx digihîje 1.5Mpps. Wekî ku hûn dikarin bibînin, servera bi nftables xwedan rezervek performansa mezin e. Heya nuha, ev server heya 30 Gbit / s li 3Mpps pêvajoyê dike û eşkere ye ku di heman demê de xwedî çavkaniyên CPU-ya belaş e ku bi sînorkirina torê ya fizîkî ya 40Gbps re peyda bike.

Ez hêvî dikim ku ev materyal dê ji endezyarên torê re kêrhatî be ku hewl didin ku performansa serverên xwe baştir bikin.

Source: www.habr.com

Add a comment