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

Naarmate IPv4-adressen opraken, zijn veel telecomoperators geconfronteerd met de noodzaak om hun klanten toegang tot het netwerk te bieden via adresvertaling. In dit artikel zal ik uitleggen hoe je Carrier Grade NAT-prestaties kunt behalen op commodity-servers.
\n<\/a><\/noindex><\/p>\n

Een beetje geschiedenis<\/h3>\n

\nHet onderwerp van de uitputting van het IPv4-adresblok is al geruime tijd niet nieuw. Op een gegeven moment verschenen er wachtlijsten bij RIPE, en er ontstonden markten waar blokken adressen werden verhandeld en overeenkomsten voor verhuur werden gesloten. Geleidelijk aan begonnen telecomoperators internettoegang te bieden via adres- en poortvertaling. Sommigen hebben niet genoeg adressen gekregen om elke abonnee een \u2018wit\u2019 adres te geven, terwijl anderen begonnen met besparen en geen adressen op de secundaire markt wilden kopen. Fabrikanten van netwerkapparatuur steunden dit idee, omdat deze functionaliteit vaak extra uitbreidingsmodules of licenties vereist. Bijvoorbeeld, bij Juniper kan NAPT uitgevoerd worden op een aparte servicekaart MS-MIC in de MX-routerlijn (behalve de laatste MX104 en MX204), bij Cisco ASR1k is een CGN-licentie vereist, en bij Cisco ASR9k een aparte module A9K-ISM-100 met de licentie A9K-CGN-LIC. Over het algemeen kost dit geen kleine som.<\/p>\n

IPTables<\/h3>\n

\nDe taak van NAT vereist geen gespecialiseerde rekencapaciteit, dit kan worden opgelost met standaard processors die bijvoorbeeld in elke thuisrouter zijn ge\u00efnstalleerd. Op het niveau van telecomoperators kan deze taak worden uitgevoerd met commodity-servers die draaien op FreeBSD (ipfw\/pf) of GNU\/Linux (iptables). We zullen FreeBSD niet beschouwen, omdat ik deze OS al geruime tijd niet meer gebruik, dus concentreren we ons op GNU\/Linux.<\/p>\n

Adresvertaling inschakelen is helemaal niet moeilijk. Begin met het toevoegen van een regel in iptables in de nat-tabel:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nHet besturingssysteem laadt de nf_conntrack-module, die alle actieve verbindingen zal volgen en de nodige transformaties zal uitvoeren. Er zijn verschillende nuances. Ten eerste, omdat het gaat om NAT op operatorniveau, moeten de time-outs worden aangepast, omdat de standaardwaarden ervoor zorgen dat de grootte van de vertaalgegevens al snel tot catastrofale waarden groeit. Hieronder een voorbeeld van de instellingen die ik op mijn servers heb gebruikt:<\/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
\nEn ten tweede, omdat de standaardgrootte van de vertaaltafel niet is ontworpen voor gebruik in een telecomomgeving, moet deze worden vergroot:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Het aantal buckets voor de hash-tabel die alle vertalingen opslaat moet ook worden vergroot (dit is een optie van de nf_conntrack-module): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nNa deze eenvoudige aanpassingen is er een volledig functionele opstelling ontstaan die een groot aantal cli\u00ebntadressen kan vertalen naar een pool van externe adressen. Echter, de prestaties van deze oplossing zijn niet optimaal. In mijn eerste pogingen om GNU\/Linux voor NAT te gebruiken (ongeveer 2013) kon ik prestaties halen van ongeveer 7Gbit\/s bij 0.8Mpps op \u00e9\u00e9n server (Xeon E5-1650v2). Sindsdien zijn er vele optimalisaties in de netwerkstack van de GNU\/Linux-kernel aangebracht, en de prestaties van \u00e9\u00e9n server met dezelfde hardware zijn praktisch gestegen naar 18-19 Gbit\/s bij 1.8-1.9 Mpps (dit waren de maximale waarden), maar de behoefte aan het volume dat door \u00e9\u00e9n server moest worden verwerkt, groeide veel sneller. Uiteindelijk werden er schema\u2019s ontwikkeld voor load balancing over verschillende servers, maar dit verhoogde de complexiteit van de configuratie, onderhoud en de kwaliteit van de geleverde diensten.<\/p>\n
NFTables<\/h3>\n
\nMomenteel is een populaire trend in het programmeren van \"pakketten doorschuiven\" het gebruik van DPDK en XDP. Over dit onderwerp zijn talloze artikelen geschreven, zijn er verschillende presentaties gegeven en verschijnen er commerci\u00eble producten (bijvoorbeeld SKAT van VasExperts). Maar onder de omstandigheden van beperkte middelen bij programmeurs van telecomoperators is het behoorlijk problematisch om zelf een soort \"project\" op basis van deze frameworks te ontwikkelen. Het is namelijk veel moeilijker om een dergelijke oplossing verder te exploiteren, met name omdat er diagnose-instrumenten ontwikkeld moeten worden. Bijvoorbeeld, de standaard tcpdump werkt niet zomaar met DPDK, en de pakketten die via XDP terug de kabels in worden gestuurd, zullen niet \"zichtbaar\" zijn voor deze tool. Tegen de achtergrond van alle gesprekken over nieuwe technologie\u00ebn voor het doorsturen van pakketten in de gebruikersruimte zijn de presentaties<\/a><\/noindex> en artikel<\/a><\/noindex> Pablo Neira Ayuso, maintainer van iptables, over de ontwikkeling van flow offloading in nftables. Laten we dit mechanisme nader bekijken.<\/p>\n
Het basisidee is dat als de router pakketten van \u00e9\u00e9n sessie in beide richtingen van de stroom (TCP-sessie is in de toestand ESTABLISHED gegaan) heeft doorgelaten, er geen noodzaak is om de volgende pakketten van deze sessie door alle firewall-regels te laten gaan, aangezien al deze controles uiteindelijk toch zullen resulteren in de doorgifte van het pakket voor verdere routing. Bovendien is het kiezen van een route niet nodig \u2014 we weten al naar welke interface en aan welk host we de pakketten binnen deze sessie moeten doorsturen. Het blijft alleen om deze informatie op te slaan en te gebruiken voor routing in een vroeg stadium van de pakketverwerking. Bij het uitvoeren van NAT moet bovendien informatie over de wijzigingen in adressen en poorten, die door de nf_conntrack-module zijn omgezet, worden opgeslagen. Ja, natuurlijk, in dit geval werken verschillende policers en andere informatief-statistische regels in iptables niet meer, maar binnen de context van de taak van een afzonderlijke NAT-implementatie of bijvoorbeeld een border is dat niet zo belangrijk, omdat de services over apparaten verspreid zijn.<\/p>\n
Configuratie<\/h4>\n
\nOm gebruik te maken van deze functie moeten we:<\/p>\n