Llwybro cyflym a NAT yn Linux

Wrth i gyfeiriadau IPv4 ddisbyddu, mae llawer o weithredwyr telathrebu yn wynebu'r angen i ddarparu mynediad i'r rhwydwaith i'w cleientiaid gan ddefnyddio cyfieithu cyfeiriadau. Yn yr erthygl hon byddaf yn dweud wrthych sut y gallwch gael perfformiad Carrier Grade NAT ar weinyddion nwyddau.

Tipyn o hanes

Nid yw pwnc blinder gofod cyfeiriad IPv4 yn newydd bellach. Ar ryw adeg, ymddangosodd rhestrau aros yn RIPE, yna daeth cyfnewidfeydd i'r amlwg lle roedd blociau o gyfeiriadau yn cael eu masnachu a daethpwyd i gytundeb i'w prydlesu. Yn raddol, dechreuodd gweithredwyr telathrebu ddarparu gwasanaethau mynediad i'r Rhyngrwyd gan ddefnyddio cyfieithu cyfeiriadau a phorthladdoedd. Ni lwyddodd rhai i gael digon o gyfeiriadau i roi cyfeiriad “gwyn” i bob tanysgrifiwr, tra dechreuodd eraill arbed arian trwy wrthod prynu cyfeiriadau ar y farchnad eilaidd. Cefnogodd cynhyrchwyr offer rhwydwaith y syniad hwn, oherwydd mae'r swyddogaeth hon fel arfer yn gofyn am fodiwlau neu drwyddedau estyniad ychwanegol. Er enghraifft, yn llinell Juniper o lwybryddion MX (ac eithrio'r MX104 a MX204 diweddaraf), gallwch berfformio NAPT ar gerdyn gwasanaeth MS-MIC ar wahân, mae Cisco ASR1k angen trwydded CGN, mae Cisco ASR9k angen modiwl A9K-ISM-100 ar wahân a thrwydded A9K-CGN -LIC iddo. Yn gyffredinol, mae'r pleser yn costio llawer o arian.

IPTables

Nid yw'r dasg o berfformio NAT yn gofyn am adnoddau cyfrifiadurol arbenigol; gellir ei ddatrys gan broseswyr pwrpas cyffredinol, sy'n cael eu gosod, er enghraifft, mewn unrhyw lwybrydd cartref. Ar raddfa gweithredwr telathrebu, gellir datrys y broblem hon gan ddefnyddio gweinyddion nwyddau sy'n rhedeg FreeBSD (ipfw/pf) neu GNU/Linux (iptables). Ni fyddwn yn ystyried FreeBSD, oherwydd... Rhoddais y gorau i ddefnyddio'r OS hwn gryn amser yn ôl, felly byddwn yn cadw at GNU/Linux.

Nid yw galluogi cyfieithu cyfeiriadau yn anodd o gwbl. Yn gyntaf mae angen i chi gofrestru rheol mewn iptables yn y tabl nat:

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

Bydd y system weithredu yn llwytho'r modiwl nf_conntrack, a fydd yn monitro'r holl gysylltiadau gweithredol ac yn perfformio'r trawsnewidiadau angenrheidiol. Mae yma sawl cynnil. Yn gyntaf, gan ein bod yn sôn am NAT ar raddfa gweithredwr telathrebu, mae angen addasu'r terfynau amser, oherwydd gyda gwerthoedd diofyn bydd maint y tabl cyfieithu yn tyfu'n gyflym i werthoedd trychinebus. Isod mae enghraifft o'r gosodiadau a ddefnyddiais ar fy gweinyddwyr:

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

Ac yn ail, gan nad yw maint diofyn y tabl cyfieithu wedi'i gynllunio i weithio o dan amodau gweithredwr telathrebu, mae angen ei gynyddu:

net.netfilter.nf_conntrack_max = 3145728

Mae hefyd angen cynyddu nifer y bwcedi ar gyfer y bwrdd hash sy'n storio'r holl ddarllediadau (mae hwn yn opsiwn yn y modiwl nf_conntrack):

options nf_conntrack hashsize=1572864

Ar ôl y triniaethau syml hyn, ceir dyluniad cwbl weithredol a all drosi nifer fawr o gyfeiriadau cleientiaid yn gronfa o rai allanol. Fodd bynnag, mae perfformiad yr ateb hwn yn gadael llawer i'w ddymuno. Yn fy ymdrechion cyntaf i ddefnyddio GNU/Linux ar gyfer NAT (tua 2013), llwyddais i gael perfformiad o tua 7Gbit yr eiliad ar 0.8Mpps y gweinydd (Xeon E5-1650v2). Ers hynny, mae llawer o wahanol optimeiddiadau wedi'u gwneud yn pentwr rhwydwaith cnewyllyn GNU/Linux, mae perfformiad un gweinydd ar yr un caledwedd wedi cynyddu i bron 18-19 Gbit yr eiliad ar 1.8-1.9 Mpps (dyma'r gwerthoedd uchaf) , ond tyfodd y galw am gyfaint traffig, a broseswyd gan un gweinydd yn gynt o lawer. O ganlyniad, datblygwyd cynlluniau i gydbwyso'r llwyth ar wahanol weinyddion, ond cynyddodd hyn oll gymhlethdod sefydlu, cynnal a chynnal ansawdd y gwasanaethau a ddarperir.

NTFables

Y dyddiau hyn, tuedd ffasiynol mewn “bagiau symud” meddalwedd yw'r defnydd o DPDK a XDP. Mae llawer o erthyglau wedi'u hysgrifennu ar y pwnc hwn, mae llawer o wahanol areithiau wedi'u gwneud, ac mae cynhyrchion masnachol yn ymddangos (er enghraifft, SKAT gan VasExperts). Ond o ystyried adnoddau rhaglennu cyfyngedig gweithredwyr telathrebu, mae'n eithaf problemus creu unrhyw “gynnyrch” yn seiliedig ar y fframweithiau hyn ar eich pen eich hun. Bydd yn llawer anoddach gweithredu datrysiad o’r fath yn y dyfodol; yn benodol, bydd angen datblygu offer diagnostig. Er enghraifft, ni fydd tcpdump safonol gyda DPDK yn gweithio yn union fel hynny, ac ni fydd yn “gweld” pecynnau a anfonir yn ôl i'r gwifrau gan ddefnyddio XDP. Ynghanol yr holl sôn am dechnolegau newydd ar gyfer allbynnu anfon pecynnau ymlaen i ofod defnyddwyr, aethant yn ddisylw adroddiadau и erthyglau Pablo Neira Ayuso, cynhaliwr iptables, am ddatblygiad dadlwytho llif yn nftables. Edrychwn ar y mecanwaith hwn yn fwy manwl.

Y prif syniad yw pe bai'r llwybrydd yn pasio pecynnau o un sesiwn i ddau gyfeiriad y llif (aeth sesiwn TCP i'r cyflwr SEFYDLEDIG), yna nid oes angen pasio pecynnau dilynol y sesiwn hon trwy'r holl reolau wal dân, oherwydd bydd yr holl wiriadau hyn yn dal i ddod i ben gyda'r pecyn yn cael ei drosglwyddo ymhellach i'r llwybr. Ac nid oes angen i ni ddewis llwybr mewn gwirionedd - rydym eisoes yn gwybod i ba ryngwyneb ac at ba westeiwr y mae angen i ni anfon pecynnau o fewn y sesiwn hon. Y cyfan sydd ar ôl yw storio'r wybodaeth hon a'i defnyddio ar gyfer llwybro yn gynnar yn y broses o brosesu pecynnau. Wrth berfformio NAT, mae angen hefyd storio gwybodaeth am newidiadau mewn cyfeiriadau a phorthladdoedd a gyfieithwyd gan y modiwl nf_conntrack. Ydy, wrth gwrs, yn yr achos hwn mae swyddogion amrywiol a rheolau gwybodaeth ac ystadegol eraill yn iptables yn rhoi’r gorau i weithio, ond o fewn fframwaith y dasg o NAT sefydlog ar wahân neu, er enghraifft, ffin, nid yw hyn mor bwysig, oherwydd bod y gwasanaethau yn cael eu dosbarthu ar draws dyfeisiau.

Ffurfweddiad

I ddefnyddio'r swyddogaeth hon mae angen i ni:

• Defnyddiwch gnewyllyn ffres. Er gwaethaf y ffaith bod y swyddogaeth ei hun yn ymddangos yng nghnewyllyn 4.16, am gyfnod eithaf hir roedd yn “amrwd” iawn ac yn achosi panig cnewyllyn yn rheolaidd. Sefydlogodd popeth tua mis Rhagfyr 2019, pan ryddhawyd cnewyllyn LTS 4.19.90 a 5.4.5.
• Ailysgrifennu rheolau iptables mewn fformat nftables gan ddefnyddio fersiwn eithaf diweddar o nftables. Yn gweithio'n union yn fersiwn 0.9.0

Os yw popeth mewn egwyddor yn glir gyda'r pwynt cyntaf, y prif beth yw peidio ag anghofio cynnwys y modiwl yn y ffurfweddiad yn ystod y gwasanaeth (CONFIG_NFT_FLOW_OFFLOAD=m), yna mae angen esboniad ar yr ail bwynt. Disgrifir rheolau nftables yn hollol wahanol nag yn iptables. Cofnodion yn datgelu bron pob pwynt, mae yna hefyd arbennig trawsnewidyddion rheolau o iptables i nftables. Felly, ni roddaf ond enghraifft o sefydlu NAT a dadlwytho llif. Chwedl fach er enghraifft: , - dyma'r rhyngwynebau rhwydwaith y mae traffig yn mynd drwyddynt; mewn gwirionedd gall fod mwy na dau ohonynt. , — cyfeiriad cychwyn a diwedd yr ystod o gyfeiriadau “gwyn”.

Mae ffurfweddiad NAT yn syml iawn:

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

Gyda dadlwytho llif mae ychydig yn fwy cymhleth, ond yn eithaf dealladwy:

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

Dyna, mewn gwirionedd, yw'r gosodiad cyfan. Nawr bydd holl draffig TCP/CDU yn disgyn i'r bwrdd fastnat ac yn cael ei brosesu'n llawer cyflymach.

Canfyddiadau

Er mwyn ei gwneud yn glir pa mor “llawer cyflymach” yw hyn, byddaf yn atodi sgrinlun o'r llwyth ar ddau weinyddwr go iawn, gyda'r un caledwedd (Xeon E5-1650v2), wedi'i ffurfweddu'n union yr un fath, gan ddefnyddio'r un cnewyllyn Linux, ond yn perfformio NAT mewn iptables (NAT4) ac mewn nftables (NAT5).

Nid oes graff o becynnau yr eiliad yn y sgrinlun, ond ym mhroffil llwyth y gweinyddwyr hyn mae maint pecyn cyfartalog tua 800 beit, felly mae'r gwerthoedd yn cyrraedd hyd at 1.5Mpps. Fel y gwelwch, mae gan y gweinydd gyda nftables gronfa berfformiad enfawr. Ar hyn o bryd, mae'r gweinydd hwn yn prosesu hyd at 30Gbit yr eiliad ar 3Mpps ac mae'n amlwg ei fod yn gallu bodloni'r cyfyngiad rhwydwaith ffisegol o 40Gbps, tra bod ganddo adnoddau CPU am ddim.

Rwy'n gobeithio y bydd y deunydd hwn yn ddefnyddiol i beirianwyr rhwydwaith sy'n ceisio gwella perfformiad eu gweinyddwyr.

Ffynhonnell: hab.com