{"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\/pl\/blog\/administrirovanie\/bystryj-routing-i-nat-v-linux","title":{"rendered":"Szybkie routowanie i NAT w systemie Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

W miar\u0119 wyczerpywania si\u0119 adres\u00f3w IPv4, wielu operator\u00f3w telekomunikacyjnych zmierzy\u0142o si\u0119 z konieczno\u015bci\u0105 organizacji dost\u0119pu swoich klient\u00f3w do sieci za pomoc\u0105 translacji adres\u00f3w. W tym artykule opowiem, jak mo\u017cna osi\u0105gn\u0105\u0107 wydajno\u015b\u0107 na poziomie Carrier Grade NAT na serwerach typu commodity.
\n<\/a><\/noindex><\/p>\n

Historia<\/h3>\n

\nTemat wyczerpywania si\u0119 przestrzeni adresowej IPv4 przesta\u0142 by\u0107 nowo\u015bci\u0105. W pewnym momencie w RIPE pojawi\u0142y si\u0119 listy oczekuj\u0105cych, a nast\u0119pnie zacz\u0119\u0142y powstawa\u0107 gie\u0142dy, na kt\u00f3rych handlowano blokami adres\u00f3w oraz zawierano transakcje dotycz\u0105ce ich wynajmu. Z czasem operatorzy telekomunikacyjni zacz\u0119li oferowa\u0107 us\u0142ugi dost\u0119pu do Internetu za pomoc\u0105 translacji adres\u00f3w i port\u00f3w. Niekt\u00f3rzy nie zd\u0105\u017cyli uzyska\u0107 wystarczaj\u0105cej liczby adres\u00f3w, aby przydzieli\u0107 \"bia\u0142y\" adres ka\u017cdemu abonentowi, a inni zacz\u0119li oszcz\u0119dza\u0107, rezygnuj\u0105c z zakupu adres\u00f3w na rynku wt\u00f3rnym. Producenci sprz\u0119tu sieciowego wsparli t\u0119 ide\u0119, poniewa\u017c ten funkcjonalno\u015b\u0107 zazwyczaj wymaga dodatkowych modu\u0142\u00f3w rozszerze\u0144 lub licencji. Na przyk\u0142ad produkuj\u0105c routery MX, firma Juniper (z wyj\u0105tkiem najnowszych MX104 i MX204) umo\u017cliwia wykonywanie NAPT na oddzielnej karcie serwisowej MS-MIC, podczas gdy na Cisco ASR1k wymagana jest licencja CGN, a na Cisco ASR9k \u2014 oddzielny modu\u0142 A9K-ISM-100 oraz licencja A9K-CGN-LIC do niego. Generalnie, zabawa ta nie jest tania.<\/p>\n

IPTables<\/h3>\n

\nZadanie wykonywania NAT nie wymaga specjalistycznych zasob\u00f3w obliczeniowych; mog\u0105 si\u0119 nim zaj\u0105\u0107 procesory og\u00f3lnego przeznaczenia, kt\u00f3re s\u0105 zainstalowane przyk\u0142adowo w ka\u017cdym domowym routerze. Na poziomie operatora telekomunikacyjnego zadanie to mo\u017cna rozwi\u0105za\u0107, korzystaj\u0105c z serwer\u00f3w commodity zarz\u0105dzanych przez FreeBSD (ipfw\/pf) lub GNU\/Linux (iptables). Nie b\u0119dziemy rozwa\u017ca\u0107 FreeBSD, poniewa\u017c od do\u015b\u0107 dawna zrezygnowa\u0142em z u\u017cywania tego systemu operacyjnego, wi\u0119c skupimy si\u0119 na GNU\/Linux.<\/p>\n

W\u0142\u0105czenie translacji adres\u00f3w nie jest wcale trudne. Na pocz\u0105tek nale\u017cy wprowadzi\u0107 regu\u0142\u0119 w iptables do tabeli nat:<\/p>\n

iptables -t nat -A POSTROUTING -s 100.64.0.0\/10 -j SNAT --to - --persistent\n<\/code><\/pre>\n
\nSystem operacyjny za\u0142adowuje modu\u0142 nf_conntrack, kt\u00f3ry b\u0119dzie \u015bledzi\u0107 wszystkie aktywne po\u0142\u0105czenia i wykonywa\u0107 niezb\u0119dne przekszta\u0142cenia. Istnieje kilka niuans\u00f3w. Po pierwsze, poniewa\u017c m\u00f3wimy o NAT w skali operatora telekomunikacyjnego, konieczne jest dostosowanie timeout\u00f3w, poniewa\u017c przy warto\u015bciach domy\u015blnych rozmiar tabeli translacji szybko wzro\u015bnie do katastrofalnych rozmiar\u00f3w. Poni\u017cej przyk\u0142ad ustawie\u0144, kt\u00f3re u\u017cy\u0142em na swoich serwerach:<\/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
\nPo drugie, poniewa\u017c domy\u015blny rozmiar tabeli translacji nie jest dostosowany do pracy w warunkach operatora telekomunikacyjnego, nale\u017cy go zwi\u0119kszy\u0107:<\/p>\n
net.netfilter.nf_conntrack_max = 3145728\n<\/code><\/pre>\n
\n Nale\u017cy tak\u017ce zwi\u0119kszy\u0107 liczb\u0119 buckets w tablicy haszyuj\u0105cych, kt\u00f3ra przechowuje wszystkie translacje (to opcja modu\u0142u nf_conntrack): <\/p>\n
options nf_conntrack hashsize=1572864\n<\/code><\/pre>\n
\nPo tych prostych manipulacjach otrzymujemy dobrze dzia\u0142aj\u0105c\u0105 konstrukcj\u0119, kt\u00f3ra mo\u017ce t\u0142umaczy\u0107 du\u017c\u0105 liczb\u0119 adres\u00f3w klient\u00f3w na pul\u0119 zewn\u0119trznych. Jednak wydajno\u015b\u0107 tego rozwi\u0105zania pozostawia wiele do \u017cyczenia. W swoich pierwszych pr\u00f3bach wykorzystania GNU\/Linux do NAT (oko\u0142o 2013 roku) uda\u0142o mi si\u0119 osi\u0105gn\u0105\u0107 wydajno\u015b\u0107 oko\u0142o 7Gbit\/s przy 0.8Mpps na jeden serwer (Xeon E5-1650v2). Od tego czasu w stosie sieciowym j\u0105dra GNU\/Linux wprowadzono wiele r\u00f3\u017cnych optymalizacji, a wydajno\u015b\u0107 jednego serwera na tym samym sprz\u0119cie wzros\u0142a praktycznie do 18-19 Gbit\/s przy 1.8-1.9 Mpps (by\u0142y to warto\u015bci graniczne), ale potrzeba w zakresie przetwarzanego ruchu przez jeden serwer ros\u0142a znacznie szybciej. Ostatecznie opracowano schematy r\u00f3wnowa\u017cenia obci\u0105\u017cenia na r\u00f3\u017cne serwery, co zwi\u0119kszy\u0142o z\u0142o\u017cono\u015b\u0107 konfiguracji, utrzymania i zapewnienia jako\u015bci \u015bwiadczonych us\u0142ug.<\/p>\n
NFTables<\/h3>\n
\nObecnie modnym trendem w programowym \u201eprzek\u0142adaniu pakiet\u00f3w\u201d jest stosowanie DPDK i XDP. Na ten temat napisano wiele artyku\u0142\u00f3w, odby\u0142o si\u0119 wiele r\u00f3\u017cnych wyst\u0105pie\u0144, a na rynku pojawi\u0142y si\u0119 komercyjne produkty (na przyk\u0142ad SKAT od VasExperts). Jednak w warunkach ograniczonych zasob\u00f3w programist\u00f3w w\u015br\u00f3d operator\u00f3w telekomunikacyjnych, samodzielne tworzenie jakiego\u015b \u201ewynalazku\u201d na bazie tych framework\u00f3w jest do\u015b\u0107 problematyczne. Wykorzystywanie takiego rozwi\u0105zania w przysz\u0142o\u015bci b\u0119dzie o wiele trudniejsze, szczeg\u00f3lnie dlatego, \u017ce konieczne b\u0119dzie opracowanie narz\u0119dzi diagnostycznych. Na przyk\u0142ad standardowy tcpdump z DPDK nie zadzia\u0142a, a pakiety wysy\u0142ane z powrotem do sieci za pomoc\u0105 XDP nie b\u0119d\u0105 przez niego \u201ewidziane\u201d. W obliczu wszystkich rozm\u00f3w na temat nowych technologii przesy\u0142ania pakiet\u00f3w w przestrzeni u\u017cytkownika, umkn\u0119\u0142y te sprawozdania<\/a><\/noindex> i artyku\u0142u<\/a><\/noindex> Pablo Neira Ayuso, maintainer iptables, na temat rozwoju flow offloading w nftables. Przyjrzyjmy si\u0119 temu mechanizmowi bli\u017cej.<\/p>\n
G\u0142\u00f3wna idea polega na tym, \u017ce je\u015bli router przepu\u015bci\u0142 pakiety jednej sesji w obie strony strumienia (sesja TCP przesz\u0142a w stan ESTABLISHED), to nie ma potrzeby przepuszczania kolejnych pakiet\u00f3w tej sesji przez wszystkie zasady zapory, poniewa\u017c wszystkie te kontrole i tak zako\u0144cz\u0105 si\u0119 przekazaniem pakietu dalej do routingu. W\u0142a\u015bciwie r\u00f3wnie\u017c nie trzeba podejmowa\u0107 decyzji co do trasy \u2014 ju\u017c wiemy, na kt\u00f3ry interfejs i do kt\u00f3rego hosta nale\u017cy przekaza\u0107 pakiety w ramach tej sesji. Pozostaje tylko zachowa\u0107 te informacje i wykorzysta\u0107 je do routingu na wczesnym etapie przetwarzania pakietu. Przy wykonywaniu NAT konieczne jest dodatkowe zachowanie informacji o zmianach adres\u00f3w i port\u00f3w, przekszta\u0142conych przez modu\u0142 nf_conntrack. Tak, oczywi\u015bcie, w takim przypadku przestaj\u0105 dzia\u0142a\u0107 r\u00f3\u017cne policery i inne informacje\/statystyczne zasady w iptables, ale w ramach zadania oddzielnego NAT-u lub na przyk\u0142ad bordera \u2014 nie jest to a\u017c tak istotne, poniewa\u017c us\u0142ugi s\u0105 rozproszone na urz\u0105dzeniach.<\/p>\n
Konfiguracja<\/h4>\n
\nAby skorzysta\u0107 z tej funkcji, musimy:<\/p>\n