ProHoster > blog > Utawala > Uelekezaji wa haraka na NAT kwenye Linux

Uelekezaji wa haraka na NAT kwenye Linux

Kadiri anwani za IPv4 zinavyopungua, waendeshaji wengi wa mawasiliano ya simu wanakabiliwa na hitaji la kuwapa wateja wao ufikiaji wa mtandao kwa kutumia tafsiri ya anwani. Katika nakala hii nitakuambia jinsi unaweza kupata utendaji wa Daraja la Mtoa huduma wa NAT kwenye seva za bidhaa.

kidogo ya historia

Mada ya uchovu wa nafasi ya anwani ya IPv4 sio mpya tena. Wakati fulani, orodha za kungojea zilionekana katika RIPE, kisha ubadilishanaji uliibuka ambao vitalu vya anwani viliuzwa na mikataba ilihitimishwa ili kuzikodisha. Hatua kwa hatua, waendeshaji wa mawasiliano ya simu walianza kutoa huduma za ufikiaji wa mtandao kwa kutumia anwani na tafsiri ya bandari. Wengine hawakuweza kupata anwani za kutosha kutoa anwani "nyeupe" kwa kila mteja, wakati wengine walianza kuokoa pesa kwa kukataa kununua anwani kwenye soko la sekondari. Wazalishaji wa vifaa vya mtandao waliunga mkono wazo hili, kwa sababu utendakazi huu kwa kawaida huhitaji moduli za nyongeza au leseni. Kwa mfano, katika safu ya Juniper ya vipanga njia vya MX (isipokuwa MX104 na MX204 ya hivi karibuni), unaweza kutekeleza NAPT kwenye kadi tofauti ya huduma ya MS-MIC, Cisco ASR1k inahitaji leseni ya CGN, Cisco ASR9k inahitaji moduli tofauti ya A9K-ISM-100. na leseni ya A9K-CGN -LIC kwake. Kwa ujumla, raha inagharimu pesa nyingi.

IPTables

Kazi ya kutekeleza NAT hauitaji rasilimali maalum za kompyuta; inaweza kutatuliwa na wasindikaji wa kusudi la jumla, ambao wamewekwa, kwa mfano, kwenye kipanga njia chochote cha nyumbani. Kwa ukubwa wa opereta wa mawasiliano ya simu, tatizo hili linaweza kutatuliwa kwa kutumia seva za bidhaa zinazoendesha FreeBSD (ipfw/pf) au GNU/Linux (iptables). Hatutazingatia FreeBSD, kwa sababu ... Niliacha kutumia OS hii muda mrefu uliopita, kwa hivyo tutashikamana na GNU/Linux.

Kuwezesha tafsiri ya anwani si vigumu hata kidogo. Kwanza unahitaji kusajili sheria katika iptables kwenye jedwali la nat:

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

Mfumo wa uendeshaji utapakia moduli ya nf_conntrack, ambayo itafuatilia miunganisho yote ya kazi na kufanya mabadiliko muhimu. Kuna hila kadhaa hapa. Kwanza, kwa kuwa tunazungumza juu ya NAT kwa kiwango cha mwendeshaji wa mawasiliano ya simu, inahitajika kurekebisha muda, kwa sababu kwa maadili chaguo-msingi saizi ya jedwali la utafsiri itakua haraka hadi maadili ya janga. Ifuatayo ni mfano wa mipangilio niliyotumia kwenye seva zangu:

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

Na pili, kwa kuwa saizi chaguo-msingi ya jedwali la tafsiri haijaundwa kufanya kazi chini ya masharti ya mwendeshaji wa mawasiliano ya simu, inahitaji kuongezwa:

net.netfilter.nf_conntrack_max = 3145728

Inahitajika pia kuongeza idadi ya ndoo za jedwali la hashi kuhifadhi matangazo yote (hili ni chaguo katika moduli ya nf_conntrack): 

options nf_conntrack hashsize=1572864

Baada ya ghiliba hizi rahisi, muundo wa kufanya kazi kabisa unapatikana ambao unaweza kutafsiri idadi kubwa ya anwani za mteja kwenye dimbwi la zile za nje. Walakini, utendaji wa suluhisho hili huacha kuhitajika. Katika majaribio yangu ya kwanza ya kutumia GNU/Linux kwa NAT (takriban 2013), niliweza kupata utendaji wa karibu 7Gbit/s kwa 0.8Mpps kwa seva (Xeon E5-1650v2). Tangu wakati huo, uboreshaji nyingi tofauti zimefanywa katika safu ya mtandao ya kernel ya GNU/Linux, utendaji wa seva moja kwenye maunzi sawa umeongezeka hadi karibu 18-19 Gbit/s kwa 1.8-1.9 Mpps (hizi ndizo zilikuwa maadili ya juu) , lakini mahitaji ya kiasi cha trafiki, yaliyochakatwa na seva moja yalikua kwa kasi zaidi. Matokeo yake, mipango ilitengenezwa ili kusawazisha mzigo kwenye seva tofauti, lakini yote haya yaliongeza ugumu wa kuanzisha, kudumisha na kudumisha ubora wa huduma zinazotolewa.

Meza za NF

Siku hizi, mtindo wa mtindo katika "mifuko ya kuhama" ya programu ni matumizi ya DPDK na XDP. Nakala nyingi zimeandikwa juu ya mada hii, hotuba nyingi tofauti zimefanywa, na bidhaa za kibiashara zinaonekana (kwa mfano, SKAT kutoka kwa VasExperts). Lakini kwa kuzingatia rasilimali chache za programu za waendeshaji wa mawasiliano ya simu, ni shida sana kuunda "bidhaa" yoyote kulingana na mifumo hii peke yako. Itakuwa ngumu zaidi kutumia suluhisho kama hilo katika siku zijazo; haswa, zana za utambuzi zitalazimika kutengenezwa. Kwa mfano, tcpdump ya kawaida iliyo na DPDK haitafanya kazi hivyo tu, na "haitaona" pakiti zilizorejeshwa kwa waya kwa kutumia XDP. Katikati ya mazungumzo yote juu ya teknolojia mpya za usambazaji wa pakiti kwa nafasi ya watumiaji, hazikutambuliwa. ripoti ΠΈ nakala Pablo Neira Ayuso, mtunzaji wa iptables, kuhusu ukuzaji wa upakiaji wa mtiririko katika nftables. Hebu tuangalie kwa karibu utaratibu huu.

Wazo kuu ni kwamba ikiwa kipanga njia kilipitisha pakiti kutoka kwa kikao kimoja katika pande zote mbili za mtiririko (kikao cha TCP kiliingia katika hali ILIYOSIMULIWA), basi hakuna haja ya kupitisha pakiti zinazofuata za kikao hiki kupitia sheria zote za firewall, kwa sababu. ukaguzi huu wote bado utaisha na pakiti kuhamishiwa zaidi kwenye uelekezaji. Na kwa kweli hatuhitaji kuchagua njia - tayari tunajua ni kiolesura kipi na kwa mwenyeji gani tunahitaji kutuma pakiti ndani ya kipindi hiki. Kilichobaki ni kuhifadhi habari hii na kuitumia kwa uelekezaji katika hatua ya awali ya usindikaji wa pakiti. Wakati wa kutekeleza NAT, inahitajika kuhifadhi habari zaidi kuhusu mabadiliko katika anwani na bandari zilizotafsiriwa na moduli ya nf_conntrack. Ndiyo, bila shaka, katika kesi hii polisi mbalimbali na taarifa nyingine na sheria za takwimu katika iptables kuacha kufanya kazi, lakini ndani ya mfumo wa kazi ya kusimama tofauti NAT au, kwa mfano, mpaka, hii si muhimu sana, kwa sababu huduma. husambazwa katika vifaa vyote.

Usanidi

Ili kutumia kipengele hiki tunahitaji:

  • Tumia punje safi. Licha ya ukweli kwamba utendaji yenyewe ulionekana kwenye kernel 4.16, kwa muda mrefu ilikuwa "mbichi" sana na mara kwa mara ilisababisha hofu ya kernel. Kila kitu kilitulia karibu Desemba 2019, wakati LTS kernels 4.19.90 na 5.4.5 zilitolewa.
  • Andika upya sheria za iptables katika umbizo la nftables kwa kutumia toleo la hivi majuzi la nfttables. Inafanya kazi haswa katika toleo la 0.9.0

Ikiwa kila kitu kwa kanuni ni wazi na hatua ya kwanza, jambo kuu si kusahau kuingiza moduli katika usanidi wakati wa kusanyiko (CONFIG_NFT_FLOW_OFFLOAD=m), basi hatua ya pili inahitaji maelezo. sheria za nftables zinaelezewa tofauti kabisa kuliko katika iptables. Nyaraka inaonyesha karibu pointi zote, pia kuna maalum waongofu sheria kutoka iptables hadi nfttables. Kwa hivyo, nitatoa tu mfano wa kusanidi NAT na upakiaji wa mtiririko. Hadithi ndogo kwa mfano: , - hizi ni miingiliano ya mtandao ambayo trafiki hupita; kwa ukweli kunaweza kuwa zaidi ya mbili kati yao. , β€” anwani ya kuanzia na ya mwisho ya anuwai ya anwani "nyeupe".

Usanidi wa NAT ni rahisi sana:

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

Kwa upakiaji wa mtiririko ni ngumu zaidi, lakini inaeleweka kabisa:

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

Hiyo, kwa kweli, ni usanidi wote. Sasa trafiki yote ya TCP/UDP itaangukia kwenye jedwali la fastnat na kuchakatwa haraka zaidi.

Matokeo

Ili kuifanya iwe wazi jinsi hii ni "haraka zaidi", nitaambatisha picha ya skrini ya mzigo kwenye seva mbili halisi, na vifaa sawa (Xeon E5-1650v2), iliyosanidiwa sawa, kwa kutumia kernel sawa ya Linux, lakini nikifanya NAT katika iptables. (NAT4) na katika nfttables (NAT5).

Uelekezaji wa haraka na NAT kwenye Linux

Hakuna grafu ya pakiti kwa sekunde katika picha ya skrini, lakini katika wasifu wa upakiaji wa seva hizi wastani wa ukubwa wa pakiti ni karibu baiti 800, kwa hivyo thamani hufikia hadi 1.5Mpps. Kama unaweza kuona, seva iliyo na nftables ina hifadhi kubwa ya utendaji. Hivi sasa, seva hii huchakata hadi 30Gbit/s kwa 3Mpps na kwa wazi ina uwezo wa kufikia kikomo cha mtandao halisi cha 40Gbps, huku ikiwa na rasilimali za bure za CPU.

Natumai nyenzo hii itakuwa muhimu kwa wahandisi wa mtandao wanaojaribu kuboresha utendaji wa seva zao.

Chanzo: mapenzi.com

Kuongeza maoni