{"id":81265,"date":"2020-05-12T01:42:43","date_gmt":"2020-05-11T23:42:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/bystryj-routing-i-nat-v-linux"},"modified":"2020-05-12T01:42:43","modified_gmt":"2020-05-11T23:42:43","slug":"bystryj-routing-i-nat-v-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/bystryj-routing-i-nat-v-linux","title":{"rendered":"Kiire routing ja NAT Linuxis","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

IPv4 aadresside ammendumise t\u00f5ttu seisavad paljud telekommunikatsiooniettev\u00f5tted silmitsi vajadusega korraldada oma klientide juurdep\u00e4\u00e4s v\u00f5rku aadresside t\u00f5lke abil. Selles artiklis r\u00e4\u00e4gin, kuidas saavutada Carrier Grade NAT tasemel j\u00f5udlus kommoditeediserveritel.
\n<\/a><\/noindex><\/p>\n

Enne kui liigume edasi<\/h3>\n

\nIPv4 aadressiruumide ammendumise teema ei ole enam uus. Teatud hetkel tekkisid RIPE'is ooteread (waiting list), seej\u00e4rel ilmusid b\u00f6rsid, kus kaupleti aadressiblokke ning s\u00f5lmiti lepingud nende rentimiseks. Aja jooksul hakkasid telekommunikatsiooniettev\u00f5tted pakkuma interneti juurdep\u00e4\u00e4su aadresside ja portide t\u00f5lke abil. M\u00f5ned ei saanud piisavalt aadresse, et anda igale tellijale 'valget' aadressi, teised alustasid s\u00e4\u00e4stmist, loobudes aadresside ostmisest sekundaarsetelt turgudelt. V\u00f5rguseadmete tootjad toetasid seda ideed, kuna see funktsioon n\u00f5uab tavaliselt t\u00e4iendavaid laiendusi v\u00f5i litsentse. N\u00e4iteks Juniperi MX marsruuteri seerias (v\u00e4lja arvatud viimased MX104 ja MX204) saab NAPT-i teostada eraldi teenusekaardil MS-MIC, Cisco ASR1k puhul on vajalik CGN litsents, Cisco ASR9k puhul on vajalik eraldi A9K-ISM-100 moodul ja litsents A9K-CGN-LIC selle jaoks. \u00dcldiselt ei ole see odav l\u00f5bu.<\/p>\n

IPTables<\/h3>\n

\nNAT-i teostamise \u00fclesanne ei n\u00f5ua spetsialiseeritud arvutiv\u00f5imsust, see on suuteline lahendama tavalised protsessorid, mis on installitud n\u00e4iteks igas koduses ruuteris. Telekommunikatsiooniettev\u00f5tte mastaabis saab selle \u00fclesande lahendada, kasutades kommertservereid FreeBSD (ipfw\/pf) v\u00f5i GNU\/Linux (iptables) operatsioonis\u00fcsteemidega. FreeBSD-d ei k\u00e4sitle, kuna ma olen juba pikka aega loobunud selle OS-i kasutamisest, seega peatume GNU\/Linuxi peal.<\/p>\n

Aadresside t\u00f5lke lubamine ei ole sugugi keeruline. Alustamiseks tuleb kirjutada reegel iptables'i nat tabelisse:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nOperatsioonis\u00fcsteem laadib nf_conntrack mooduli, mis j\u00e4lgib k\u00f5iki aktiivseid \u00fchendusi ja viib l\u00e4bi vajalikud muutused. Siin on m\u00f5ned n\u00fcansid. Esiteks, kuna tegu on operaatori NAT-iga, tuleb ajav\u00e4lja timeout-e kohandada, sest vaikev\u00e4\u00e4rtustega v\u00f5ib t\u00f5lgete tabel kiiresti j\u00f5uda katastroofiliste suurusteni. Allpool on n\u00e4ide seadistustest, mida olen oma serverites kasutanud:<\/p>\n
net.ipv4.ip_forward = 1\nnet.ipv4.ip_local_port_range = 8192 65535\n\nnet.netfilter.nf_conntrack_generic_timeout = 300\nnet.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60\nnet.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60\nnet.netfilter.nf_conntrack_tcp_timeout_established = 600\nnet.netfilter.nf_conntrack_tcp_timeout_fin_wait = 60\nnet.netfilter.nf_conntrack_tcp_timeout_close_wait = 45\nnet.netfilter.nf_conntrack_tcp_timeout_last_ack = 30\nnet.netfilter.nf_conntrack_tcp_timeout_time_wait = 120\nnet.netfilter.nf_conntrack_tcp_timeout_close = 10\nnet.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300\nnet.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300\nnet.netfilter.nf_conntrack_udp_timeout = 30\nnet.netfilter.nf_conntrack_udp_timeout_stream = 60\nnet.netfilter.nf_conntrack_icmpv6_timeout = 30\nnet.netfilter.nf_conntrack_icmp_timeout = 30\nnet.netfilter.nf_conntrack_events_retry_timeout = 15\nnet.netfilter.nf_conntrack_checksum=0\n<\/code><\/pre>\n
\nJa teiseks, kuna vaikimisi tabeli suurus ei ole kohandatud operaatoritingimustele, tuleb seda suurendada:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Samuti tuleb suurendada ka p\u00e4iste arvu hash-tabelis, mis sisaldab k\u00f5iki muundamisi (see on nf_conntrack mooduli valik): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nP\u00e4rast neid lihtsaid toiminguid tekib t\u00e4iesti t\u00f6\u00f6korras lahendus, mis suudab edastada suurt hulka klientide aadresse v\u00e4liste aadresside kogusse. Siiski, selle lahenduse j\u00f5udlus j\u00e4\u00e4b soovitust madalamaks. Oma esimestel katsetel kasutada GNU\/Linuxi NAT-ina (umbes aastal 2013) sain \u00fche serveri (Xeon E5-1650v2) korral j\u00f5udluse umbes 7Gbit\/s ja 0.8Mpps. Sellest ajast on GNU\/Linuxi s\u00fcdamiku v\u00f5rgustiku sisene tehtud palju erinevaid optimeerimisi, \u00fche serveri j\u00f5udlus samal riistvaral on t\u00f5usnud praktiliselt 18-19 Gbit\/s ja 1.8-1.9 Mpps (need olid piiri v\u00e4\u00e4rtused), kuid \u00fche serveri k\u00e4ideldava liikluse maht on kasvanud palju kiiremini. L\u00f5puks on v\u00e4lja t\u00f6\u00f6tatud koormuse tasakaalustamise skeemid erinevate serverite vahel, kuid see k\u00f5ik on suurendanud seadistamise, hooldamise ja teenuse kvaliteedi s\u00e4ilitamise keerukust.<\/p>\n
NFTables<\/h3>\n
\nPraegu on moes programmide \"pakettide \u00fcmberpanemise\" suund DPDK ja XDP kasutamine. Sellel teemal on kirjutatud hulgaliselt artikleid, toimunud on palju erinevaid ettekandeid ja turule on ilmunud kaubanduslikke tooteid (n\u00e4iteks SCAT firmalt VasExperts). Kuid piiratud inimressurssidega programmeerijatel on keeruline ise midagi sarnast nende raamistike baasil kokku panna. Sellise lahenduse kasutamine hiljem osutub palju keerulisemaks, sealhulgas tuleb v\u00e4lja t\u00f6\u00f6tada diagnostikavahendid. N\u00e4iteks tavap\u00e4rane tcpdump DPDK-ga lihtsalt ei t\u00f6\u00f6ta, samuti ei \"n\u00e4e\" ta pakette, mis saadetakse tagasi juhtmetesse XDP abil. Uute tehnoloogiate, mis edastavad pakette user-space'is, r\u00e4\u00e4kimise taustal on t\u00e4helepanuta j\u00e4\u00e4nud ettekanded<\/a><\/noindex> ja artikleid<\/a><\/noindex> Pablo Neira Ayuso, iptables'i hooldaja, r\u00e4\u00e4kis flow offloading'i arendamisest nftables'is. Vaadakem seda mehhanismi l\u00e4hemalt.<\/p>\n
Peamine idee seisneb selles, et kui ruuter on lasknud sama sessiooni pakette m\u00f5lemas suunas voos (TCP sessioon on l\u00e4inud ESTABLISHED olekusse), siis ei ole tarvis edasisi selle sessiooni pakette l\u00e4bi k\u00f5igi tulem\u00fc\u00fcrireeglite lasta, kuna k\u00f5ik need kontrollid l\u00f5ppevad igal juhul paketi edastamisega edasise suunamise juurde. Ja valiku tegemine marsruudi suhtes pole samuti vajalik \u2014 me teame juba, milliseks liideseks ja millisele hostile tuleb paketid selle sessiooni piires edastada. J\u00e4\u00e4b vaid see teave salvestada ja kasutada seda paketi varajases t\u00f6\u00f6tlemise etapis marsruudiks. NAT'i t\u00e4itmisel on vajalik ka salvestada teave aadresside ja sadamate muudatuste kohta, mida transformaator nf_conntrack on teinud. Jah, muidugi, sel juhul l\u00f5petavad t\u00f6\u00f6 mitmesugused poliitikavahendajad ja muud teabe-statistilised reeglid iptables'is, kuid eraldi NAT'i v\u00f5i n\u00e4iteks piiri\u00fclese \u00fclesande kontekstis ei ole see sugugi nii oluline, kuna teenused on jaotatud seadmete vahel.<\/p>\n
Konfiguratsioon<\/h4>\n
\nSelle funktsiooni kasutamiseks peame:<\/p>\n