Jump to content
Калькуляторы

Assymetric NAT на Linux

1 час назад, LostSoul сказал:

кажется я начал вспоминать, возможно там дело в аппаратной проверке  crc на сетевухе.   сегодня проверю.

нет

23 минуты назад, LostSoul сказал:

ситуация специфична для debian начиная с какого-то обновления

с ядра 3.4 или 3.5, непомню точно.

 

Нужно понимать как работает вообще НАТ для того, чтоб починить :)

 

Так а чего тебе вдруг микротик не подошел, а, LostSoul ?

 

Share this post


Link to post
Share on other sites

Господа, большая просьба обсуждение работы конттрака перенести в другое место. Тут всё-таки о ядерном модуле тема.

Хотелось бы видеть опыт внедрения, если кто-то уже решился.

Share this post


Link to post
Share on other sites

Мое ИМХО, что времена самодельных BRAS и CGNAT в основном прошли.

Сейчас есть обкатанные аппаратные решения разной степени доступности.

Share this post


Link to post
Share on other sites

38 минут назад, alibek сказал:

Мое ИМХО, что времена самодельных BRAS и CGNAT в основном прошли.

Сейчас есть обкатанные аппаратные решения разной степени доступности.

Полноценную замену smartedge для QinQ IPoE (aka dot1q subscriber) так и не нашли пока. А на smartedge производитель похоже забил.

 

По теме: никто не пробовал вот эту штуку как NAT Box: https://wiki.fd.io/view/VPP https://wiki.fd.io/view/VPP/NAT ?

Share this post


Link to post
Share on other sites

Итак, я внедрил на одном из серверов (BRAS +BORDER):

root@gw1:~# uname -r
3.16.0-7-amd64
root@gw1:~# accel-cmd show stat
uptime: 107.08:11:44
cpu: 0%
mem(rss/virt): 12172/134184 kB
core:
  mempool_allocated: 4841775
  mempool_available: 1413623
  thread_count: 1
  thread_active: 1
  context_count: 3237
  context_sleeping: 0
  context_pending: 0
  md_handler_count: 1722
  md_handler_pending: 0
  timer_count: 3371
  timer_pending: 0
sessions:
  starting: 0
  active: 1672
  finishing: 1
ipoe:
  starting: 0
  active: 1673
  delayed: 0
radius...........
root@gw1:~# cat /etc/debian_version
8.11
root@gw1:~# cat /proc/sys/net/netfilter/nf_conntrack_count
189
root@gw1:~# cat /proc/net/NAT/statistics
Active NAT sessions: 49288
Tried NAT sessions: 9028921
Created NAT sessions: 9026387
DNAT dropped pkts: 34247488
Fragmented pkts: 0
Related ICMP pkts: 2254633
Active Users: 1408

Все юзеры переведены с conntrack на ipt_NAT. CPU 2*E5645 @ 2.4GHz;

Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

В среднем нагрузка за счет отключения conntrack упала в два раза, посмотрю и сравню в ЧНН. (на модуль преключился около 11:00 19.07 на графике)

 

CGNAT_load.png

Edited by SABRE

Share this post


Link to post
Share on other sites

6 часов назад, a290 сказал:

Полноценную замену smartedge для QinQ IPoE (aka dot1q subscriber) так и не нашли пока. А на smartedge производитель похоже забил.

 

По теме: никто не пробовал вот эту штуку как NAT Box: https://wiki.fd.io/view/VPP https://wiki.fd.io/view/VPP/NAT ?

хм интересно. погуглил , есть упоминание о нем на ffrouting

 

https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes%3A-VPP

Share this post


Link to post
Share on other sites

18 часов назад, SABRE сказал:

вообще интересно) iptables -t raw -nvL 

iptables -t nat -nvL

может оно уже чем-то до этого натится?

conntrack | grep gre

нет. других правил просто нет.

никаких соединений для gre не создается в conntrack (для указанного трафика )

для других типов трафика - создаются. ( по тем же самым правилам prerouting netmap и postrouting netmap )

iptables неплохо представляю себе в деталях, во времена rhel3/ kernel 2.6.18  сам писал себе несложные модули типа хитрого load balancer.

 

вроде бы с какой-то версии там это все теперь транслируется в flow через прослойку совместимости.

или ядра  4.15.18-15-pve это еще не касается?

 

Share this post


Link to post
Share on other sites

@LostSoul я предлагаю перейти в отдельную тему. Что касается GRE, то нашел это:

What has changed with the 3.18.x kernel : if neither nf_conntrack_pptp
nor nf_conntrack_proto_gre are loaded, any GRE packet is INVALID.

Не могут пакеты просто так пропадать в ядре. Посмотрите в момент создания соединения conntrack -E (events)

 

 

 

@all

Итак по прошествию ЧНН могу заключить что нагрузка упала вдвое, что вполне ожидаемо изза полного отключения conntrack. Когда-то мы уже подходили к этому вопросу и выключали его доя пользователей с белым IP, что дало пропорциональное снижение нагрузкию Здесь же получилось убрать conntrack полностью.

CGNAT_load.png

Edited by SABRE

Share this post


Link to post
Share on other sites

Круто. Жаль что не могу себе позволить отказать в сервисах пользователям, которые не работают через этот модуль :( Лучше куплю ещё один сервак и раскину нагрузку, чем буду объяснять, что не могу дать сервис из-за нехватки мощи.

Edited by TriKS

Share this post


Link to post
Share on other sites

17 минут назад, TriKS сказал:

Круто. Жаль что не могу себе позволить отказать в сервисах пользователям, которые не работают через этот модуль :( Лучше куплю ещё один сервак и раскину нагрузку, чем буду объяснять, что не могу дать сервис из-за нехватки мощи.

 

В каких сервисах?

Share this post


Link to post
Share on other sites

@uzd подскажите как выполняется распределение пользователей по нат пулу. Старается ли модуль как больше утилизировать пул, чтобы на один внешний адрес приходилось как можно меньше меньше внутренних?

И на что вы спрыгнули с серваков и зачем собственно?

Share this post


Link to post
Share on other sites

16 минут назад, TriKS сказал:

No ALGs for FTP/SIP/PPTP are implemented

ИМХО актуален только VPN.

Для SIP по правильному нужно белый IP, а пассивный FTP вообще не проблема.

Share this post


Link to post
Share on other sites

1 hour ago, TriKS said:

У меня есть пптп клиентура.

Возможно пртестю по свободе, пока не до этого.

Ну не знаю, Pptp в 19году... У нас сейчас жалоб не было.

Share this post


Link to post
Share on other sites

10 hours ago, vurd said:

@uzd подскажите как выполняется распределение пользователей по нат пулу. Старается ли модуль как больше утилизировать пул, чтобы на один внешний адрес приходилось как можно меньше меньше внутренних?

И на что вы спрыгнули с серваков и зачем собственно?

Алгорим выбора NAT IP из пула работает через хэш-функцию, на вход которой передаются 3 параметра:  IP клиента, NAT Pool Start, NAT Pool End.

В результате клиенты размазываются по NAT пулу достаточно равномерно, при этом одному и тому же внутреннему IP всегда назначается один и тот же внешний IP из пула адресов.

Перенесли функцию CGN на оборудование одного крупного китайского вендора (не Huawei) с техподдержкой и запасом производительности в сотни гигабит - модуль NAT был написан для менее амбициозных задач - для сети с трафиком до 40-80 гигабит, и он свою роль уже выполнил.

 

10 hours ago, TriKS said:

Круто. Жаль что не могу себе позволить отказать в сервисах пользователям, которые не работают через этот модуль :( Лучше куплю ещё один сервак и раскину нагрузку, чем буду объяснять, что не могу дать сервис из-за нехватки мощи.

 

Я на все 200% не тестировал различные кейсы работы PPTP через данный модуль NAT, но в большинстве случаев оно должно работать и без ALG. Аналогично для SIP и Passive FTP.

Модуль эти протоколы никак не блокирует, а вполне корректно пропускает через себя с заменой IP-адресов и портов в заголовках L3/L4 + пересчитывает CRC где нужно.

 

8 hours ago, vurd said:

И я так понимаю nat fragments тоже не поддерживается. (printk(KERN_DEBUG "xt_NAT DEBUG: Drop fragmented IP packet\n");)

Фрагментированные пакеты работают, просто все фрагменты сначала собираются в один большой пакет ядром Linux, и только потом передаются в Iptables.

Данный участок кода написан на случай, если кто-нибудь сможет выключить сбор фрагментов на стороне ядра Linux (а это не слишком просто)

Share this post


Link to post
Share on other sites

1 hour ago, uzd said:

Я на все 200% не тестировал различные кейсы работы PPTP через данный модуль NAT, но в большинстве случаев оно должно работать и без ALG.

Прежде всего спасибо за Вашу работу - модуль действитеьно очень нужет и является хорошим решением между stateless NAT via iproute и stateful conntrack NAT.

Проверил на тестовом сервере - действительно NAT для GRE отрабатывает, но в сессиях записи об этом протоколе нет. Дописал часть правил чтобы клиентов, которые используют PPTP натить через conntrack:

ipset -N -! ct_fallback hash:ip

iptables -t raw -A PREROUTING -s <grey_net> -p tcp --dport 1723 -m set ! --match-set ct_fallback src -j SET --add-set ct_fallback src
iptables -t raw -A PREROUTING -s <grey_net> -p gre -m set ! --match-set ct_fallback src -j SET --add-set ct_fallback src
iptables -t raw -A PREROUTING -m set --match-set ct_fallback src -j RETURN
iptables -t raw -A PREROUTING -s <grey_net> -j CT --notrack
iptables -t raw -A PREROUTING -d <nat_pool> -j NAT --dnat


iptables -A FORWARD -d <grey_net> -j ACCEPT
iptables -A FORWARD -m set --match-set ct_fallback src -j ACCEPT
iptables -A FORWARD -s <grey_net> -j NAT --snat

iptables -t nat -A POSTROUTING -m set --match-set ct_fallback src -j SNAT --to-source <NAT_IP_for_fallback>

 

Share this post


Link to post
Share on other sites

3 часа назад, uzd сказал:

Фрагментированные пакеты работают, просто все фрагменты сначала собираются в один большой пакет ядром Linux, и только потом передаются в Iptables.

Данный участок кода написан на случай, если кто-нибудь сможет выключить сбор фрагментов на стороне ядра Linux (а это не слишком просто)

это сейчас значит,   что крупный пакет из кучи фрагментов в принципе не пройдет через nat пока не будет принят полностью?

ну это же огромное увеличение задержек

 

Share this post


Link to post
Share on other sites

 

34 минуты назад, LostSoul сказал:

ну это же огромное увеличение задержек

чтобы выполнить NAT нужны данные заголовка уровня L4 (tcp, udp). Только первый фрагмент большого пакета получает

этот заголовок. Поэтому, это принципиальное требование для любовог NAT движка.

Share this post


Link to post
Share on other sites

1 минуту назад, kisa сказал:

Поэтому, это принципиальное требование для любовог NAT движка.

жуткие вещи вы рассказываете.  что мешает проанализировать имеющиеся L3/L4 заголовки в рамках первого(первых) фрагментов , что необходимы для принятия решения о судьбе пакета, согласно настроенным и правилам и дальнейшей немедленной обработке и пересылке первого ( первых ) фрагментов? 

Естественно , что если в числе фильтров стоит полнотекстовый поиск по содержимому, сравнение в каком-то дальнем смещении , то это не прокатит.

 

Share this post


Link to post
Share on other sites

Фрагменты это такая же фантомная проблема в эксплуатации как и поддержка пптп. За всю жизнь с отключенными фрагментами обращались только операторы кол центра тинькова, которым выдавался реальник и вопрос закрывался.

По поводу распределения адресов код то я прочитал сразу, я не совсем понимаю как оно будет точно рассчитано, ладно, будет проще написать три строчки калькулятора и прогнать интересующее меня.

Share this post


Link to post
Share on other sites

2 часа назад, vurd сказал:

только операторы кол центра тинькова,

а как можно было call-центр крупного банка подключить с серым IP?

или у этого банка надомные операторы , подключающиеся к серверу банковской телефонии?

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.