Перейти к содержимому
Калькуляторы
1 час назад, LostSoul сказал:

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

нет

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

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

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Итак, я внедрил на одном из серверов (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

Изменено пользователем SABRE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 это еще не касается?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@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

Изменено пользователем SABRE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем TriKS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

No ALGs for FTP/SIP/PPTP are implemented

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

No ALGs for FTP/SIP/PPTP are implemented

;(

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 hour ago, TriKS said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вообще GRE, можно спокойно запустить через Linux conntrack NAT, и тогда вообще не вижу проблем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 (а это не слишком просто)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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>

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.