[PumpIT]

Здравствуйте! Как то неожиданно абоненты начали жаловаться на отсутствие скорости, раньше было пару звонков, за сегодня прям ощутимо. Находятся за натом, и исчерпали ограничение sess_tcp=2000, есть те, кто держит полку в 2000, вот они и жалуются.

Общее количество не большое, но вопрос, почему это стало неожиданно массово 

[root@skat14 ~]# fdpi_ctrl list all status --service 11 | grep -c sess_tcp=2000
15
[root@skat14 ~]#

Держится в районе 20. Из предположений: вирусня на компьютере/или другом устройстве,  все кто жаловался пользуются Smart-TV. Вопрос, какая рекомендация по sess_tcp=, увеличивать как то не хочется, может сессии быстрее рубить lifetime_flow_long=300?

[zavndw]

так легко проверить, если после 5 минут lifetime_flow_long количество этих клиентов не падает то скорее всего вирусня. В принципе их динамику понаблюдать. тв смарт берет 10 соединений в обычном случае. ну да же 20 возьмет, больше ему не во, что тратить.

[PumpIT]

Вот такая динамика

 

Это 5 минут

[PumpIT]

И еще заметили такой прикол, есть абон с белым адресом, в его сети присутствует видеорегистратор, допустим у него тариф 10мбит, но при включении регистратора, он генерирует трафик на максимуме интерфейса коммутатора доступа, причем dlf/broadcast/multicast фильтры не обнаруживают ни чего подозрительного, трафик доходит до Ската, им обрабатывается (что фиксируется счетчиком трафика на профиле абонента PPPoE) Получается, что некоторый тип трафика обходит шейпер ската?

[Urs_ak]

У нас чего-то быстро, в своё время, стали жаловаться на такое и я увеличил до sess_tcp=8000

 

Ещё у СКАТ'а есть проблема плохого освобождения трансляций:

Есть завирусованный абонент с забитым sess_tcp , ему меняешь серый ip и на следующий день смотришь, а на старом ip всё ещё висят трансляции на СКАТе.

 

Мне в ТП сказали, что "в будущих версиях быстрее будут освобождать".

 

Из базовой рекомендации: если ниже NATа есть BRAS, то на нём зафильтровать серые ip которые не входят в операторский пул, т.е. если ip выдаются из пула 100.64.0.0/10, то  чтобы 192.168.0.0/16 и т.п. не доходили до СКАТа и не натились. Потому что вирусы сканируют серые сети и соотв. забивают sess_tcp, ну это видно, если netflow поглядеть со СКАТа.

[PumpIT]

Так вот куда утекло 27г оперативки..

[bike]

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

стали жаловаться на такое и я увеличил до sess_tcp=8000

Сделали так сразу, но у нас пул 512 белых на менее 3к серых, т.е. адресов с запасом.

В среднем загруженность портов Ната "около нуля".

 

Был момент озадачился статистикой по сессиям - обычные пользователи редко выедают более 2 - 3к tcp/udp сессий.

Посмотрел на наличие превышений 8к сессий - не более 1-3 абонентов за месяц и то далеко не каждый, т.е. на уровне погрешности.

 

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

Звонил - у нас нет претензий, всё работает хорошо. Что само по себе странно.

 

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

Из базовой рекомендации: если ниже NATа есть BRAS, то на нём зафильтровать серые ip которые не входят в операторский пул, т.е. если ip выдаются из пула 100.64.0.0/10, то  чтобы 192.168.0.0/16 и т.п. не доходили до СКАТа и не натились. Потому что вирусы сканируют серые сети и соотв. забивают sess_tcp, ну это видно, если netflow поглядеть со СКАТа. 

А как вы навешиваете Нат на пользователей? Не сталкивались с подобным.

У нас L2 DHCP Radius Proxy, при авторизации выдаём серый адрес из пула 100.64.0.0/10 и навешиваем нужный профиль Ната.

 

П.С. Вредные советы - lifetime_flow_long=1800. Проблем, пока, нет.

[PumpIT]

 У нас bras/nat все в одном, навешиваем профиль 11, если нат. пул у нас с маской /27, по расходованию портов на один IP есть пару, которые заняты на 70%

[Urs_ak]

9 часов назад, bike сказал:

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

Звонил - у нас нет претензий, всё работает хорошо. Что само по себе странно.

У большинства вирусы. Вот например:

Скрытый текст

 

...
16:09:29.984    	0.004 	100.100.49.65 	24314	  192.168.71.110   	445        	1      	94  	188000    
16:07:12.705    	0.001 	100.100.49.65 	17379	  192.168.44.164   	445        	1      	94  	752000    
16:09:03.025    	0.004 	100.100.49.65 	22963	   192.168.66.49   	445        	1      	94  	188000    
16:07:06.024    	0.003 	100.100.49.65 	17077	  192.168.43.134   	445        	1      	94  	250666    
16:07:56.974    	0.006 	100.100.49.65 	19650	   192.168.53.79   	445        	1      	94  	125333    
16:09:33.044    	0.005 	100.100.49.65 	24486	   192.168.72.27   	445        	1      	94  	150400    
16:08:20.975    	0.002 	100.100.49.65 	20847	  192.168.57.248   	445        	1      	94  	376000    
16:09:27.124    	0.001 	100.100.49.65 	24227	   192.168.71.24   	445        	1      	94  	752000    
16:08:06.175    	0.007 	100.100.49.65 	20192	  192.168.55.108   	445        	1      	94  	107428    
16:07:47.874    	0.005 	100.100.49.65 	19145	   192.168.51.90   	445        	1      	94  	150400    
16:07:20.875    	0.002 	100.100.49.65 	17764	   192.168.46.12   	445        	1      	94  	376000    
16:07:26.985    	0.007 	100.100.49.65 	18132	  192.168.47.115   	445        	1      	94  	107428    
16:07:51.014    	0.008 	100.100.49.65 	19376	   192.168.52.66   	445        	1      	94  	94000    
16:07:32.974    	0.003 	100.100.49.65 	18422	  192.168.48.150   	445        	1      	94  	250666    
16:08:02.974    	0.002 	100.100.49.65 	19940	  192.168.54.113   	445        	1      	94  	376000    
16:09:36.104    	0.008 	100.100.49.65 	24656	  192.168.72.195   	445        	1      	94  	94000    
16:08:42.134    	0.005 	100.100.49.65 	21991	  192.168.62.111   	445        	1      	94  	150400    
16:08:42.074    	0.004 	100.100.49.65 	21960	   192.168.62.82   	445        	1      	94  	188000    
16:08:39.024    	0.004 	100.100.49.65 	21757	  192.168.61.133   	445        	1      	94  	188000    
16:07:36.014    	0.001 	100.100.49.65 	18613	   192.168.49.75   	445        	1      	94  	752000    
16:08:06.165    	0.006 	100.100.49.65 	20177	   192.168.55.93   	445        	1      	94  	125333    
16:09:21.105    	0.005 	100.100.49.65 	23899	  192.168.69.203   	445        	1      	94  	150400    
16:08:33.214    	0.005 	100.100.49.65 	21550	  192.168.60.192   	445        	1      	94  	150400    
16:09:33.294    	0.006 	100.100.49.65 	24596	  192.168.72.138   	445        	1      	94  	125333    
16:08:50.944    	0.003 	100.100.49.65 	22329	  192.168.63.190   	445        	1      	94  	250666    
16:07:15.195    	0.005 	100.100.49.65 	17581	   192.168.45.91   	445        	1      	94  	150400    
16:09:29.994    	0.005 	100.100.49.65 	24325	  192.168.71.121   	445        	1      	94  	150400    
16:08:47.944    	0.006 	100.100.49.65 	22184	   192.168.63.36   	445        	1      	94  	125333    
...

 

 

 

 

Или вот ещё:

Скрытый текст

...
14:38:06.795    	3.000   	100.100.32.117 	59892     172.25.12.77  	8445        	2     	188     	94    
14:56:21.986    	3.007   	100.100.32.117 	60440     172.30.12.18  	8445        	2     	188     	94    
14:38:42.805    	3.007   	100.100.32.117 	59945   172.25.242.140  	8445        	2     	188     	94    
15:16:39.256    	3.002   	100.100.32.117 	51654   172.25.242.140  	8445        	2     	188     	94    
14:09:24.514    	3.002   	100.100.32.117 	50478   172.30.122.227  	8445        	2     	188     	94    
14:52:29.966    	3.004   	100.100.32.117 	60276   172.25.242.140  	8445        	2     	188     	94    
14:18:20.334    	3.003   	100.100.32.117 	59264     172.25.12.77  	8445        	2     	188     	94    
14:41:14.795    	3.006   	100.100.32.117 	60177   172.30.174.250  	8445        	2     	188     	94    
14:37:50.785    	3.005   	100.100.32.117 	59876   172.19.245.125  	8445        	2     	188     	94    
14:41:06.805    	3.003   	100.100.32.117 	60168     172.30.12.18  	8445        	2     	188     	94    
14:41:25.936    	3.000   	100.100.32.117 	60196   172.19.245.125  	8445        	2     	188     	94    
14:58:01.976    	3.008   	100.100.32.117 	60546     172.25.0.155  	8445        	2     	188     	94    
14:57:37.996    	2.998   	100.100.32.117 	60509     172.25.12.77  	8445        	2     	188     	94    
15:00:39.426    	3.004   	100.100.32.117 	60697   172.19.245.125  	8445        	2     	188     	94    
14:56:05.986    	3.009   	100.100.32.117 	60413     172.25.12.77  	8445        	2     	188     	94    
15:15:15.477    	3.002   	100.100.32.117 	51538   172.19.245.125  	8445        	2     	188     	94    
14:55:57.976    	3.005   	100.100.32.117 	60394     172.25.0.155  	8445        	2     	188     	94    
15:02:25.967    	3.003   	100.100.32.117 	50929   172.25.242.140  	8445        	2     	188     	94    
14:56:20.526    	3.006   	100.100.32.117 	60434   172.19.245.125  	8445        	2     	188     	94    
14:56:25.966    	 3.006   	100.100.32.117 	60444   172.25.242.140  	8445        	2     	188     	94    
15:16:23.227    	3.009   	100.100.32.117 	51626     172.25.12.77  	8445        	2     	188     	94    
14:09:31.153    	3.001   	100.100.32.117 	50491      72.163.1.80  	  80        	2     	188     	94    
15:14:41.236    	3.003   	100.100.32.117 	51484      72.163.1.80  	  80        	2     	188     	94    
14:59:49.966    	3.006   	100.100.32.117 	60623     172.25.0.155  	8445        	2     	188     	94    
14:40:49.075    	3.001   	100.100.32.117 	60142   172.19.245.125  	8445        	2     	188     	94    
15:15:19.227    	3.003   	100.100.32.117 	51543   172.30.119.131  	8445        	2     	188     	94    
15:15:19.227    	3.001   	100.100.32.117 	51542     172.25.12.77  	8445        	2     	188     	94    
14:41:06.805    	3.005   	100.100.32.117 	60169     172.25.12.77  	8445        	2     	188     	94    
...

 

 

Есть непонятные случаи - позвонил абонент, плохо сайты открываются, вирусов в статистике не нашёл. Абонент говорит "у меня пара макбуков и две Яндекс колонки". Из подозрительного в netflow - каждые минуту-две синхронизация времени на разные ip. Поменял ему серый ip и больше не жаловался. Видимо дело не в NTP.

[PumpIT]

Поставили 4000, Теперь по статистике это значение превысили только 10 юзеров, и странно, они вообще не звонили  превышая 2000, может и вправду не замечали)

[bike]

9 часов назад, bkdipnet сказал:

Поставили 4000, Теперь по статистике это значение превысили только 10 юзеров, и странно, они вообще не звонили  превышая 2000, может и вправду не замечали)

ИМХО, много лет жили на Ericsson SE 100 с его Натом и проблем не знали с ограничением в 2к сессий, сейчас эта планка поднялась до 2-3 к сессий в виду огромно кол-ва "домашних девайсов".

 

Нормальный абонент не упираясь в ограничения кол-ва сессий не имеет проблем, а у "загаженных", при достаточном пуле, хватает lifetime_flow_long, что бы "добрые" tcp сессии жили и появлялись новые.

 

П.С. Разговор, во основном, про tcp, а какие у Вас ограничения на udp? У нас 8к tcp/udp - например "Ютубчег" бегает по quic, а это udp.

[PumpIT]

@bike Аналогично с SE100 вообще таких проблем не знали. По udp сделали такое же: 4000 но по статистике и 2000 не переходили вроде, поставлю на мониторинг, посмотрим. Просто Скат у нас уже около 1.5 лет вроде, и за это время не было жалоб с этой стороны, а тут как лавина, при чем были дома у жалующихся пользователей, там комп иногда включают, а в основном два телефона, но наблюдали у ип с большим парком оборудования, как его зараженные компы сканят 0.0.0.0/0 то есть вообще весь диапазон существующих адресов, сканит все "интересные порты" там половина таких компов, блокируешь один начинает другой, сделали правило, чтоб автоматом блокировало и забыли. Видимо у всех проблемных клиентов такая же бяка, и активировалась удаленно или по таймеру.

[PumpIT]

Да, пользователям что то объяснять трудно, сегодня отключился один из тех, у кого 4000 tcp было. И все же, может есть какой то механизм сброса трансляций на проблемных адресах? Раз сессия долго не сбрасывается автоматически, может находить таких и очищать вручную/скриптом. Просто проверили на одном: разрываешь соединение, как только он подключается, получаем опять те же цифры по сессиям, это про 

В 01.09.2021 в 22:12, Urs_ak сказал:

Мне в ТП сказали, что "в будущих версиях быстрее будут освобождать".

Пока увеличили до 6000, но это не решение проблемы, как нам кажется...

[Urs_ak]

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

И все же, может есть какой то механизм сброса трансляций на проблемных адресах

Я спрашивал в ТП, сказали нету - "либо рестарт сервиса, либо подождать пока эти сессии займут другие абоненты"

Вообще сами спросите в их ТП :), потому что они при апгрейде СКАТа обязывают выкупать ТП за прошлые годы, даже если не пользовался. Вот пусть поработают.

У нас при 8k tcp/udp, условно - один звонок в месяц с этой проблемой.

[Valaskor]

Ух ты, неужели кроме нас еще кто-то жалуется, багу уже много лет, часть тсп-сессий не таймаутится.

 

Моя чистилка:

cat /etc/cron.d/nat_clean
PATH=/sbin:/bin:/usr/sbin:/usr/bin
1-59/5 * * * * root fdpi_ctrl list all status --service 11 --outformat json | jq -r '.lstatuses[] | select(.status_11.sess_tcp>1990) | .ipv4'| head -n50 | xargs -L1 fdpi_ctrl del --bind_multi --ip

 

Если не используется авторизация, можно просто 11 услугу выключать-включать по идее.

[Urs_ak]

@Valaskor Спасибо, потестим.

 

Позор ТП VasExperts

[Valaskor]

Похоже в 11 версии с натом стало получше.

[Urs_ak]

В 22.11.2021 в 12:25, Valaskor сказал:

Похоже в 11 версии с натом стало получше.

В changelog ничего про NAT нет

Скрытый текст

Цитата

Изменения в версии 11.0 Foundation

 

Добавлена поддержка сигнатур, определяемых пользователями на основе SNI, IP[:PORT] или SUBNET
Добавлена запись трафика в СХД («закон Яровой»)
Добавлены протоколы FACETIME,NORD_VPN,EXPRESS_VPN,PRIVATETUNNEL_VPN,VPNUNLIMITED,PSIPHON3,CLUBHOUSE,TLS_UNKNOWN,QUIC_IETF,SPEEDTEST
Изменено : по 12 услуге пишутся данные в pcap и после детектирования закрытия сессии
[dpi engine] Add configurable IP recheck timeout
[sorm engine] New config prmt for amount of meta_parser
Изменено : Если задан параметр ssl_reply в версию протокола ставим значение из протокола content_type=0x16
Изменено : определение протоколов ssl_unknown и tls_unknown определяется как : sni пусто и cname пусто - сморим версию заголовка ServerHello ( из первых 5-ти байтов ). Если версия ⇐0x0300 - это ssl_unknown иначе это tls_unknown. Если задан параметр tls13_unknown - всегда смотрим ServerHello и если там версия 0x0304 это всегда протокол tls_unknown ( независимо от sni/cname)
Исправлено : в файлах layout в поле flags ставится значение : 2 - если это служебная запись или не определено еще flow иначе уставнавливаем 1- dir_data
Изменено : если задан параметр ssl_parse_reply происходит поиск cname
Изменено : В формат ajb_save_sslreply_format добавлены 3 новые поля tphost ( тип хоста - всегда 2 ), host ( cname ), evers - версия из Extensions ( определяется только если задан параметр tls13_unknown=1 иначе 0 ).
Изменено : Формат clickstream передачи ssl-reply. Добавлены поля : 1011 - type_host - число лежит в host - всегда 2 и 1005 cname
Изменено : сообщения при трассировки вида DPI(DEF_PROTO,CHANGE_PROTO,STORED_PROTO) - добавлено поле cntr_fin, direction
Исправлено : после закрытия соединения не помещалась запись в short очередь для tcp
Добавлено : при трассировке для TCP соединений сообщения добавлено сообщение об изменении очереди (short/long)
Изменено : формат вывода команды fdpi_cli dump flow cache
Добавлено : параметр ajb_save_fragment - задает запись фрагментированных пакетов в pcap
Изменено : разбор протокола TLS
[pcrf][DHCP] Fixed: передача opt82 circuit/remote id в аккаунтинг
Добавлено : для storage_agent параметр engine_bind_cores который задает привязку потоков записи к ядрам
[BRAS][DHCPv6] Fixed: падение на пакете DHCP-Confirm без указания IPv6-адресов в IA_NA-опции
Fixed: режим tap_mode=1 - не должно быть отправки пакетов
Fixed: крах при разборе L2-заголовков для eher_type=0xFFFF
[PCRF][framed-pool] Fixed: при добавлении в уже существующую опцию opt125 не учитывалось, что dhcp_poolname_opt=0 - это то же самое, что и dhcp_poolname_opt=2. Это приводило к добавлению opt125 для VasExperts при dhcp_poolname_opt=0
[BRAS][ARP] Добавлено: поддержка режима сегментирования абонентов в общем VLAN на сети доступа(изоляция абонентов на коммутаторе, т.е. абонам не доставляется трафик между друг другом даже в одном влане) Добавлен fastdpi.conf-параметр bras_arp_vlan_segmentation: Учитывается только при установленном флаге 1 в bras_arp_proxy для ARP-запросов от одного абонента другому. off (типичный случай) - абоненты A и B в одном VLAN могут взаимодействовать между собой напрямую, СКАТ не обрабатывает ARP-запрос от абонента A «who has target abonent B IP» on - на коммутаторе включена изоляция абонентов, находящихся в одном VLAN, поэтому СКАТ должен сам ответить на ARP-запрос от абонента A «who has target abonent B IP»
[cfg] Fixed: не учитывалось значение параметра set_packet_priority в fastdpi.conf
Изменено : статистика SDS_AGENTS_ - добавлено суммарное кол-во ошибок и процент
Изменено : поддержка нескольких очередей SDS_AJB
Добавлено : параметры sds_ajb_num - кол-во очередей sds_ajb ( default 1 ) sds_ajb_bind_cores - задает ядра к которым надо привязывать потоки. Если не задан - ядра назначаются автоматом. Пример sds_ajb_bind_cores=1:1:2:2

 

Изменения в версии 11.1 Foundation

 

[fastpcrf] Fixed: передача opt82 в аккаунтинг при L3 auth
[pcrf] Fixed: передача значения атрибута opt82 remoteId в аккаунтинг
[pcrf] Added: возможность задания атрибутов для opt82.Новые параметры в fastpcrf.conf: attr_opt82_remoteid=vendorId.attrId где vendorId - id вендора. Если vendorId != 0, то значение передается в VSA-атрибуте. Если vendorId == 0, то значение передается в обычном Радиус-атрибуте (не-VSA) attrId - id атрибута, число от 1 до 255. Если эти параметры не заданы, то opt82 передается в следующих атрибутах: acct: circuitId: ADSL VSA 3561.1, remoteId: ADSL VSA 3561.2 auth: circuitId: VasExperts VSA 43823.39, remoteId: VasExperts VSA 43823.33 Пример задания: attr_opt82_remoteid=15.34 attr_opt82_circuitid=15.35

 

[Stas Kazanskii]

В 01.09.2021 в 19:20, bkdipnet сказал:

Вот такая динамика

 

Это 5 минут

Подскажите, пожалуйста, как вы организовали графический мониторинг сессий.

[Urs_ak]

В 26.11.2021 в 12:48, Stas Kazanskii сказал:

Подскажите, пожалуйста, как вы организовали графический мониторинг сессий.

На этом графике - кол-во абонентов у которых трансляций больше 2000

Запускается что-то типа fdpi_ctrl list all status --service 11 --outformat json | jq -r '.lstatuses[] | select(.status_11.sess_tcp>2000) | .ipv4'| wc -l

и результат пихается в метрику Zabbix

[Stas Kazanskii]

В 27.11.2021 в 21:18, Urs_ak сказал:

На этом графике - кол-во абонентов у которых трансляций больше 2000

Запускается что-то типа fdpi_ctrl list all status --service 11 --outformat json | jq -r '.lstatuses[] | select(.status_11.sess_tcp>2000) | .ipv4'| wc -l

и результат пихается в метрику Zabbix

Благодарю великодушно! Отлично работает.

[bike]

"Изменения в версии 11.2 BETA1

1. Существенно переработана поддержка CGNAT: клиенты на одном белом адресе будут активнее переиспользовать сессии друг друга."

Кто то уже тестировал?

[Valaskor]

Коллеги, мне это кажется, или в версии 12.4 опять как то стали подзалипать сессии? Никто не обращал внимания?

[Urs_ak]

Я сижу на 11.4 и проблем с залипанием не испытываю (ранее это была больная тема, приходилось перезапускать службу раз в месяц)

 

Однако почитываю их телеграм-канал и у меня тоже создалось впечатления что начиная с какой-то 12.х опять там проблемы с NAT

 

Поэтому продолжу сидеть на 11.4

 

[catalist]

а что за телеграм-канал?