ПроХостер > блог > Администрација > Брзо рутирање и НАТ у Линуку

Брзо рутирање и НАТ у Линуку

Како ИПв4 адресе постају исцрпљене, многи телеком оператери су суочени са потребом да својим клијентима обезбеде приступ мрежи користећи превођење адреса. У овом чланку ћу вам рећи како можете постићи НАТ перформансе Царриер Граде на робним серверима.

Мало историје

Тема исцрпљивања ИПв4 адресног простора више није нова. У неком тренутку су се у РИПЕ-у појавиле листе чекања, затим су се појавиле берзе на којима се трговало блоковима адреса и склапали су послови о њиховом закупу. Телеком оператери су постепено почели да пружају услуге приступа Интернету користећи превод адреса и портова. Неки нису успели да прибаве довољно адреса да издају „белу” адресу сваком претплатнику, док су други почели да штеде одбијајући да купе адресе на секундарном тржишту. Произвођачи мрежне опреме подржали су ову идеју, јер ова функционалност обично захтева додатне модуле проширења или лиценце. На пример, у Јуниперовој линији МКС рутера (осим најновијих МКС104 и МКС204), можете да извршите НАПТ на посебној МС-МИЦ сервисној картици, Цисцо АСР1к захтева ЦГН лиценцу, Цисцо АСР9к захтева посебан А9К-ИСМ-100 модул и А9К-ЦГН лиценцу -ЛИЦ њему. Генерално, задовољство кошта много новца.

ИПТаблес

Задатак обављања НАТ-а не захтева специјализоване рачунарске ресурсе, већ га могу решити процесори опште намене, који су инсталирани, на пример, у било ком кућном рутеру. На нивоу телеком оператера, овај проблем се може решити коришћењем робних сервера који користе ФрееБСД (ипфв/пф) или ГНУ/Линук (иптаблес). Нећемо разматрати ФрееБСД, јер... Одавно сам престао да користим овај ОС, тако да ћемо се држати ГНУ/Линук-а.

Омогућавање превода адреса уопште није тешко. Прво морате да региструјете правило у иптаблес у табели нат:

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

Оперативни систем ће учитати нф_цоннтрацк модул, који ће надгледати све активне везе и извршити потребне конверзије. Овде постоји неколико суптилности. Прво, пошто је реч о НАТ-у на скали телеком оператера, потребно је подесити тајм-ауте, јер ће са подразумеваним вредностима величина табеле превођења брзо нарасти до катастрофалних вредности. Испод је пример подешавања која сам користио на својим серверима:

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

Такође је потребно повећати број кантица за хеш табелу у којој се чувају сва емитовања (ово је опција у модулу нф_цоннтрацк): 

options nf_conntrack hashsize=1572864

Након ових једноставних манипулација, добија се потпуно исправан дизајн који може да преведе велики број адреса клијената у скуп екстерних адреса. Међутим, перформансе овог решења остављају много да се пожеле. У мојим првим покушајима да користим ГНУ/Линук за НАТ (око 2013.), успео сам да постигнем перформансе од око 7Гбит/с при 0.8Мппс по серверу (Ксеон Е5-1650в2). Од тог времена, направљено је много различитих оптимизација у мрежном стеку ГНУ/Линук кернела, перформансе једног сервера на истом хардверу су порасле на скоро 18-19 Гбит/с при 1.8-1.9 Мппс (ово су биле максималне вредности) , али је потражња за обимом саобраћаја, који обрађује један сервер, расла много брже. Као резултат тога, развијене су шеме за балансирање оптерећења на различитим серверима, али је све то повећало сложеност постављања, одржавања и одржавања квалитета пружених услуга.

НФТаблес

У данашње време, модеран тренд у софтверским „променама врећа“ је употреба ДПДК и КСДП. Много је чланака написано на ову тему, одржано је много различитих говора, појављују се комерцијални производи (на пример, СКАТ из ВасЕкпертс-а). Али с обзиром на ограничене програмске ресурсе телеком оператера, прилично је проблематично креирати било који „производ“ заснован на овим оквирима самостално. У будућности ће бити много теже управљати таквим решењем, посебно ће се морати развити дијагностички алати. На пример, стандардни тцпдумп са ДПДК неће функционисати тек тако и неће „видети“ пакете који се враћају у жице користећи КСДП. Усред свих прича о новим технологијама за прослеђивање пакета у кориснички простор, оне су остале непримећене извештаји и Чланак Пабло Неира Аиусо, одржавалац иптаблес-а, о развоју претовара тока у нфтаблес-у. Погледајмо овај механизам детаљније.

Основна идеја је да ако је рутер прослеђивао пакете из једне сесије у оба смера тока (ТЦП сесија је прешла у ЕСТАБЛИСХЕД стање), онда нема потребе да се следећи пакети ове сесије пропуштају кроз сва правила заштитног зида, јер све ове провере ће се и даље завршити тако што се пакет даље преноси на рутирање. И заправо не морамо да бирамо руту – већ знамо на који интерфејс и на који хост треба да шаљемо пакете у оквиру ове сесије. Остаје само да се ове информације чувају и користе за рутирање у раној фази обраде пакета. Приликом обављања НАТ-а потребно је додатно ускладиштити информације о променама адреса и портова које је превео нф_цоннтрацк модул. Да, наравно, у овом случају разни полицајци и друга информациона и статистичка правила у иптаблес-у престају да раде, али у оквиру задатка засебног сталног НАТ-а или, на пример, границе, то није толико важно, јер услуге дистрибуирају се по уређајима.

Конфигурација

Да бисмо користили ову функцију, потребно нам је:

  • Користите свеже језгро. Упркос чињеници да се сама функционалност појавила у кернелу 4.16, доста дуго је била веома „сирова“ и редовно је изазивала панику кернела. Све се стабилизовало око децембра 2019, када су пуштени ЛТС кернели 4.19.90 и 5.4.5.
  • Препишите иптаблес правила у нфтаблес формату користећи прилично новију верзију нфтаблес. Ради тачно у верзији 0.9.0

Ако је све у принципу јасно са првом тачком, главна ствар је да не заборавите да укључите модул у конфигурацију током монтаже (ЦОНФИГ_НФТ_ФЛОВ_ОФФЛОАД=м), онда друга тачка захтева објашњење. нфтаблес правила су описана потпуно другачије него у иптаблес. Записи открива скоро све тачке, постоје и посебне претварачи правила од иптаблес до нфтаблес. Стога ћу навести само пример подешавања НАТ-а и отпуштања протока. Мала легенда на пример: , - ово су мрежни интерфејси кроз које саобраћај пролази; у стварности их може бити више од два. , — почетну и крајњу адресу опсега „белих“ адреса.

НАТ конфигурација је врло једноставна:

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

То је, у ствари, цела поставка. Сада ће сав ТЦП/УДП саобраћај пасти у фастнат табелу и бити обрађен много брже.

Налази

Да би било јасно колико је ово „много брже“, приложићу снимак екрана оптерећења на два стварна сервера, са истим хардвером (Ксеон Е5-1650в2), идентично конфигурисаним, користећи исто језгро Линука, али обављајући НАТ у иптаблес (НАТ4) и у нфтаблес (НАТ5).

Брзо рутирање и НАТ у Линуку

На снимку екрана нема графикона пакета у секунди, али у профилу оптерећења ових сервера просечна величина пакета је око 800 бајтова, тако да вредности достижу и до 1.5Мппс. Као што видите, сервер са нфтаблес има огромну резерву перформанси. Тренутно, овај сервер обрађује до 30Гбит/с при 3Мппс и очигледно је способан да испуни ограничење физичке мреже од 40Гбпс, док има слободне ЦПУ ресурсе.

Надам се да ће овај материјал бити користан мрежним инжењерима који покушавају да побољшају перформансе својих сервера.

Извор: ввв.хабр.цом

Додај коментар