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

Avec l'\u00e9puisement des adresses IPv4, de nombreux op\u00e9rateurs de t\u00e9l\u00e9communications ont d\u00fb organiser l'acc\u00e8s de leurs clients au r\u00e9seau par le biais de la traduction d'adresses. Dans cet article, je vais expliquer comment obtenir des performances de niveau Carrier Grade NAT sur des serveurs classiques.
\n<\/a><\/noindex><\/p>\n

Un peu d'histoire<\/h3>\n

\nLa question de l'\u00e9puisement de l'espace d'adresses IPv4 n'est plus nouvelle. \u00c0 un certain moment, des listes d'attente sont apparues chez RIPE, puis des \u00e9changes ont vu le jour, o\u00f9 des blocs d'adresses \u00e9taient \u00e9chang\u00e9s et des contrats de location \u00e9taient conclus. Progressivement, les op\u00e9rateurs de t\u00e9l\u00e9communications ont commenc\u00e9 \u00e0 fournir des services d'acc\u00e8s \u00e0 Internet par le biais de la traduction d'adresses et de ports. Certains n'ont pas eu assez d'adresses pour attribuer une adresse \u00ab blanche \u00bb \u00e0 chaque abonn\u00e9, tandis que d'autres ont commenc\u00e9 \u00e0 \u00e9conomiser de l'argent en renon\u00e7ant \u00e0 l'achat d'adresses sur le march\u00e9 secondaire. Les fabricants de mat\u00e9riel r\u00e9seau ont soutenu cette id\u00e9e, car cette fonctionnalit\u00e9 n\u00e9cessite g\u00e9n\u00e9ralement des modules d'extension suppl\u00e9mentaires ou des licences. Par exemple, chez Juniper, dans la gamme de routeurs MX (sauf les derniers MX104 et MX204), la r\u00e9alisation de NAPT peut se faire sur une carte de service d\u00e9di\u00e9e MS-MIC, sur le Cisco ASR1k, une licence CGN est requise, et sur le Cisco ASR9k \u2014 un module s\u00e9par\u00e9 A9K-ISM-100 avec la licence A9K-CGN-LIC. En somme, cette option a un co\u00fbt non n\u00e9gligeable.<\/p>\n

IPTables<\/h3>\n

\nLa t\u00e2che d'ex\u00e9cuter le NAT ne n\u00e9cessite pas de ressources de calcul sp\u00e9cialis\u00e9es, elle peut \u00eatre r\u00e9alis\u00e9e par des processeurs g\u00e9n\u00e9ralistes, comme ceux qui sont install\u00e9s par exemple dans n'importe quel routeur domestique. \u00c0 l'\u00e9chelle d'un op\u00e9rateur de t\u00e9l\u00e9communications, ce probl\u00e8me peut \u00eatre r\u00e9solu en utilisant des serveurs classiques sous FreeBSD (ipfw\/pf) ou GNU\/Linux (iptables). Nous ne consid\u00e9rerons pas FreeBSD, car j'ai abandonn\u00e9 l'utilisation de ce syst\u00e8me d'exploitation depuis assez longtemps, nous allons donc nous concentrer sur GNU\/Linux.<\/p>\n

Activer la traduction d'adresses n'est pas tr\u00e8s compliqu\u00e9. Il suffit d'\u00e9crire une r\u00e8gle dans iptables dans la table nat :<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nLe syst\u00e8me d'exploitation chargera le module nf_conntrack, qui surveillera toutes les connexions actives et effectuera les transformations n\u00e9cessaires. Il y a quelques subtilit\u00e9s \u00e0 prendre en compte. Tout d'abord, \u00e9tant donn\u00e9 qu'il s'agit de NAT \u00e0 l'\u00e9chelle d'un op\u00e9rateur de t\u00e9l\u00e9communications, il est n\u00e9cessaire d'ajuster les d\u00e9lais d'expiration, car avec les valeurs par d\u00e9faut, la taille de la table de traductions augmentera rapidement jusqu'\u00e0 des niveaux catastrophiques. Voici un exemple de configurations que j'ai utilis\u00e9es sur mes serveurs :<\/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
\nEt deuxi\u00e8mement, puisque par d\u00e9faut la taille de la table de traductions n'est pas con\u00e7ue pour fonctionner dans un environnement d'op\u00e9rateur de t\u00e9l\u00e9communications, elle doit \u00eatre augment\u00e9e :<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Il est \u00e9galement n\u00e9cessaire d'augmenter le nombre de buckets pour la table de hachage, qui stocke toutes les traductions (c'est une option du module nf_conntrack) : <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nApr\u00e8s ces manipulations simples, on obtient une construction fonctionnelle qui peut traduire un grand nombre d'adresses clients en un pool d'adresses externes. Cependant, la performance de cette solution laisse \u00e0 d\u00e9sirer. Dans mes premi\u00e8res tentatives d'utilisation de GNU\/Linux pour NAT (environ en 2013), j'ai pu atteindre une performance d'environ 7 Gbit\/s avec 0,8 Mpps sur un serveur (Xeon E5-1650v2). Depuis, de nombreuses optimisations ont \u00e9t\u00e9 apport\u00e9es \u00e0 la pile r\u00e9seau du noyau GNU\/Linux, et la performance d'un serveur sur le m\u00eame mat\u00e9riel a pratiquement augment\u00e9 \u00e0 18-19 Gbit\/s avec 1,8-1,9 Mpps (ce furent des valeurs limites), mais le besoin de volume de trafic trait\u00e9 par un seul serveur a augment\u00e9 beaucoup plus rapidement. En fin de compte, des sch\u00e9mas de r\u00e9partition de la charge entre diff\u00e9rents serveurs ont \u00e9t\u00e9 \u00e9labor\u00e9s, mais tout cela a augment\u00e9 la complexit\u00e9 de la configuration, de la maintenance et du maintien de la qualit\u00e9 des services fournis.<\/p>\n
NFTables<\/h3>\n
\nActuellement, une tendance populaire dans l'\u00ab empilement de paquets \u00bb est l'utilisation de DPDK et XDP. Ce sujet a suscit\u00e9 de nombreux articles, plusieurs pr\u00e9sentations ont \u00e9t\u00e9 r\u00e9alis\u00e9es, et des produits commerciaux sont apparus (par exemple, SKAT de VasExperts). Cependant, dans un contexte de ressources limit\u00e9es pour les d\u00e9veloppeurs chez les op\u00e9rateurs de t\u00e9l\u00e9communications, cr\u00e9er soi-m\u00eame une \u00ab solution \u00bb bas\u00e9e sur ces frameworks est assez probl\u00e9matique. Exploiter une telle solution par la suite sera beaucoup plus compliqu\u00e9, notamment en ce qui concerne le d\u00e9veloppement d'outils de diagnostic. Par exemple, l'outil tcpdump standard avec DPDK ne fonctionnera pas simplement, et il ne \u00ab verra \u00bb pas non plus les paquets renvoy\u00e9s sur les lignes \u00e0 l'aide de XDP. Au milieu de toutes les discussions sur les nouvelles technologies de transfert de paquets vers l'espace utilisateur, sont rest\u00e9es inaper\u00e7ues les rapports<\/a><\/noindex> et article<\/a><\/noindex> Pablo Neira Ayuso, le mainteneur d'iptables, sur le d\u00e9veloppement de l'externalisation de flux dans nftables. Examinons ce m\u00e9canisme plus en d\u00e9tail.<\/p>\n
L'id\u00e9e principale est que si le routeur a trait\u00e9 des paquets d'une m\u00eame session dans les deux sens du flux (la session TCP est pass\u00e9e \u00e0 l'\u00e9tat ESTABLISHED), il n'est pas n\u00e9cessaire de faire passer les paquets suivants de cette session par toutes les r\u00e8gles du pare-feu, car toutes ces v\u00e9rifications se soldront de toute fa\u00e7on par la transmission du paquet pour un routage ult\u00e9rieur. De plus, il n'est pas n\u00e9cessaire de choisir un itin\u00e9raire \u2014 nous savons d\u00e9j\u00e0 \u00e0 quel interface et \u00e0 quel h\u00f4te envoyer les paquets dans le cadre de cette session. Il ne reste qu'\u00e0 conserver cette information et \u00e0 l'utiliser pour le routage \u00e0 un stade pr\u00e9coce du traitement du paquet. Lors de l'ex\u00e9cution de NAT, il est \u00e9galement n\u00e9cessaire de conserver des informations sur les modifications d'adresses et de ports effectu\u00e9es par le module nf_conntrack. Oui, bien s\u00fbr, dans ce cas, divers analyseurs et d'autres r\u00e8gles de statistique d'information dans iptables ne fonctionneront plus, mais dans le cadre de la t\u00e2che d'un NAT distinct ou, par exemple, d'une fronti\u00e8re \u2014 ce n'est pas si important, car les services sont r\u00e9partis sur diff\u00e9rents appareils.<\/p>\n
Configuration<\/h4>\n
\nPour profiter de cette fonctionnalit\u00e9, nous devons :<\/p>\n