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

Com a escassez de endere\u00e7os IPv4, muitos provedores de telecomunica\u00e7\u00f5es se viram na necessidade de organizar o acesso de seus clientes \u00e0 rede por meio de tradu\u00e7\u00e3o de endere\u00e7os. Neste artigo, vou explicar como obter um desempenho de n\u00edvel Carrier Grade NAT em servidores comuns.
\n<\/a><\/noindex><\/p>\n

Um pouco de hist\u00f3ria<\/h3>\n

\nA quest\u00e3o da escassez do espa\u00e7o de endere\u00e7os IPv4 j\u00e1 n\u00e3o \u00e9 nova. Em algum momento, surgiram filas de espera na RIPE, depois surgiram mercados onde blocos de endere\u00e7os eram negociados e contratos de aluguel eram firmados. Gradualmente, os provedores de telecomunica\u00e7\u00f5es come\u00e7aram a oferecer servi\u00e7os de acesso \u00e0 Internet por meio de tradu\u00e7\u00e3o de endere\u00e7os e portas. Alguns n\u00e3o conseguiram obter endere\u00e7os suficientes para atribuir um endere\u00e7o 'p\u00fablico' a cada assinante, enquanto outros come\u00e7aram a economizar, desistindo da compra de endere\u00e7os no mercado secund\u00e1rio. Os fabricantes de equipamentos de rede apoiaram essa ideia, pois essa funcionalidade geralmente requer m\u00f3dulos de expans\u00e3o ou licen\u00e7as adicionais. Por exemplo, a Juniper, em sua linha de roteadores MX (exceto os mais recentes MX104 e MX204), pode executar NAPT em um cart\u00e3o de servi\u00e7o MS-MIC separado, no Cisco ASR1k \u00e9 necess\u00e1ria uma licen\u00e7a CGN, e no Cisco ASR9k \u2014 um m\u00f3dulo A9K-ISM-100 separado com a licen\u00e7a A9K-CGN-LIC correspondente. Em resumo, o prazer custa caro.<\/p>\n

IPTables<\/h3>\n

\nA tarefa de realizar NAT n\u00e3o requer recursos computacionais especializados, podendo ser realizada por processadores de uso geral, como os que est\u00e3o instalados, por exemplo, em qualquer roteador dom\u00e9stico. Em escala de provedores de telecomunica\u00e7\u00f5es, essa tarefa pode ser resolvida utilizando servidores comuns rodando FreeBSD (ipfw\/pf) ou GNU\/Linux (iptables). N\u00e3o vamos considerar o FreeBSD, pois h\u00e1 bastante tempo desisti de usar esse SO, por isso vamos nos concentrar no GNU\/Linux.<\/p>\n

Ativar a tradu\u00e7\u00e3o de endere\u00e7os n\u00e3o \u00e9 dif\u00edcil. Para come\u00e7ar, \u00e9 necess\u00e1rio adicionar uma regra ao iptables na tabela nat:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nO sistema operacional carregar\u00e1 o m\u00f3dulo nf_conntrack, que monitorar\u00e1 todas as conex\u00f5es ativas e realizar\u00e1 as transforma\u00e7\u00f5es necess\u00e1rias. Existem algumas sutilezas aqui. Primeiro, uma vez que se trata de NAT em larga escala de um provedor de servi\u00e7os, \u00e9 preciso ajustar os timeouts, pois com os valores padr\u00e3o, o tamanho da tabela de tradu\u00e7\u00f5es crescer\u00e1 rapidamente para valores catastr\u00f3ficos. Abaixo est\u00e1 um exemplo das configura\u00e7\u00f5es que utilizei em meus 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
\nE em segundo lugar, uma vez que o tamanho da tabela de tradu\u00e7\u00f5es por padr\u00e3o n\u00e3o \u00e9 projetado para opera\u00e7\u00e3o em um ambiente de operadora, ele precisa ser aumentado:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Tamb\u00e9m \u00e9 necess\u00e1rio aumentar o n\u00famero de buckets para a tabela de hash que armazena todas as tradu\u00e7\u00f5es (esta \u00e9 uma op\u00e7\u00e3o do m\u00f3dulo nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nAp\u00f3s essas simples manobras, obtemos uma estrutura funcionando completamente capaz de traduzir um grande n\u00famero de endere\u00e7os de clientes para um pool externo. No entanto, o desempenho desta solu\u00e7\u00e3o deixa a desejar. Em minhas primeiras tentativas de usar GNU\/Linux para NAT (cerca de 2013), consegui obter um desempenho de cerca de 7 Gbit\/s a 0,8 Mpps em um \u00fanico servidor (Xeon E5-1650v2). Desde ent\u00e3o, muitas otimiza\u00e7\u00f5es foram feitas no stack de rede do kernel GNU\/Linux; o desempenho de um servidor com o mesmo hardware cresceu praticamente para 18-19 Gbit\/s a 1,8-1,9 Mpps (valores m\u00e1ximos), mas a demanda por volume de tr\u00e1fego processado por um \u00fanico servidor cresceu muito mais rapidamente. Como resultado, esquemas de balanceamento de carga para diferentes servidores foram desenvolvidos, mas tudo isso aumentou a complexidade da configura\u00e7\u00e3o, manuten\u00e7\u00e3o e qualidade dos servi\u00e7os prestados.<\/p>\n
NFTables<\/h3>\n
\nAtualmente, uma tend\u00eancia popular no \"empilhamento de pacotes\" \u00e9 o uso de DPDK e XDP. Muitos artigos foram escritos sobre o tema, diversas apresenta\u00e7\u00f5es foram feitas e produtos comerciais est\u00e3o surgindo (como SKAT da VasExperts). No entanto, devido \u00e0 escassez de programadores nas operadoras de telecomunica\u00e7\u00f5es, desenvolver uma solu\u00e7\u00e3o pr\u00f3pria baseada nesses frameworks \u00e9 bastante problem\u00e1tico. A utiliza\u00e7\u00e3o subsequente de tal solu\u00e7\u00e3o ser\u00e1 muito mais complexa, pois ser\u00e1 necess\u00e1rio desenvolver ferramentas de diagn\u00f3stico. Por exemplo, o tcpdump padr\u00e3o n\u00e3o funcionar\u00e1 com DPDK, e os pacotes enviados de volta pelos cabos usando XDP n\u00e3o ser\u00e3o \"vistos\" por ele. Entre todas as discuss\u00f5es sobre novas tecnologias de encaminhamento de pacotes para o espa\u00e7o do usu\u00e1rio, ficaram sem aten\u00e7\u00e3o. apresenta\u00e7\u00f5es<\/a><\/noindex> e artigo<\/a><\/noindex> Pablo Neira Ayuso, mantenedor do iptables, sobre o desenvolvimento do flow offloading no nftables. Vamos examinar esse mecanismo mais detalhadamente.<\/p>\n
A ideia principal \u00e9 que, se um roteador passou pacotes de uma sess\u00e3o em ambas as dire\u00e7\u00f5es do fluxo (a sess\u00e3o TCP passou para o estado ESTABLISHED), n\u00e3o h\u00e1 necessidade de passar os pacotes subsequentes dessa sess\u00e3o por todas as regras do firewall, pois todas essas verifica\u00e7\u00f5es acabar\u00e3o resultando na transmiss\u00e3o do pacote para o roteamento. E tamb\u00e9m n\u00e3o \u00e9 necess\u00e1rio escolher a rota \u2014 j\u00e1 sabemos para qual interface e qual host devemos encaminhar os pacotes dentro dessa sess\u00e3o. Apenas \u00e9 necess\u00e1rio salvar essas informa\u00e7\u00f5es e utiliz\u00e1-las para o roteamento na fase inicial de processamento do pacote. Ao realizar NAT, \u00e9 necess\u00e1rio tamb\u00e9m preservar informa\u00e7\u00f5es sobre as mudan\u00e7as de endere\u00e7os e portas, que foram transformadas pelo m\u00f3dulo nf_conntrack. Sim, claro, nesse caso diversas pol\u00edticas e outras regras informativas-estat\u00edsticas no iptables deixam de funcionar, mas para a tarefa de um NAT isolado ou, por exemplo, na borda, isso n\u00e3o \u00e9 t\u00e3o importante, pois os servi\u00e7os est\u00e3o distribu\u00eddos entre os dispositivos.<\/p>\n
Configura\u00e7\u00e3o<\/h4>\n
\nPara aproveitar essa funcionalidade, precisamos:<\/p>\n