{"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\/da\/blog\/administrirovanie\/bystryj-routing-i-nat-v-linux","title":{"rendered":"Hurtig routing og NAT i Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Som IPv4-adresserne bliver udt\u00f8mt, st\u00e5r mange teleoperat\u00f8rer over for n\u00f8dvendigheden af at organisere adgang til nettet for deres kunder gennem adresseovers\u00e6ttelse. I denne artikel vil jeg forklare, hvordan man kan opn\u00e5 ydeevne p\u00e5 niveau med Carrier Grade NAT p\u00e5 commodity-servere.
\n<\/a><\/noindex><\/p>\n

Lidt historie<\/h3>\n

\nTemaet om udt\u00f8mning af IPv4-adressens rum er ikke nyt. P\u00e5 et tidspunkt opstod der ventelister i RIPE, og derefter dukkede der markeder op, hvor blokke af adresser blev handlet og lejeaftaler blev indg\u00e5et. Langsomt begyndte teleoperat\u00f8rer at tilbyde internetadgang ved hj\u00e6lp af adresse- og portovers\u00e6ttelse. Nogle havde ikke f\u00e5et nok adresser til at give hver kunde en 'hvid' adresse, mens andre begyndte at spare penge ved at afst\u00e5 fra at k\u00f8be adresser p\u00e5 det sekund\u00e6re marked. Producenterne af netv\u00e6rksudstyr st\u00f8ttede denne id\u00e9, da denne funktion normalt kr\u00e6ver ekstra udvidelseskort eller licenser. For eksempel, hos Juniper i deres MX-routerline (bortset fra de nyeste MX104 og MX204) kan man udf\u00f8re NAPT p\u00e5 et separat servicekort MS-MIC, p\u00e5 Cisco ASR1k kr\u00e6ves en CGN-licens, og p\u00e5 Cisco ASR9k kr\u00e6ves et separat modul A9K-ISM-100 samt licensen A9K-CGN-LIC. Generelt koster det en del penge.<\/p>\n

IPTables<\/h3>\n

\nOpgaven med at udf\u00f8re NAT kr\u00e6ver ingen specialiserede beregningsressourcer, da almindelige CPU'er, som dem der findes i enhver hjemmerouter, kan l\u00f8se den. I teleoperat\u00f8rernes skala kan denne opgave l\u00f8ses ved hj\u00e6lp af commodity-servere, der k\u00f8rer FreeBSD (ipfw\/pf) eller GNU\/Linux (iptables). Vi vil ikke overveje FreeBSD, da jeg har opgivet at bruge dette operativsystem for l\u00e6ngere tid siden, s\u00e5 lad os fokusere p\u00e5 GNU\/Linux.<\/p>\n

Det er slet ikke sv\u00e6rt at aktivere adresseovers\u00e6ttelse. F\u00f8rst skal du skrive en regel i iptables ind i nat-tabellen:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nOperativsystemen vil indl\u00e6se nf_conntrack-modulet, som vil overv\u00e5ge alle aktive forbindelser og udf\u00f8re de n\u00f8dvendige transformationer. Der er nogle nuancer her. For det f\u00f8rste, da vi taler om NAT i stor skala for en telekommunikationsudbyder, er det n\u00f8dvendigt at justere timeouts, fordi tabellen for overs\u00e6ttelser med standardv\u00e6rdierne hurtigt vil vokse til katastrofale st\u00f8rrelser. Nedenfor er et eksempel p\u00e5 de indstillinger, jeg har brugt p\u00e5 mine servere:<\/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
\nFor det andet, da st\u00f8rrelsen p\u00e5 overs\u00e6ttelsestabellen som standard ikke er beregnet til at fungere under en operat\u00f8r, skal den \u00f8ges:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Det er ogs\u00e5 n\u00f8dvendigt at \u00f8ge antallet af buckets til hash-tabellen, der gemmer alle overs\u00e6ttelser (dette er en mulighed i modulet nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nEfter disse enkle manipulationer f\u00e5r man en fuldt fungerende konstruktion, der kan overs\u00e6tte et stort antal klientadresser til en pulje af eksterne adresser. Men ydeevnen af denne l\u00f8sning er ikke tilfredsstillende. I mine f\u00f8rste fors\u00f8g med at bruge GNU\/Linux til NAT (omkring 2013) kunne jeg opn\u00e5 en ydeevne p\u00e5 omkring 7 Gbit\/s ved 0,8 Mpps p\u00e5 en server (Xeon E5-1650v2). Siden da er der foretaget mange forskellige optimeringer i det netv\u00e6rksstak i GNU\/Linux-kernen, og ydeevnen p\u00e5 en enkelt server med den samme hardware er steget til n\u00e6sten 18-19 Gbit\/s ved 1,8-1,9 Mpps (dette var gr\u00e6nsev\u00e6rdier), men behovet for den m\u00e6ngde trafik, der behandles af en enkelt server, er steget meget hurtigere. Som et resultat er der udviklet lastbalanceringsordninger for forskellige servere, men alt dette har \u00f8get kompleksiteten ved konfiguration, vedligeholdelse og sikring af kvalitetsservice.<\/p>\n
NFTables<\/h3>\n
\nI dag er en popul\u00e6r trend inden for programmering af 'pakkeoml\u00e6gning' brugen af DPDK og XDP. Der er skrevet mange artikler om dette emne, lavet forskellige pr\u00e6sentationer, og kommercielle produkter som SKAT fra VasExperts er begyndt at dukke op. Men i en situation med begr\u00e6nsede ressourcer blandt programm\u00f8rer hos teleoperat\u00f8rer kan det v\u00e6re ret problematisk at udvikle en eller anden 'l\u00f8sning' baseret p\u00e5 disse rammer selv. Det vil ogs\u00e5 v\u00e6re meget sv\u00e6rere at implementere en s\u00e5dan l\u00f8sning senere hen, is\u00e6r da der vil v\u00e6re behov for at udvikle diagnostiske v\u00e6rkt\u00f8jer. For eksempel vil standard tcpdump ikke fungere med DPDK, og pakker sendt tilbage i ledningerne med XDP vil den ikke 'se'. Bag alle samtalerne om nye teknologier til at sende pakker til user-space er der blevet overset foredrag<\/a><\/noindex> og artikler<\/a><\/noindex> Pablo Neira Ayuso, vedligeholder af iptables, om udviklingen af flow offloading i nftables. Lad os se n\u00e6rmere p\u00e5 denne mekanisme.<\/p>\n
Den grundl\u00e6ggende id\u00e9 er, at hvis routeren har ladet pakker fra \u00e9n session passere i begge retninger af str\u00f8mmen (TCP-sessionen er g\u00e5et ind i tilstanden ESTABLISHED), er der ikke behov for at lade de f\u00f8lgende pakker fra denne session g\u00e5 gennem alle firewall-reglerne, da alle disse kontroller alligevel vil ende med at sende pakken videre til routing. Og valget af rute beh\u00f8ver faktisk ikke at udf\u00f8res \u2014 vi ved allerede, hvilken interface og hvilken v\u00e6rt pakkerne skal videresendes til inden for denne session. Der er kun behov for at gemme denne information og bruge den til routing i den tidlige fase af pakkebehandlingen. Ved udf\u00f8relse af NAT er det n\u00f8dvendigt yderligere at gemme information om \u00e6ndringerne af adresser og porte, som er blevet transformeret af modulet nf_conntrack. Ja, selvf\u00f8lgelig vil forskellige polysere og andre informations- og statistiske regler i iptables stoppe med at fungere, men i forbindelse med opgaven med en separat NAT eller f.eks. en border-router er det ikke s\u00e5 vigtigt, fordi tjenesterne er distribueret p\u00e5 enhederne.<\/p>\n
Konfiguration<\/h4>\n
\nFor at bruge denne funktion skal vi:<\/p>\n