{"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\/sq\/blog\/administrirovanie\/bystryj-routing-i-nat-v-linux","title":{"rendered":"Routimi i shpejt\u00eb dhe NAT n\u00eb Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Me r\u00ebnien e adresave IPv4, shum\u00eb operator\u00eb t\u00eb telekomunikacionit u p\u00ebrball\u00ebn me nevoj\u00ebn p\u00ebr t\u00eb organizuar qasjen e klient\u00ebve t\u00eb tyre n\u00eb rrjet n\u00ebp\u00ebrmjet p\u00ebrkthimit t\u00eb adresave. N\u00eb k\u00ebt\u00eb artikull, do t\u00eb flas p\u00ebr m\u00ebnyrat se si mund t\u00eb arrijm\u00eb performanc\u00ebn e nivelit Carrier Grade NAT n\u00eb server\u00eb t\u00eb zakonsh\u00ebm.
\n<\/a><\/noindex><\/p>\n

Pak histori<\/h3>\n

\nTema e p\u00ebrfundimit t\u00eb hap\u00ebsir\u00ebs adresuese IPv4 nuk \u00ebsht\u00eb e re. N\u00eb nj\u00eb moment t\u00eb caktuar n\u00eb RIPE u shfaq\u00ebn listar\u00eb pritjeje, pastaj tregje ku tregoheshin blloqet e adresave dhe u lidh\u00ebn marr\u00ebveshje p\u00ebr qiramarrjen e tyre. Gradualisht, operator\u00ebt e telekomunikacionit filluan t\u00eb ofrojn\u00eb sh\u00ebrbime qasje n\u00eb internet duke p\u00ebrdorur p\u00ebrkthimin e adresave dhe porteve. Disa nuk arrit\u00ebn t\u00eb merrnin mjaft adresash p\u00ebr t'iu ofruar \u00e7do abonenti nj\u00eb adres\u00eb 't\u00eb bardh\u00eb', nd\u00ebrsa disa filluan t\u00eb kursejn\u00eb, duke refuzuar t\u00eb blenin adresa n\u00eb tregun e dyt\u00eb. Prodhuesit e pajisjeve rrjetike mb\u00ebshtet\u00ebn k\u00ebt\u00eb ide, pasi ky funksionalitet zakonisht k\u00ebrkon modulet e zgjerimit ose licensat shtes\u00eb. P\u00ebr shembull, n\u00eb linj\u00ebn e router\u00ebve MX t\u00eb Juniper (p\u00ebrve\u00e7 versioneve t\u00eb fundit MX104 dhe MX204), p\u00ebr t\u00eb realizuar NAPT k\u00ebrkohet nj\u00eb kart\u00eb sh\u00ebrbimi e ve\u00e7ant\u00eb MS-MIC, nd\u00ebrsa p\u00ebr Cisco ASR1k k\u00ebrkohet nj\u00eb licens\u00eb SGN, dhe p\u00ebr Cisco ASR9k - nj\u00eb moduli i ve\u00e7ant\u00eb A9K-ISM-100 dhe licens\u00eb A9K-CGN-LIC p\u00ebr t\u00eb. N\u00eb p\u00ebrgjith\u00ebsi, k\u00ebto sh\u00ebrbime k\u00ebrkojn\u00eb nj\u00eb investim t\u00eb konsideruesh\u00ebm.<\/p>\n

IPTables<\/h3>\n

\nDetyra e realizimit t\u00eb NAT-it nuk k\u00ebrkon burime t\u00eb specializuara t\u00eb llogaritjes; kjo mund t\u00eb zgjidhet nga procesor\u00ebt e zakonsh\u00ebm, t\u00eb cil\u00ebt jan\u00eb t\u00eb instaluar, p\u00ebr shembull, n\u00eb \u00e7do router sht\u00ebpiak. N\u00eb shkall\u00ebn e nj\u00eb operatori telekomunikacioni, kjo detyr\u00eb mund t\u00eb zgjidhet duke p\u00ebrdorur server\u00ebt e zakonsh\u00ebm n\u00ebn menaxhimin e FreeBSD (ipfw\/pf) ose GNU\/Linux (iptables). Nuk do ta shqyrtojm\u00eb FreeBSD-n\u00eb, pasi un\u00eb kam hequr dor\u00eb nga p\u00ebrdorimi i k\u00ebtij sistemi operativ mjaft koh\u00eb m\u00eb par\u00eb, k\u00ebshtu q\u00eb do t\u00eb ndalemi n\u00eb GNU\/Linux.<\/p>\n

Aktivizimi i p\u00ebrkthimit t\u00eb adresave nuk \u00ebsht\u00eb aspak i komplikuar. S\u00eb pari, \u00ebsht\u00eb e nevojshme t\u00eb shkruani nj\u00eb rregull n\u00eb iptables n\u00eb tabel\u00ebn nat:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nSistemi operativ do t\u00eb ngarkoj\u00eb modulin nf_conntrack, i cili do t\u00eb monitoroj\u00eb t\u00eb gjitha lidhjet aktive dhe do t\u00eb kryej\u00eb transformimet e nevojshme. Ka disa nuanca k\u00ebtu. S\u00eb pari, duke qen\u00eb se b\u00ebhet fjal\u00eb p\u00ebr NAT n\u00eb shkall\u00eb operatori t\u00eb komunikimit, \u00ebsht\u00eb e nevojshme t\u00eb rregullohen timeout-\u00ebt, sepse me vlerat standarde, madh\u00ebsia e tabel\u00ebs s\u00eb p\u00ebrkthimeve do t\u00eb rritet shum\u00eb shpejt n\u00eb nivele katastrofike. M\u00eb posht\u00eb \u00ebsht\u00eb nj\u00eb shembull i konfigurimeve q\u00eb kam p\u00ebrdorur n\u00eb server\u00ebt e mi:<\/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
\nDhe s\u00eb dyti, duke qen\u00eb se madh\u00ebsia e tabel\u00ebs s\u00eb p\u00ebrkthimeve nuk \u00ebsht\u00eb e optimizuar p\u00ebr pun\u00eb n\u00eb kushtet e nj\u00eb operatori t\u00eb komunikimit, \u00ebsht\u00eb e nevojshme ta shtojm\u00eb at\u00eb:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Gjithashtu, \u00ebsht\u00eb e nevojshme t\u00eb rritet numri i buckets p\u00ebr tabel\u00ebn e hash-it q\u00eb mban t\u00eb gjitha p\u00ebrkthimet (kjo \u00ebsht\u00eb nj\u00eb opsion i modulit nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nPas k\u00ebtyre manovrave t\u00eb thjeshta, rezulton nj\u00eb struktur\u00eb mjaft funksionale, e cila mund t\u00eb p\u00ebrkthej\u00eb nj\u00eb num\u00ebr t\u00eb madh adresash klienti n\u00eb nj\u00eb grup t\u00eb jasht\u00ebm. Megjithat\u00eb, performanca e k\u00ebtij zgjidhjeje \u00ebsht\u00eb e k\u00ebnaqshme. N\u00eb p\u00ebrpjekjet e mia t\u00eb para p\u00ebr t\u00eb p\u00ebrdorur GNU\/Linux p\u00ebr NAT (rreth vitit 2013), arrita nj\u00eb performanc\u00eb prej rreth 7Gbit\/s me 0.8Mpps n\u00eb nj\u00eb server (Xeon E5-1650v2). Q\u00eb at\u00ebher\u00eb, n\u00eb stack-un rrjetor t\u00eb kernelit GNU\/Linux jan\u00eb b\u00ebr\u00eb shum\u00eb optimizime t\u00eb ndryshme, dhe performanca e nj\u00eb serveri me t\u00eb nj\u00ebjtin hardware \u00ebsht\u00eb rritur n\u00eb pothuajse 18-19 Gbit\/s me 1.8-1.9 Mpps (k\u00ebto ishin nivele maksimale), por k\u00ebrkesa p\u00ebr sasin\u00eb e trafik po p\u00ebrpunuar nga nj\u00eb server po rritej shum\u00eb m\u00eb shpejt. N\u00eb fund, jan\u00eb zhvilluar skema balancimi ngarkese n\u00eb server\u00eb t\u00eb ndrysh\u00ebm, por t\u00eb gjitha k\u00ebto e rrit\u00ebn kompleksitetin e konfigurimit, mir\u00ebmbajtjes dhe mbajtjes s\u00eb cil\u00ebsis\u00eb s\u00eb sh\u00ebrbimeve t\u00eb ofruara.<\/p>\n
NFTables<\/h3>\n
\nNj\u00eb trend aktual n\u00eb programimin e \"transferit t\u00eb paketave\" \u00ebsht\u00eb p\u00ebrdorimi i DPDK dhe XDP. N\u00eb k\u00ebt\u00eb tem\u00eb jan\u00eb shkruar shum\u00eb artikuj, jan\u00eb mbajtur shum\u00eb prezantime dhe kan\u00eb dal\u00eb produkte komerciale (p\u00ebr shembull, SKAT nga VasExperts). Por n\u00eb kushte t\u00eb burimeve t\u00eb kufizuara t\u00eb programuesve tek operator\u00ebt e komunikimit, t\u00eb zhvillosh ndonj\u00eb \"zgjidhje\" t\u00eb till\u00eb n\u00eb baz\u00eb t\u00eb k\u00ebtyre kuadrove \u00ebsht\u00eb mjaft problematike. Shfryt\u00ebzimi i nj\u00eb zgjidhjeje t\u00eb till\u00eb m\u00eb von\u00eb do t\u00eb jet\u00eb shum\u00eb m\u00eb i komplikuar, ve\u00e7an\u00ebrisht do t\u00eb duhet t\u00eb zhvillohen mjete diagnostikimi. P\u00ebr shembull, tcpdump-i standard me DPDK nuk do t\u00eb funksionoj\u00eb thjesht, as paketat q\u00eb d\u00ebrgohen p\u00ebrs\u00ebri n\u00eb tela me ndihm\u00ebn e XDP nuk do t\u00eb \"shihen\". N\u00eb sfondin e t\u00eb gjitha bisedave p\u00ebr teknologjit\u00eb e reja t\u00eb p\u00ebrmir\u00ebsimit t\u00eb paketave n\u00eb hap\u00ebsir\u00ebn e p\u00ebrdoruesit, jan\u00eb mbetur t\u00eb paiv\u00eb n\u00eb mes referatat<\/a><\/noindex> dhe artikullit<\/a><\/noindex> Pablo Neira Ayuso, mir\u00ebmbajt\u00ebsi i iptables, p\u00ebr zhvillimin e shkarkimit t\u00eb rrjedh\u00ebs n\u00eb nftables. Le ta shqyrtojm\u00eb k\u00ebt\u00eb mekaniz\u00ebm m\u00eb holl\u00ebsisht.<\/p>\n
Ideja kryesore \u00ebsht\u00eb q\u00eb, n\u00ebse router-i ka kaluar paketat e nj\u00eb seance n\u00eb t\u00eb dy an\u00ebt e rrjedh\u00ebs (seanca TCP ka kaluar n\u00eb gjendjen ESTABLISHED), nuk ka nevoj\u00eb t\u00eb kalojn\u00eb paketat e m\u00ebtejshme t\u00eb k\u00ebsaj seance p\u00ebrmes t\u00eb gjitha rregullave t\u00eb firewall-it, sepse t\u00eb gjitha k\u00ebto kontrole do t\u00eb p\u00ebrfundojn\u00eb n\u00eb d\u00ebrgimin e paket\u00ebs m\u00eb tej n\u00eb routing. Po ashtu, nuk \u00ebsht\u00eb e nevojshme t\u00eb nd\u00ebrtohet n\u00eb rrug\u00ebn - ne tashm\u00eb e dim\u00eb se n\u00eb cilin nd\u00ebrfaqe dhe cilit host duhet t'u d\u00ebrgohen paketat brenda k\u00ebsaj seance. Mbete vet\u00ebm t\u00eb ruhet kjo informacion dhe ta p\u00ebrdorim p\u00ebr routing n\u00eb nj\u00eb faz\u00eb t\u00eb hershme t\u00eb p\u00ebrpunimit t\u00eb paket\u00ebs. N\u00eb realizimin e NAT-it \u00ebsht\u00eb e nevojshme gjithashtu t\u00eb ruhet informacioni mbi ndryshimet e adresave dhe porteve, t\u00eb transformuara nga moduli nf_conntrack. Po, sigurisht, n\u00eb k\u00ebt\u00eb rast ndalen t\u00eb funksionojn\u00eb politikat e ndryshme dhe rregullat e tjera informacion-statistike n\u00eb iptables, por n\u00eb kuad\u00ebr t\u00eb detyr\u00ebs s\u00eb nj\u00eb NAT-i t\u00eb ve\u00e7ant\u00eb ose, p\u00ebr shembull, nj\u00eb kufi - kjo nuk \u00ebsht\u00eb aq e r\u00ebnd\u00ebsishme, sepse sh\u00ebrbimet jan\u00eb t\u00eb shp\u00ebrndara n\u00eb pajisje.<\/p>\n
Konfigurimi<\/h4>\n
\nP\u00ebr t\u00eb p\u00ebrdorur k\u00ebt\u00eb funksionalitet, na nevojitet:<\/p>\n