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

Con l'esaurirsi degli indirizzi IPv4, molti operatori di telecomunicazioni si sono trovati nella necessit\u00e0 di organizzare l'accesso alla rete dei propri clienti attraverso la traduzione degli indirizzi. In questo articolo spiegher\u00f2 come ottenere prestazioni di livello Carrier Grade NAT su server commodity.
\n<\/a><\/noindex><\/p>\n

Un po' di storia<\/h3>\n

\nIl tema dell'esaurimento dello spazio degli indirizzi IPv4 non \u00e8 nuovo. A un certo punto, in RIPE, sono apparse liste d'attesa, poi sono nate borse in cui si scambiavano blocchi di indirizzi e si stipulavano contratti di affitto. Gradualmente, gli operatori di telecomunicazioni hanno iniziato a fornire servizi di accesso a Internet attraverso la traduzione di indirizzi e porte. Alcuni non sono riusciti a ottenere un numero sufficiente di indirizzi per assegnare un indirizzo 'pubblico' a ciascun utente, mentre altri hanno iniziato a risparmiare denaro rifiutandosi di acquistare indirizzi sul mercato secondario. I produttori di apparecchiature di rete hanno sostenuto questa idea, poich\u00e9 questa funzionalit\u00e0 richiede solitamente moduli di espansione o licenze aggiuntive. Ad esempio, per Juniper nella serie di router MX (eccetto i pi\u00f9 recenti MX104 e MX204), eseguire NAPT \u00e8 possibile su una scheda di servizio separata MS-MIC, su Cisco ASR1k \u00e8 necessaria la licenza CGN, mentre su Cisco ASR9k \u00e8 necessario un modulo separato A9K-ISM-100 e la licenza A9K-CGN-LIC. In generale, il divertimento ha un costo considerevole.<\/p>\n

IPTables<\/h3>\n

\nIl compito di eseguire NAT non richiede risorse computazionali specializzate; pu\u00f2 essere gestito da processori generici, come quelli installati in qualsiasi router domestico. A livello di un operatore di telecomunicazioni, questo compito pu\u00f2 essere affrontato utilizzando server commodity con FreeBSD (ipfw\/pf) o GNU\/Linux (iptables). Non considereremo FreeBSD, dato che ho smesso di usare questo sistema operativo da un bel po', quindi ci concentreremo su GNU\/Linux.<\/p>\n

Abilitare la traduzione degli indirizzi non \u00e8 affatto complicato. Per iniziare, \u00e8 necessario scrivere una regola in iptables nella tabella nat:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nIl sistema operativo caricher\u00e0 il modulo nf_conntrack, che monitorer\u00e0 tutte le connessioni attive ed eseguir\u00e0 le necessarie trasformazioni. Ci sono alcune particolarit\u00e0. In primo luogo, poich\u00e9 si tratta di NAT su larga scala per un operatore di telecomunicazioni, \u00e8 necessario regolare i timeout, perch\u00e9 con i valori predefiniti la dimensione della tabella delle traduzioni crescer\u00e0 rapidamente a valori catastrofici. Di seguito un esempio delle impostazioni che ho utilizzato sui miei server:<\/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
\nIn secondo luogo, poich\u00e9 per impostazione predefinita la dimensione della tabella di traduzione non \u00e8 progettata per l'uso da parte di un operatore di comunicazione, deve essere aumentata:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n \u00c8 anche necessario aumentare il numero di buckets per la tabella hash che memorizza tutte le traduzioni (questa \u00e8 un'opzione del modulo nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nDopo queste semplici manipolazioni, si ottiene una configurazione perfettamente funzionante in grado di tradurre un gran numero di indirizzi client in un pool di indirizzi esterni. Tuttavia, le prestazioni di questa soluzione lasciano a desiderare. Nei miei primi tentativi di utilizzare GNU\/Linux per NAT (circa nel 2013), sono riuscito a raggiungere prestazioni di circa 7Gbit\/s con 0.8Mpps su un server (Xeon E5-1650v2). Da allora, nel stack di rete del kernel GNU\/Linux sono state implementate molte diverse ottimizzazioni, e le prestazioni di un singolo server con la stessa configurazione sono praticamente aumentate fino a 18-19 Gbit\/s con 1.8-1.9 Mpps (questi erano i valori massimi), ma la domanda sul volume del traffico trattato da un singolo server \u00e8 cresciuta molto pi\u00f9 rapidamente. Di conseguenza, sono stati sviluppati schemi di bilanciamento del carico su pi\u00f9 server, ma tutto ci\u00f2 ha aumentato la complessit\u00e0 della configurazione, della manutenzione e del mantenimento della qualit\u00e0 dei servizi erogati.<\/p>\n
NFTables<\/h3>\n
\nAttualmente, la tendenza nel 'riassegnare pacchetti' nei programmi \u00e8 l'uso di DPDK e XDP. Sono stati scritti numerosi articoli su questo argomento, ci sono state molte presentazioni diverse e sono nati prodotti commerciali (ad esempio, SKAT di VasExperts). Tuttavia, nel contesto delle risorse limitate dei programmatori nei fornitori di servizi di telecomunicazione, sviluppare autonomamente un 'oggetto' basato su questi framework \u00e8 piuttosto problematico. Sfruttare tale soluzione in seguito sar\u00e0 molto pi\u00f9 difficile, in particolare, sar\u00e0 necessario sviluppare strumenti di diagnostica. Ad esempio, il classico tcpdump con DPDK non funzioner\u00e0 semplicemente, e nemmeno i pacchetti inviati di nuovo nei cavi tramite XDP saranno 'visibili'. Tra tutte le chiacchiere sulle nuove tecnologie di invio del forwarding dei pacchetti nello user-space, sono passati inosservati relazioni<\/a><\/noindex> e sul CommunityHelpWiki (sullo stesso dominio<\/a><\/noindex> Pablo Neira Ayuso, mantenitore di iptables, sulla progettazione del flow offloading in nftables. Esaminiamo questo meccanismo pi\u00f9 nel dettaglio.<\/p>\n
L'idea principale \u00e8 che se il router ha fatto passare pacchetti di una sessione in entrambe le direzioni del flusso (la sessione TCP \u00e8 passata allo stato ESTABLISHED), non \u00e8 necessario far passare i pacchetti successivi di quella sessione attraverso tutte le regole del firewall, poich\u00e9 tutti questi controlli si concluderanno comunque con la trasmissione del pacchetto nel routing. Inoltre, non c'\u00e8 bisogno di eseguire anche la scelta del percorso \u2014 sappiamo gi\u00e0 in quale interfaccia e a quale host inviare i pacchetti all'interno di questa sessione. Rimane solo da salvare queste informazioni e utilizzarle per il routing nelle fasi iniziali del trattamento del pacchetto. Durante l'esecuzione del NAT, \u00e8 necessario conservare ulteriormente le informazioni sulle modifiche degli indirizzi e delle porte, trasformate dal modulo nf_conntrack. Certo, in questo caso smettono di funzionare vari polizieri e altre regole statistiche informative in iptables, ma nel contesto della funzione di un NAT singolo o, ad esempio, di un bordo, non \u00e8 cos\u00ec rilevante, perch\u00e9 i servizi sono distribuiti su pi\u00f9 dispositivi.<\/p>\n
Configurazione<\/h4>\n
\nPer utilizzare questa funzione dobbiamo:<\/p>\n