IPv4 мекенжайлары таусылғандықтан, көптеген байланыс операторлары мекенжайды аудару арқылы өз клиенттеріне желіге кіруді қамтамасыз ету қажеттілігіне тап болады. Бұл мақалада мен сізге тауар серверлерінде Carrier Grade NAT өнімділігін қалай алуға болатынын айтамын.
Біраз тарих
IPv4 мекенжай кеңістігін сарқылу тақырыбы енді жаңа емес. Бір сәтте RIPE-де күту тізімдері пайда болды, содан кейін мекен-жайлар блоктары сатылатын биржалар пайда болды және оларды жалға беру туралы мәмілелер жасалды. Байланыс операторлары бірте-бірте мекенжай мен портты аудару арқылы Интернетке қол жеткізу қызметтерін көрсете бастады. Кейбіреулер әрбір абонентке «ақ» мекенжай беру үшін жеткілікті мекенжай ала алмады, ал басқалары қайталама нарықта мекенжайларды сатып алудан бас тартып, ақша үнемдей бастады. Желілік жабдықты өндірушілер бұл идеяны қолдады, өйткені бұл функция әдетте қосымша кеңейтім модульдерін немесе лицензияларды қажет етеді. Мысалы, Juniper MX маршрутизаторлар желісінде (соңғы MX104 және MX204-тен басқа) NAPT қызметін бөлек MS-MIC қызмет картасында орындауға болады, Cisco ASR1k үшін CGN лицензиясы қажет, Cisco ASR9k бөлек A9K-ISM-100 модулін қажет етеді. және оған A9K-CGN лицензиясы -LIC. Жалпы, ләззат алу үшін көп ақша қажет.
IPTables
NAT орындау міндеті арнайы есептеу ресурстарын қажет етпейді, оны, мысалы, кез келген үй маршрутизаторында орнатылған жалпы мақсаттағы процессорлар шеше алады. Байланыс операторының масштабында бұл мәселені FreeBSD (ipfw/pf) немесе GNU/Linux (iptables) жұмыс істейтін тауар серверлері арқылы шешуге болады. Біз FreeBSD-ді қарастырмаймыз, себебі... Мен бұл ОЖ-ны пайдалануды әлдеқашан тоқтатқанмын, сондықтан біз GNU/Linux-ты ұстанамыз.
Мекенжай аудармасын қосу мүлде қиын емес. Алдымен nat кестесіндегі iptables ережесін тіркеу керек:
iptables -t nat -A POSTROUTING -s 100.64.0.0/10 -j SNAT --to <pool_start_addr>-<pool_end_addr> --persistent
Амалдық жүйе барлық белсенді қосылымдарды бақылайтын және қажетті түрлендірулерді орындайтын nf_conntrack модулін жүктейді. Мұнда бірнеше нәзіктіктер бар. Біріншіден, біз байланыс операторының шкаласында NAT туралы айтып отырғандықтан, күту уақытын реттеу қажет, өйткені әдепкі мәндермен аударма кестесінің өлшемі апатты мәндерге тез өседі. Төменде мен серверлерде пайдаланған параметрлердің мысалы келтірілген:
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
Екіншіден, аударма кестесінің әдепкі өлшемі байланыс операторының жағдайында жұмыс істеуге арналмағандықтан, оны ұлғайту қажет:
net.netfilter.nf_conntrack_max = 3145728
Сондай-ақ, барлық таратылымдарды сақтайтын хэш кестесі үшін шелектердің санын көбейту қажет (бұл nf_conntrack модуліндегі опция):
options nf_conntrack hashsize=1572864
Осы қарапайым манипуляциялардан кейін клиенттің көптеген мекенжайларын сыртқы пулға аудара алатын толық жұмыс істейтін дизайн алынады. Дегенмен, бұл шешімнің өнімділігі көп нәрсені қаламайды. NAT үшін GNU/Linux пайдаланудағы алғашқы әрекеттерімде (шамамен 2013 ж.) мен бір серверге 7 Мп/с жылдамдықпен шамамен 0.8 Гбит/с өнімділікке қол жеткіздім (Xeon E5-1650v2). Сол уақыттан бері GNU/Linux ядросының желі стекінде көптеген әртүрлі оңтайландырулар жасалды, бір сервердің бір аппараттық құралдағы өнімділігі 18-19 Мп/с жылдамдықпен 1.8-1.9 Гбит/с дейін өсті (бұл ең жоғары мәндер болды) , бірақ бір сервер өңдейтін трафик көлеміне сұраныс әлдеқайда жылдам өсті. Нәтижесінде әртүрлі серверлердегі жүктемені теңестіру үшін схемалар әзірленді, бірақ мұның бәрі ұсынылатын қызметтердің сапасын орнату, қолдау және қолдаудың күрделілігін арттырды.
NF кестелері
Қазіргі уақытта «сөмкелерді ауыстыру» бағдарламалық жасақтамасындағы сәнді тренд DPDK және XDP пайдалану болып табылады. Бұл тақырыпта көптеген мақалалар жазылды, көптеген түрлі баяндамалар жасалды, коммерциялық өнімдер пайда болды (мысалы, VasExperts компаниясының SKAT). Бірақ байланыс операторларының шектеулі бағдарламалау ресурстарын ескере отырып, осы құрылымдарға негізделген кез-келген «өнімді» өз бетіңізше жасау өте қиын. Болашақта мұндай шешімді пайдалану әлдеқайда қиын болады, атап айтқанда, диагностикалық құралдарды жасау керек. Мысалы, DPDK бар стандартты tcpdump дәл осылай жұмыс істемейді және XDP арқылы сымдарға кері жіберілген пакеттерді «көрмейді». Пайдаланушы кеңістігіне пакеттерді қайта жіберудің жаңа технологиялары туралы барлық әңгімелердің арасында олар назардан тыс қалды. и Пабло Нейра Аюсо, iptables қолдаушысы, nftables-те ағынды түсіруді дамыту туралы. Бұл механизмді толығырақ қарастырайық.
Негізгі идея мынада: егер маршрутизатор бір сеанстан пакеттерді ағынның екі бағытына да өткізсе (TCP сеансы ҚҰРЫЛҒАН күйге өтті), онда осы сеанстың келесі пакеттерін брандмауэрдің барлық ережелері арқылы өткізудің қажеті жоқ, өйткені барлық осы тексерулер пакетті маршруттауға жіберумен аяқталады. Бізге маршрутты таңдаудың қажеті жоқ - біз осы сеанс ішінде пакеттерді қай интерфейске және қандай хостқа жіберу керектігін білеміз. Бұл ақпаратты сақтау және оны пакеттерді өңдеудің бастапқы кезеңінде маршруттау үшін пайдалану ғана қалады. NAT орындаған кезде nf_conntrack модулі арқылы аударылған мекенжайлар мен порттардағы өзгерістер туралы ақпаратты қосымша сақтау қажет. Иә, әрине, бұл жағдайда әртүрлі полицейлер және iptables-тегі басқа ақпарат және статистикалық ережелер жұмысын тоқтатады, бірақ жеке тұрған NAT немесе, мысалы, шекараның тапсырмасы аясында бұл соншалықты маңызды емес, өйткені қызметтер құрылғыларға таратылады.
Конфигурация
Бұл функцияны пайдалану үшін бізге қажет:
- Жаңа ядроны пайдаланыңыз. Функционалдық 4.16 ядросында пайда болғанына қарамастан, ол ұзақ уақыт бойы өте «шикі» болды және үнемі ядроның дүрбелеңін тудырды. Барлығы 2019 жылдың желтоқсанында тұрақтанды, ол кезде LTS ядролары 4.19.90 және 5.4.5 шығарылды.
- nftables-тің өте соңғы нұсқасын пайдаланып iptables ережелерін nftables пішімінде қайта жазыңыз. 0.9.0 нұсқасында дәл жұмыс істейді
Егер бірінші тармақта принцип бойынша бәрі түсінікті болса, ең бастысы құрастыру кезінде модульді конфигурацияға қосуды ұмытпау керек (CONFIG_NFT_FLOW_OFFLOAD=m), онда екінші тармақ түсіндіруді қажет етеді. nftables ережелері iptables ережелеріне қарағанда мүлдем басқаша сипатталған. барлық дерлік тұстарын ашады, ерекшелері де бар iptables-тен nftable-ге дейінгі ережелер. Сондықтан мен тек NAT және ағынды түсіруді орнатудың мысалын беремін. Мысалы, шағын аңыз: , - бұл трафик өтетін желілік интерфейстер, шын мәнінде олардың екеуінен де көп болуы мүмкін. , — «ақ» адрестер диапазонының бастапқы және аяқталу адресі.
NAT конфигурациясы өте қарапайым:
#! /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
}
}
Ағынды түсіру кезінде бұл сәл күрделірек, бірақ түсінікті:
#! /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;
}
}
Бұл, шын мәнінде, бүкіл орнату. Енді барлық TCP/UDP трафигі fastnat кестесіне түседі және әлдеқайда жылдам өңделеді.
нәтижелері
Мұның қаншалықты «тезірек» екенін түсіну үшін мен бірдей конфигурацияланған, бірдей Linux ядросын пайдаланып, бірақ iptables-де NAT орындайтын бірдей аппараттық құралмен (Xeon E5-1650v2) екі нақты сервердегі жүктеменің скриншотын қосамын. (NAT4) және nftables (NAT5).
Скриншотта секундына дестелердің графигі жоқ, бірақ бұл серверлердің жүктеме профилінде орташа пакет өлшемі шамамен 800 байт, сондықтан мәндер 1.5 Мп/сек дейін жетеді. Көріп отырғаныңыздай, nftables сервері үлкен өнімділікке ие. Қазіргі уақытта бұл сервер 30Mpps жылдамдықта 3 Гбит/с дейін өңдейді және тегін процессор ресурстарына ие бола отырып, 40 Гбит/с физикалық желі шектеуіне жауап бере алатыны анық.
Бұл материал серверлерінің жұмысын жақсартуға тырысатын желі инженерлері үшін пайдалы болады деп үміттенемін.
Ақпарат көзі: www.habr.com