{"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\/es\/blog\/administrirovanie\/bystryj-routing-i-nat-v-linux","title":{"rendered":"Enrutamiento r\u00e1pido y NAT en Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A medida que se agotan las direcciones IPv4, muchos operadores de telecomunicaciones se han enfrentado a la necesidad de proporcionar acceso a sus clientes a la red mediante la traducci\u00f3n de direcciones. En este art\u00edculo, explicar\u00e9 c\u00f3mo se puede alcanzar un rendimiento de nivel Carrier Grade NAT en servidores comerciales.
\n<\/a><\/noindex><\/p>\n

Un poco de historia<\/h3>\n

\nEl tema del agotamiento del espacio de direcciones IPv4 ya no es nuevo. En alg\u00fan momento surgieron listas de espera en RIPE, luego aparecieron intercambios donde se comerciaban bloques de direcciones y se firmaban contratos para su alquiler. Poco a poco, los operadores de telecomunicaciones comenzaron a ofrecer servicios de acceso a Internet mediante la traducci\u00f3n de direcciones y puertos. Algunos no lograron obtener suficientes direcciones para asignar una direcci\u00f3n 'p\u00fablica' a cada suscriptor, mientras que otros comenzaron a economizar, renunciando a la compra de direcciones en el mercado secundario. Los fabricantes de equipos de red apoyaron esta idea, ya que esta funcionalidad normalmente requiere m\u00f3dulos de expansi\u00f3n o licencias adicionales. Por ejemplo, en Juniper, en la l\u00ednea de enrutadores MX (excepto los \u00faltimos MX104 y MX204), realizar NAPT se puede hacer en una tarjeta de servicio separada MS-MIC, en Cisco ASR1k se requiere la licencia CGN, y en Cisco ASR9k se necesita un m\u00f3dulo separado A9K-ISM-100 y la licencia A9K-CGN-LIC correspondiente. En general, esto no es barato.<\/p>\n

IPTables<\/h3>\n

\nLa tarea de realizar NAT no requiere recursos computacionales especializados, puede ser manejada por procesadores de prop\u00f3sito general, como los que se encuentran en cualquier enrutador dom\u00e9stico. A nivel de operador de telecomunicaciones, esta tarea se puede resolver utilizando servidores comerciales que funcionen con FreeBSD (ipfw\/pf) o GNU\/Linux (iptables). No examinaremos FreeBSD ya que hace tiempo abandon\u00e9 el uso de este sistema operativo, as\u00ed que nos centraremos en GNU\/Linux.<\/p>\n

Activar la traducci\u00f3n de direcciones no es complicado. Para comenzar, es necesario escribir una regla en iptables en la tabla nat:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nEl sistema operativo cargar\u00e1 el m\u00f3dulo nf_conntrack, que supervisar\u00e1 todas las conexiones activas y realizar\u00e1 las transformaciones necesarias. Hay algunas sutilezas aqu\u00ed. Primero, dado que se trata de NAT a escala de operador de telecomunicaciones, es necesario ajustar los tiempos de espera, porque con los valores predeterminados el tama\u00f1o de la tabla de traducciones crecer\u00e1 r\u00e1pidamente a valores catastr\u00f3ficos. A continuaci\u00f3n, un ejemplo de la configuraci\u00f3n que utilic\u00e9 en mis servidores:<\/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
\nY en segundo lugar, dado que el tama\u00f1o de la tabla de traducci\u00f3n por defecto no est\u00e1 dise\u00f1ado para operar en condiciones de un operador de telecomunicaciones, es necesario aumentar su tama\u00f1o:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Tambi\u00e9n es necesario aumentar la cantidad de buckets para la tabla hash que almacena todas las traducciones (esta es una opci\u00f3n del m\u00f3dulo nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nDespu\u00e9s de estas sencillas manipulaciones, se obtiene una estructura que puede traducir una gran cantidad de direcciones de clientes en un grupo de direcciones externas. Sin embargo, el rendimiento de esta soluci\u00f3n deja mucho que desear. En mis primeros intentos de usar GNU\/Linux para NAT (aproximadamente en 2013), pude alcanzar un rendimiento de alrededor de 7Gbit\/s a 0.8Mpps en un servidor (Xeon E5-1650v2). Desde entonces, se han realizado muchas optimizaciones en la pila de red del n\u00facleo de GNU\/Linux, y el rendimiento de un servidor con el mismo hardware ha crecido pr\u00e1cticamente a 18-19 Gbit\/s a 1.8-1.9 Mpps (estos fueron los valores extremos), pero la demanda de volumen de tr\u00e1fico procesado por un solo servidor ha crecido mucho m\u00e1s r\u00e1pido. Como resultado, se desarrollaron esquemas de balanceo de carga en diferentes servidores, pero todo esto increment\u00f3 la complejidad de la configuraci\u00f3n, el mantenimiento y la garant\u00eda de calidad de los servicios prestados.<\/p>\n
NFTables<\/h3>\n
\nActualmente, la tendencia de moda en el \"reenv\u00edo de paquetes\" es el uso de DPDK y XDP. Se han escrito muchos art\u00edculos sobre este tema, se han realizado diversas presentaciones y aparecen productos comerciales (por ejemplo, SKAT de VasExperts). Sin embargo, en el contexto de recursos limitados de programadores en los operadores de telecomunicaciones, crear alguna \"creaci\u00f3n\" basada en estos marcos es bastante problem\u00e1tico. Adem\u00e1s, explotar tal soluci\u00f3n en el futuro ser\u00e1 mucho m\u00e1s complicado, ya que ser\u00e1 necesario desarrollar herramientas de diagn\u00f3stico. Por ejemplo, el tcpdump est\u00e1ndar no funcionar\u00e1 con DPDK, y los paquetes enviados de vuelta a los cables mediante XDP no ser\u00e1n \"vistos\". En medio de todas las discusiones sobre nuevas tecnolog\u00edas de reenv\u00edo de paquetes en user-space, han pasado desapercibidos informes<\/a><\/noindex> y art\u00edculo<\/a><\/noindex> Pablo Neira Ayuso, mantenedor de iptables, sobre el desarrollo de flow offloading en nftables. Examinemos este mecanismo en detalle.<\/p>\n
La idea principal es que si un enrutador ha permitido que los paquetes de una sesi\u00f3n vayan en ambas direcciones (la sesi\u00f3n TCP ha alcanzado el estado ESTABLISHED), no es necesario pasar los paquetes subsecuentes de esta sesi\u00f3n a trav\u00e9s de todas las reglas del firewall, ya que todas estas comprobaciones terminar\u00e1n en la transmisi\u00f3n del paquete hacia el enrutamiento. Adem\u00e1s, no es necesario realizar la elecci\u00f3n de la ruta, porque ya sabemos a qu\u00e9 interfaz y a qu\u00e9 host se deben enviar los paquetes dentro de esta sesi\u00f3n. Solo queda guardar esta informaci\u00f3n y utilizarla para la ruta en la fase inicial del procesamiento del paquete. Al realizar NAT, tambi\u00e9n es necesario guardar informaci\u00f3n sobre los cambios en las direcciones y puertos, transformados por el m\u00f3dulo nf_conntrack. S\u00ed, por supuesto, en este caso, varios poliseres y otras reglas de informaci\u00f3n-estad\u00edsticas en iptables dejar\u00e1n de funcionar, pero en el marco de la tarea de un NAT independiente o, por ejemplo, un border, esto no es tan importante, porque los servicios est\u00e1n distribuidos entre los dispositivos.<\/p>\n
Configuraci\u00f3n<\/h4>\n
\nPara utilizar esta funci\u00f3n necesitamos:<\/p>\n