{"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 kalimin e adresave IPv4, shum\u00eb operator\u00eb t\u00eb telekomunikacionit jan\u00eb ballafaquar me nevoj\u00ebn p\u00ebr t\u00eb organizuar qasjen e klient\u00ebve t\u00eb tyre n\u00eb rrjet p\u00ebrmes p\u00ebrkthimit t\u00eb adresave. N\u00eb k\u00ebt\u00eb artikull do t\u00eb flas p\u00ebr se si mund t\u00eb arrihet performanca e nivelit Carrier Grade NAT n\u00eb serverat e zakonsh\u00ebm.
\n<\/a><\/noindex><\/p>\n

Pak histori<\/h3>\n

\nTema e shterimit t\u00eb hap\u00ebsir\u00ebs IP IPv4 nuk \u00ebsht\u00eb e re. N\u00eb nj\u00eb moment, paraqit\u00ebn lista pritjeje n\u00eb RIPE, pastaj u shfaq\u00ebn bursa ku tregoheshin blloqet e adresave dhe merren marr\u00ebveshje p\u00ebr qiradh\u00ebnie. Gradually, operator\u00ebt e telekomunikacionit filluan t\u00eb ofronin sh\u00ebrbime interneti p\u00ebrmes p\u00ebrkthimit t\u00eb adresave dhe porteve. Disa nuk arrit\u00ebn t\u00eb merrnin mjaft adresat p\u00ebr t\u00eb dh\u00ebn\u00eb nj\u00eb adres\u00eb \"t\u00eb bardh\u00eb\" p\u00ebr \u00e7do abonent, nd\u00ebrsa disa filluan t\u00eb kursenin duke hequr dor\u00eb nga blerja e adresave n\u00eb tregun e dyt\u00eb. Prodhuesit e pajisjeve rrjet\u00ebsore e mb\u00ebshtet\u00ebn k\u00ebt\u00eb ide, pasi ky funksionalitet zakonisht k\u00ebrkon module shtes\u00eb ose licenca. P\u00ebr shembull, te Juniper, n\u00eb linj\u00ebn e routerave MX (p\u00ebrve\u00e7 MX104 dhe MX204 t\u00eb fundit), kryerja e NAPT mund t\u00eb b\u00ebhet n\u00eb nj\u00eb kart\u00eb sh\u00ebrbimi t\u00eb ve\u00e7ant\u00eb MS-MIC, te Cisco ASR1k k\u00ebrkohet licence CGN, te Cisco ASR9k \u2013 nj\u00eb moduli t\u00eb ve\u00e7ant\u00eb A9K-ISM-100 dhe licenca A9K-CGN-LIC p\u00ebr t\u00eb. N\u00eb p\u00ebrgjith\u00ebsi, k\u00ebnaq\u00ebsia kushton shum\u00eb.<\/p>\n

IPTables<\/h3>\n

\nDetyra e kryerjes s\u00eb NAT nuk k\u00ebrkon burime t\u00eb specializuara t\u00eb p\u00ebrpunimit, e cila 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\u00ebpie. N\u00eb shkall\u00ebn e operator\u00ebve t\u00eb telekomunikacionit, kjo detyr\u00eb mund t\u00eb zgjidhet duke p\u00ebrdorur serverat e zakonsh\u00ebm n\u00ebn FreeBSD (ipfw\/pf) ose GNU\/Linux (iptables). Nuk do ta shqyrtojm\u00eb FreeBSD, pasi un\u00eb e kam hequr dor\u00eb q\u00eb nj\u00eb koh\u00eb t\u00eb gjat\u00eb nga p\u00ebrdorimi i k\u00ebtij OS, k\u00ebshtu q\u00eb do t\u00eb fokusohemi n\u00eb GNU\/Linux.<\/p>\n

Aktivizimi i p\u00ebrkthimit t\u00eb adresave nuk \u00ebsht\u00eb aspak e v\u00ebshtir\u00eb. P\u00ebr fillim, duhet 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 modulimin nf_conntrack, i cili do t\u00eb mbaj\u00eb n\u00ebn mbik\u00ebqyrje t\u00eb gjitha lidhjet aktive dhe do t\u00eb b\u00ebj\u00eb transformimet e nevojshme. K\u00ebtu ka disa nuanca. S\u00eb pari, pasi flasim p\u00ebr NAT n\u00eb shkall\u00eb t\u00eb operatorit t\u00eb komunikimeve, \u00ebsht\u00eb e nevojshme t\u00eb rregullohen timeout-et, sepse me vlerat e paracaktuara, madh\u00ebsia e tabel\u00ebs s\u00eb p\u00ebrkthimit do t\u00eb rritet shum\u00eb shpejt n\u00eb p\u00ebrmasa 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, pasi madh\u00ebsia e tabel\u00ebs s\u00eb p\u00ebrkthimit nuk \u00ebsht\u00eb e llogaritur t\u00eb funksionoj\u00eb n\u00eb kushte operatori t\u00eb komunikimit, \u00ebsht\u00eb e nevojshme q\u00eb t\u00eb rritet:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n \u00cbsht\u00eb gjithashtu e nevojshme t\u00eb rritet edhe numri i buckets p\u00ebr tabel\u00ebn me hash, q\u00eb ruan 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, krijohet nj\u00eb konstrukcion mjaft funksional, i cili mund t\u00eb p\u00ebrkthej\u00eb nj\u00eb num\u00ebr t\u00eb madh t\u00eb adresave t\u00eb klient\u00ebve n\u00eb nj\u00eb grup t\u00eb jashtme. Sidoqoft\u00eb, performanca e k\u00ebtij zgjidhjeje l\u00eb p\u00ebr t\u00eb d\u00ebshiruar. N\u00eb p\u00ebrpjekjet e mia t\u00eb para p\u00ebr t\u00eb p\u00ebrdorur GNU\/Linux p\u00ebr NAT (rreth vitit 2013) arrita t\u00eb merrja nj\u00eb performanc\u00eb rreth 7Gbit\/s me 0.8Mpps n\u00eb nj\u00eb server (Xeon E5-1650v2). Q\u00eb nga at\u00ebher\u00eb, ka pasur shum\u00eb optimizime t\u00eb ndryshme n\u00eb grushtin e rrjetit t\u00eb kernelit GNU\/Linux, dhe performanca e nj\u00eb serveri me t\u00eb nj\u00ebjtin hardware \u00ebsht\u00eb rritur pothuajse n\u00eb 18-19 Gbit\/s me 1.8-1.9 Mpps (k\u00ebto ishin vlerat maksimale), por k\u00ebrkesa p\u00ebr volum trafik q\u00eb p\u00ebrpunonte nj\u00eb server erdhi duke u rritur shum\u00eb m\u00eb shpejt. Si rezultat, u zhvilluan skema t\u00eb balancimit t\u00eb ngarkes\u00ebs n\u00eb server\u00eb t\u00eb ndrysh\u00ebm, por gjith\u00e7ka ka rritur kompleksitetin e konfigurimit, mb\u00ebshtetjes dhe ruajtjes s\u00eb cil\u00ebsis\u00eb s\u00eb sh\u00ebrbimeve t\u00eb ofruara.<\/p>\n
NFTables<\/h3>\n
\nAktualisht, nj\u00eb trend i njohur n\u00eb \"transferimin e paketave\" \u00ebsht\u00eb p\u00ebrdorimi i DPDK dhe XDP. N\u00eb k\u00ebt\u00eb tem\u00eb jan\u00eb shkruar shum\u00eb artikuj, jan\u00eb b\u00ebr\u00eb shum\u00eb paraqitje t\u00eb ndryshme dhe po shfaqen produkte komerciale (p\u00ebr shembull, SKAT nga VasExperts). Por n\u00eb kushte t\u00eb burimeve t\u00eb kufizuara p\u00ebr programuesit e operator\u00ebve t\u00eb komunikimit, \u00ebsht\u00eb mjaft problematike t\u00eb zhvillosh ndonj\u00eb \"ndar\u00ebs\" n\u00eb baz\u00eb t\u00eb k\u00ebtyre kornizave. Eksplorimi i nj\u00eb zgjidhjeje t\u00eb till\u00eb m\u00eb von\u00eb do t\u00eb jet\u00eb shum\u00eb m\u00eb i komplikuar, sidomos p\u00ebr zhvillimin e mjeteve t\u00eb diagnostikimit. P\u00ebr shembull, tcpdump standard me DPDK nuk do t\u00eb funksionoj\u00eb leht\u00ebsisht, po ashtu as paketat e d\u00ebrguara prapa n\u00eb linj\u00eb me ndihm\u00ebn e XDP nuk do t\u00eb \"shihen\". N\u00eb kontekstin e t\u00eb gjitha bisedave p\u00ebr teknologjit\u00eb e reja q\u00eb kan\u00eb lidhje me forwarding-un e paketave n\u00eb hap\u00ebsir\u00ebn e p\u00ebrdoruesit, jan\u00eb mbetur t\u00eb pap\u00ebrfillura referatet<\/a><\/noindex> dhe artikulli<\/a><\/noindex> Pablo Neira Ayuso, mbajt\u00ebsi i iptables, rreth zhvillimit t\u00eb flow offloading n\u00eb nftables. Le t\u00eb shqyrtojm\u00eb k\u00ebt\u00eb mekaniz\u00ebm m\u00eb n\u00eb detaje.<\/p>\n
Ideja kryesore \u00ebsht\u00eb se n\u00ebse rrug\u00ebzuesi i kalon paketat e nj\u00eb seance n\u00eb t\u00eb dyja an\u00ebt e rrjedh\u00ebs (seanca TCP ka kaluar n\u00eb gjendjen ESTABLISHED), at\u00ebher\u00eb nuk ka nevoj\u00eb p\u00ebr kalimin e paketave t\u00eb m\u00ebtejshme t\u00eb k\u00ebsaj seance p\u00ebrmes t\u00eb gjitha rregullave t\u00eb firewall-it, pasi t\u00eb gjitha k\u00ebto kontrollime p\u00ebrfundimisht do t\u00eb p\u00ebrfundojn\u00eb me kalimin e paketit n\u00eb rrug\u00ebzim. Po ashtu, zgjedhja e rrug\u00ebs nuk duhet t\u00eb b\u00ebhet \u2014 ne tashm\u00eb e dim\u00eb n\u00eb cilin nd\u00ebrfaqe dhe cilit host duhet t'i d\u00ebrgohen paketat brenda k\u00ebsaj seance. Mbete vet\u00ebm t\u00eb ruash k\u00ebt\u00eb informacion dhe ta p\u00ebrdor\u00ebsh p\u00ebr rrug\u00ebzim n\u00eb faz\u00ebn e hershme t\u00eb p\u00ebrpunimit t\u00eb paket\u00ebve. Gjat\u00eb realizimit t\u00eb NAT-it duhet 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 ndalohen t\u00eb punojn\u00eb policer\u00ebt e ndrysh\u00ebm dhe rregullat e tjera informativo-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, t\u00eb nj\u00eb interfejsi \u2014 kjo nuk \u00ebsht\u00eb kaq e r\u00ebnd\u00ebsishme, pasi sh\u00ebrbimet jan\u00eb t\u00eb shp\u00ebrndara n\u00eb pajisje.<\/p>\n
Konfigurimi<\/h4>\n
\nP\u00ebr t\u00eb shfryt\u00ebzuar k\u00ebt\u00eb funksion na nevojitet:<\/p>\n