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

I takt med att IPv4-adresserna tar slut har m\u00e5nga teleoperat\u00f6rer st\u00f6tt p\u00e5 behovet av att organisera sina kunders \u00e5tkomst till n\u00e4tet genom adress\u00f6vers\u00e4ttning. I den h\u00e4r artikeln kommer jag att g\u00e5 igenom hur man kan uppn\u00e5 Carrier Grade NAT-prestanda p\u00e5 commodity-servrar.
\n<\/a><\/noindex><\/p>\n

Lite historia<\/h3>\n

\n\u00c4mnet kring utt\u00f6mning av IPv4-adressutrymmet \u00e4r inte nytt. Vid n\u00e5gon tidpunkt uppstod det k\u00f6er i RIPE, och sedan d\u00f6k det upp b\u00f6rser d\u00e4r man handlade med adressblock och ingick avtal om deras uthyrning. Gradvis b\u00f6rjade teleoperat\u00f6rer erbjuda internet\u00e5tkomst genom adress- och port\u00f6vers\u00e4ttning. Vissa hann inte f\u00e5 tillr\u00e4ckligt med adresser f\u00f6r att kunna ge varje abonnent en \"vit\" adress, medan andra b\u00f6rjade spara pengar genom att avst\u00e5 fr\u00e5n att k\u00f6pa adresser p\u00e5 sekund\u00e4rmarknaden. Tillverkare av n\u00e4tverksutrustning st\u00f6dde denna id\u00e9, eftersom denna funktionalitet vanligtvis kr\u00e4ver ytterligare expansionsmoduler eller licenser. Till exempel, hos Juniper i MX-serien av routrar (f\u00f6rutom de senaste MX104 och MX204) kan NAPT utf\u00f6ras p\u00e5 ett separat servicekort MS-MIC, p\u00e5 Cisco ASR1k kr\u00e4vs en licens CGN, och p\u00e5 Cisco ASR9k en separat modul A9K-ISM-100 samt licens A9K-CGN-LIC till denna. Sammanfattningsvis kostar det en hel del.<\/p>\n

IPTables<\/h3>\n

\nAtt utf\u00f6ra NAT kr\u00e4ver inga specialiserade ber\u00e4kningsresurser; det kan hanteras av allm\u00e4nna processorer som finns i exempelvis vilken hemrouter som helst. P\u00e5 teleoperat\u00f6rsniv\u00e5 kan denna uppgift l\u00f6sas med commodity-servrar som k\u00f6r FreeBSD (ipfw\/pf) eller GNU\/Linux (iptables). Vi kommer inte att behandla FreeBSD h\u00e4r, eftersom jag f\u00f6r l\u00e4nge sedan slutade anv\u00e4nda detta operativsystem, s\u00e5 vi fokuserar p\u00e5 GNU\/Linux.<\/p>\n

Att aktivera adress\u00f6vers\u00e4ttning \u00e4r inte sv\u00e5rt. F\u00f6rst m\u00e5ste du skriva in en regel i iptables 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 kommer att ladda modulen nf_conntrack, som kommer att \u00f6vervaka alla aktiva anslutningar och utf\u00f6ra n\u00f6dv\u00e4ndiga transformationer. Det finns n\u00e5gra nyanser h\u00e4r. F\u00f6r det f\u00f6rsta, eftersom vi talar om NAT i stor skala av en teleoperat\u00f6r, \u00e4r det n\u00f6dv\u00e4ndigt att justera timeout-v\u00e4rdena, eftersom standardv\u00e4rdena snabbt g\u00f6r att storleken p\u00e5 \u00f6vers\u00e4ttningstabellen v\u00e4xer till katastrofala niv\u00e5er. Nedan \u00e4r ett exempel p\u00e5 inst\u00e4llningarna som jag anv\u00e4nde p\u00e5 mina servrar:<\/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
\nOch f\u00f6r det andra, eftersom standardstorleken p\u00e5 \u00f6vers\u00e4ttningstabellen inte \u00e4r avsedd f\u00f6r anv\u00e4ndning p\u00e5 operat\u00f6rsniv\u00e5, beh\u00f6ver den \u00f6kas:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Det \u00e4r ocks\u00e5 n\u00f6dv\u00e4ndigt att \u00f6ka antalet buckets f\u00f6r hash-tabellen som lagrar alla \u00f6vers\u00e4ttningar (detta \u00e4r en alternativmodul f\u00f6r nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nEfter dessa enkla manipuleringar f\u00e5r man en helt fungerande konstruktion som kan \u00f6vers\u00e4tta ett stort antal klientadresser till en pool av externa. Men prestandan hos den h\u00e4r l\u00f6sningen l\u00e4mnar mycket att \u00f6nska. Under mina f\u00f6rsta f\u00f6rs\u00f6k med att anv\u00e4nda GNU\/Linux f\u00f6r NAT (ungef\u00e4r 2013) fick jag en prestanda p\u00e5 cirka 7 Gbit\/s vid 0,8 Mpps p\u00e5 en server (Xeon E5-1650v2). Sedan dess har m\u00e5nga olika optimeringar gjorts i n\u00e4tverksstacken av k\u00e4rnan GNU\/Linux, och prestandan p\u00e5 en server med samma h\u00e5rdvara har vuxit n\u00e4stan till 18-19 Gbit\/s vid 1,8-1,9 Mpps (detta var gr\u00e4nsv\u00e4rden), men behovet av trafikvolym som hanteras av en server har v\u00e4xt mycket snabbare. S\u00e5 sm\u00e5ningom utvecklades scheman f\u00f6r lastbalansering p\u00e5 olika servrar, men allt detta \u00f6kade komplexiteten i konfigurationen, underh\u00e5llet och kvaliteten p\u00e5 de tillhandah\u00e5llna tj\u00e4nsterna.<\/p>\n
NFTables<\/h3>\n
\nJust nu \u00e4r en modeinriktning inom programvaru \"paket\u00f6verf\u00f6ring\" anv\u00e4ndningen av DPDK och XDP. Det har skrivits m\u00e5nga artiklar om detta \u00e4mne, h\u00e5llits olika presentationer, och kommersiella produkter har dykt upp (till exempel SKAT fr\u00e5n VasExperts). Men under f\u00f6rh\u00e5llandena med begr\u00e4nsade resurser hos programmerarna p\u00e5 telekomoperat\u00f6rerna \u00e4r det ganska problematiskt att sj\u00e4lva snickra ihop n\u00e5got \"projekt\" baserat p\u00e5 dessa ramverk. Att driva en s\u00e5dan l\u00f6sning vidare kommer att bli mycket mer komplicerat, s\u00e4rskilt eftersom det m\u00e5ste utvecklas diagnostikverktyg. Till exempel fungerar inte den vanliga tcpdump med DPDK s\u00e5 bra, och paket som skickas tillbaka till kablarna med XDP kommer den inte \"se\". Bland alla diskussioner om nya teknologier f\u00f6r pakethantering i anv\u00e4ndarutrymme har man missat rapporter<\/a><\/noindex> och artiklar<\/a><\/noindex> Pablo Neira Ayuso, underh\u00e5llare av iptables, om utvecklingen av flow offloading i nftables. L\u00e5t oss granska denna mekanism n\u00e4rmare.<\/p>\n
Huvudid\u00e9n \u00e4r att om routern har sl\u00e4ppt igenom paket fr\u00e5n en session i b\u00e5da riktningarna (TCP-sessionen har g\u00e5tt \u00f6ver i tillst\u00e5ndet ESTABLISHED), s\u00e5 finns det ingen anledning att l\u00e5ta de efterf\u00f6ljande paketen fr\u00e5n denna session passera genom alla brandv\u00e4ggsregler, eftersom alla dessa kontroller \u00e4nd\u00e5 kommer att sluta med att paketet skickas vidare till routing. Och valet av rutt beh\u00f6ver egentligen inte g\u00f6ras \u2013 vi vet redan vilket gr\u00e4nssnitt och vilken v\u00e4rd paketen inom denna session ska skickas till. Det \u00e5terst\u00e5r bara att spara denna information och anv\u00e4nda den f\u00f6r routing i ett tidigt skede av paketbehandlingen. N\u00e4r NAT genomf\u00f6rs m\u00e5ste dessutom information om adress- och portf\u00f6r\u00e4ndringar som omvandlats av nf_conntrack-modulen sparas. Ja, i detta fall slutar olika policys och andra informationsstatistiska regler i iptables att fungera, men inom ramen f\u00f6r uppgiften f\u00f6r en separat st\u00e5ende NAT eller till exempel en border \u2013 \u00e4r detta inte s\u00e5 viktigt, eftersom tj\u00e4nsterna \u00e4r distribuerade \u00f6ver enheter.<\/p>\n
Konfiguration<\/h4>\n
\nF\u00f6r att anv\u00e4nda denna funktion beh\u00f6ver vi:<\/p>\n