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

Etter hvert som IPv4-adressene tar slutt, har mange telekommunikasjonsoperat\u00f8rer m\u00e5ttet organisere tilgangen til nettet for kundene sine ved hjelp av adresseoversettelse. I denne artikkelen vil jeg forklare hvordan man kan oppn\u00e5 Carrier Grade NAT-ytelse p\u00e5 commodity-servere.
\n<\/a><\/noindex><\/p>\n

Litt historie<\/h3>\n

\nTemaet med utmattelse av IPv4-adresseomr\u00e5det er ikke nytt. P\u00e5 et tidspunkt dukket det opp ventelister (waiting list) i RIPE, deretter oppstod det markedsplasser hvor adresseblokker ble handlet, og avtaler for utleie ble inng\u00e5tt. Gradvis begynte telekommunikasjonsoperat\u00f8rer \u00e5 tilby internettjenester ved hjelp av adresse- og portoversettelse. Noen rakk ikke \u00e5 skaffe nok adresser til \u00e5 tildele en \"hvit\" adresse til hver abonnent, mens andre begynte \u00e5 spare midler ved \u00e5 unng\u00e5 \u00e5 kj\u00f8pe adresser p\u00e5 det sekund\u00e6re markedet. Produsenter av nettverksutstyr st\u00f8ttet denne ideen, ettersom denne funksjonaliteten vanligvis krever ekstra utvidelseskort eller lisenser. For eksempel krever det \u00e5 utf\u00f8re NAPT p\u00e5 Junipers MX-rutere (bortsett fra de nyeste MX104 og MX204) et eget tjenestekort MS-MIC, p\u00e5 Cisco ASR1k kreves CGN-lisens, mens det p\u00e5 Cisco ASR9k kreves et eget modul A9K-ISM-100 og lisens A9K-CGN-LIC for dette. Generelt sett er det ikke billig.<\/p>\n

IPTables<\/h3>\n

\n\u00c5 utf\u00f8re NAT krever ikke spesialiserte beregningsressurser; prosessorer av generell utforming, som de som brukes i enhver hjemme-ruter, kan h\u00e5ndtere dette. P\u00e5 niv\u00e5et til telekommunikasjonsoperat\u00f8rer kan denne oppgaven l\u00f8ses ved hjelp av commodity-servere drevet av FreeBSD (ipfw\/pf) eller GNU\/Linux (iptables). Vi vil ikke vurdere FreeBSD, da jeg for lengst har sluttet \u00e5 bruke dette operativsystemet, s\u00e5 vi vil fokusere p\u00e5 GNU\/Linux.<\/p>\n

Det er ikke vanskelig \u00e5 aktivere adresseoversettelse. F\u00f8rst m\u00e5 du skrive en regel i iptables til 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 laste inn nf_conntrack-modulen, som vil overv\u00e5ke alle aktive forbindelser og utf\u00f8re n\u00f8dvendige transformasjoner. Det er noen nyanser her. For det f\u00f8rste, siden vi snakker om NAT p\u00e5 niv\u00e5 med en teleoperat\u00f8r, m\u00e5 timeout-ene justeres, fordi med standardverdier vil st\u00f8rrelsen p\u00e5 oversettelsestabellen raskt vokse til katastrofale niv\u00e5er. Under er et eksempel p\u00e5 innstillinger jeg har brukt 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 andre, siden st\u00f8rrelsen p\u00e5 oversettelsestabellen som standard ikke er beregnet for drift p\u00e5 teleoperat\u00f8rniv\u00e5, m\u00e5 den \u00f8kes:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Det er ogs\u00e5 n\u00f8dvendig \u00e5 \u00f8ke antallet buckets for hash-tabellen som lagrer alle oversettelser (dette er en innstilling i modulen nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nEtter disse enkle manipuleringene f\u00e5r man en fullt fungerende konstruksjon som kan oversette et stort antall klientadresser til en pool av eksterne. Imidlertid etterlater ytelsen til denne l\u00f8sningen mye \u00e5 \u00f8nske. I mine f\u00f8rste fors\u00f8k p\u00e5 \u00e5 bruke GNU\/Linux for NAT (rundt 2013) klarte jeg \u00e5 oppn\u00e5 en ytelse p\u00e5 omtrent 7Gbit\/s ved 0.8Mpps p\u00e5 \u00e9n server (Xeon E5-1650v2). Siden den gang har det blitt gjort mange forskjellige optimaliseringer i nettverksstakken i GNU\/Linux-kjernen, og ytelsen til \u00e9n server med samme maskinvare har \u00f8kt til nesten 18-19 Gbit\/s ved 1.8-1.9 Mpps (dette var grenseverdiene), men behovet for mengden av trafikk som behandles av \u00e9n server har vokst mye raskere. Til slutt ble det utviklet lastbalanseringsordninger p\u00e5 forskjellige servere, men alt dette har \u00f8kt kompleksiteten i konfigurasjonene, vedlikeholdet og opprettholdelsen av kvaliteten p\u00e5 tjenestene som tilbys.<\/p>\n
NFTables<\/h3>\n
\nN\u00e5 er den trendy retningen innen programmering av \"pakkeoverf\u00f8ring\" bruken av DPDK og XDP. Det er skrevet mange artikler om dette emnet, gjort mange forskjellige presentasjoner, og kommersielle produkter dukker opp (for eksempel SKAT fra VasExperts). Men med begrensede ressurser blant programmererne hos teleoperat\u00f8rer, er det ganske problematisk \u00e5 utvikle et eller annet \"prosjekt\" basert p\u00e5 disse rammeverkene. \u00c5 drifte en slik l\u00f8sning videre vil v\u00e6re mye vanskeligere, spesielt m\u00e5 man utvikle diagnoseverkt\u00f8y. For eksempel, standard tcpdump vil ikke fungere med DPDK, og pakker som sendes tilbake i kablene ved hjelp av XDP, vil den ikke \"se\". I lys av alt snakket om nye teknologier for \u00e5 flytte pakkeforvaltning til user-space, har presentasjoner<\/a><\/noindex> og artikkel<\/a><\/noindex> Pablo Neira Ayuso, vedlikeholderen av iptables, om utviklingen av flow offloading i nftables. La oss se n\u00e6rmere p\u00e5 denne mekanismen.<\/p>\n
Hovedideen er at hvis ruteren har sluppet gjennom pakker fra \u00e9n \u00f8kt i begge retninger av str\u00f8mmen (TCP-\u00f8kten har g\u00e5tt inn i ESTABLISHED-tilstand), er det ikke n\u00f8dvendig \u00e5 sende de p\u00e5f\u00f8lgende pakkene fra denne \u00f8kten gjennom alle brannmurregler, ettersom alle disse kontrollene uansett vil ende med \u00e5 sende pakken videre til ruting. I tillegg er det ikke n\u00f8dvendig \u00e5 bestemme ruten \u2014 vi vet allerede hvilken grensesnitt og hvilken vert vi skal sende pakkene til innenfor denne \u00f8kten. Det er bare \u00e5 lagre denne informasjonen og bruke den til ruting tidlig i prosesseringen av pakken. N\u00e5r NAT utf\u00f8res, m\u00e5 ogs\u00e5 informasjon om endringer i adresser og porter, som er omformet av modulen nf_conntrack, lagres. Ja, i dette tilfellet slutter ulike policy- og statistikkregler i iptables \u00e5 fungere, men i konteksten av oppgaven til en enkeltst\u00e5ende NAT eller for eksempel en border \u2014 er dette ikke s\u00e5 viktig, fordi tjenestene er distribuert over enhetene.<\/p>\n
Konfigurasjon<\/h4>\n
\nFor \u00e5 dra nytte av denne funksjonen m\u00e5 vi:<\/p>\n