{"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\/ro\/blog\/administrirovanie\/bystryj-routing-i-nat-v-linux","title":{"rendered":"Rutare rapid\u0103 \u0219i NAT \u00een Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pe m\u0103sur\u0103 ce adresele IPv4 se epuizeaz\u0103, mul\u021bi operatori de telecomunica\u021bii s-au confruntat cu nevoia de a organiza accesul clien\u021bilor lor la re\u021bea prin traducerea adreselor. \u00cen acest articol, voi explica cum se poate ob\u021bine o performan\u021b\u0103 de nivel Carrier Grade NAT pe servere de tip commodity.
\n<\/a><\/noindex><\/p>\n

Pu\u021bin istorie<\/h3>\n

\nTema epuiz\u0103rii spa\u021biului de adrese IPv4 nu mai este nou\u0103. La un moment dat, \u00een RIPE au ap\u0103rut liste de a\u0219teptare (waiting list), apoi au ap\u0103rut burse pe care erau tranzac\u021bionate blocuri de adrese \u0219i se \u00eencheiau contracte pentru \u00eenchirierea acestora. Treptat, operatorii de telecomunica\u021bii au \u00eenceput s\u0103 ofere servicii de acces la internet prin traducerea adreselor \u0219i a porturilor. Unii nu au reu\u0219it s\u0103 ob\u021bin\u0103 suficiente adrese pentru a oferi o adres\u0103 \u201ealb\u0103\u201d fiec\u0103rui abonat, iar al\u021bii au \u00eenceput s\u0103 economiseasc\u0103 resurse refuz\u00e2nd achizi\u021bionarea de adrese pe pia\u021ba secundar\u0103. Produc\u0103torii de echipamente de re\u021bea au sprijinit aceast\u0103 idee, deoarece aceast\u0103 func\u021bionalitate necesit\u0103 de obicei module suplimentare sau licen\u021be. De exemplu, la Juniper, \u00een gama de routere MX (cu excep\u021bia ultimelor MX104 \u0219i MX204), NAPT poate fi realizat pe un card de serviciu separat MS-MIC, iar pentru Cisco ASR1k este necesar\u0103 o licen\u021b\u0103 CGN, \u00een timp ce pentru Cisco ASR9k este necesar un modul separat A9K-ISM-100 \u0219i o licen\u021b\u0103 A9K-CGN-LIC. \u00cen general, pl\u0103cerea are un cost destul de ridicat.<\/p>\n

IPTables<\/h3>\n

\nSarcina de a efectua NAT nu necesit\u0103 resurse computa\u021bionale specializate; aceasta poate fi rezolvat\u0103 de procesoare generice, care sunt instalate, de exemplu, \u00een orice router de acas\u0103. La scar\u0103 de operator de telecomunica\u021bii, aceast\u0103 problem\u0103 poate fi rezolvat\u0103 folosind servere commodity care ruleaz\u0103 FreeBSD (ipfw\/pf) sau GNU\/Linux (iptables). Nu vom lua \u00een considerare FreeBSD, deoarece am renun\u021bat la utilizarea acestui sistem de operare cu ceva timp \u00een urm\u0103, a\u0219a c\u0103 ne vom concentra pe GNU\/Linux.<\/p>\n

Activarea traducerii adreselor nu este deloc complicat\u0103. \u00cen primul r\u00e2nd, este necesar s\u0103 se scrie o regul\u0103 \u00een iptables \u00een tabelul nat:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nSistemul de operare va \u00eenc\u0103rca modulul nf_conntrack, care va monitoriza toate conexiunile active \u0219i va efectua transform\u0103rile necesare. Exist\u0103 c\u00e2teva subtilit\u0103\u021bi aici. \u00cen primul r\u00e2nd, deoarece este vorba despre NAT la scar\u0103 de operator de telecomunica\u021bii, trebuie ajustate timeout-urile, deoarece cu valorile implicite, dimensiunea tabelului de traduceri va cre\u0219te rapid la valori catastrofale. Mai jos este un exemplu de set\u0103ri pe care le-am folosit pe serverele mele:<\/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
\n\u00cen al doilea r\u00e2nd, av\u00e2nd \u00een vedere c\u0103 dimensiunea tabelului de conversie nu este calculat\u0103 \u00een mod implicit pentru a func\u021biona \u00een condi\u021biile unui operator de telecomunica\u021bii, aceasta trebuie s\u0103 fie crescut\u0103:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n De asemenea, este necesar s\u0103 cre\u0219tem \u0219i num\u0103rul de buckets pentru tabelul hash care p\u0103streaz\u0103 toate conversiile (aceasta este o op\u021biune a modulului nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nDup\u0103 aceste manevre simple, ob\u021binem o structur\u0103 func\u021bional\u0103, care poate traduce un num\u0103r mare de adrese de client \u00een pool-ul extern. Cu toate acestea, performan\u021ba acestei solu\u021bii las\u0103 de dorit. \u00cen primele mele \u00eencerc\u0103ri de utilizare a GNU\/Linux pentru NAT (aproximativ 2013), am reu\u0219it s\u0103 ob\u021bin o performan\u021b\u0103 de aproximativ 7Gbit\/s la 0.8Mpps pe un server (Xeon E5-1650v2). De atunci, \u00een stiva de re\u021bea a nucleului GNU\/Linux au fost efectuate multe optimiz\u0103ri diferite, iar performan\u021ba unui singur server pe acela\u0219i hardware a crescut practic la 18-19 Gbit\/s la 1.8-1.9 Mpps (acestea au fost valorile maxime), dar cerin\u021ba privind volumul de trafic procesat de un singur server a crescut mult mai repede. \u00cen consecin\u021b\u0103, au fost dezvoltate scheme de echilibrare a \u00eenc\u0103rc\u0103rii pe diferite servere, \u00eens\u0103 toate acestea au crescut complexitatea configur\u0103rii, \u00eentre\u021binerii \u0219i men\u021binerii calit\u0103\u021bii serviciilor oferite.<\/p>\n
NFTables<\/h3>\n
\n\u00cen prezent, o direc\u021bie popular\u0103 \u00een \"manipularea pachetelor\" este utilizarea DPDK \u0219i XDP. Pe aceast\u0103 tem\u0103 au fost scrise multe articole, au avut loc diverse prezent\u0103ri \u0219i au ap\u0103rut produse comerciale (de exemplu, SKAT de la VasExperts). \u00cens\u0103, \u00een condi\u021biile resurselor limitate ale programatorilor din cadrul operatorilor de telecomunica\u021bii, este destul de problematic s\u0103 dezvolt\u0103m o solu\u021bie \u201eartizanal\u0103\u201d bazat\u0103 pe aceste cadre. Utilizarea unei astfel de solu\u021bii \u00een continuare va fi mult mai complicat\u0103, \u00een special va trebui s\u0103 dezvolt\u0103m instrumente de diagnoz\u0103. De exemplu, tcpdump standard nu va func\u021biona cu DPDK, iar pachetele trimise \u00eenapoi prin cabluri folosind XDP nu vor fi \"vizibile\". \u00cen acest context, toate discu\u021biile despre noile tehnologii de redirec\u021bionare a pachetelor \u00een user-space au r\u0103mas nefavorizate. prezent\u0103ri<\/a><\/noindex> \u0219i recomand\u0103rile sunt aplicabile coronavirusurilor \u00een general \u0219i COVID-19 \u00een particular. A\u0219adar, recomand s\u0103 desc\u0103rca\u021bi \u0219i s\u0103 printa\u021bi articolul (pentru cei interesa\u021bi de acest subiect).<\/a><\/noindex> Pablo Neira Ayuso, \u00eentre\u021bin\u0103torul iptables, despre dezvoltarea flow offloading \u00een nftables. S\u0103 vedem acest mecanism mai \u00een detaliu.<\/p>\n
Ideea principal\u0103 este c\u0103, dac\u0103 routerul a permis pachetele unei sesiuni \u00een ambele direc\u021bii ale fluxului (sesiunea TCP a trecut \u00een starea ESTABLISHED), nu este necesar s\u0103 permit\u0103 pachetele ulterioare ale acestei sesiuni s\u0103 treac\u0103 prin toate regulile firewall-ului, deoarece toate aceste verific\u0103ri se vor \u00eencheia cu transmiterea pachetului mai departe \u00een rutare. De asemenea, nu trebuie s\u0103 lu\u0103m o decizie privind ruta \u2014 \u0219tim deja pe ce interfa\u021b\u0103 \u0219i c\u0103tre ce host trebuie s\u0103 direc\u021bion\u0103m pachetele \u00een cadrul acestei sesiuni. R\u0103m\u00e2ne doar s\u0103 p\u0103str\u0103m aceast\u0103 informa\u021bie \u0219i s\u0103 o utiliz\u0103m pentru rutare \u00een stadiul incipient al proces\u0103rii pachetului. La efectuarea NAT, este necesar s\u0103 p\u0103str\u0103m informa\u021bia despre modific\u0103rile adreselor \u0219i porturilor, transformate de modulul nf_conntrack. Da, desigur, \u00een acest caz nu vor mai func\u021biona diferite poliseri \u0219i alte reguli informa\u021bionale-statistice \u00een iptables, dar \u00een contextul unei sarcini individuale a unui NAT separat sau, de exemplu, a unei margini \u2014 acest lucru nu este at\u00e2t de important, deoarece serviciile sunt distribuite pe dispozitive.<\/p>\n
Configura\u021bie<\/h4>\n
\nPentru a beneficia de aceast\u0103 func\u021bie, trebuie s\u0103:<\/p>\n