KorDen

Вон тот дамп ведь на TSMB сделан, и он в WAN летит

Не брандмауэр, а "расположение" (домашняя/рабочая/общественная для w7, частный/общий для w10), оно ЕМНИП зависит от мака default gateway.

Гм. 2.14.C.0.0-4. CIFS NQ. == Chain _NDM_OUTPUT == src: 0.0.0.0/0, dst: 0.0.0.0/0, in: "*", out: "*", proto: "UDP"; jump to "_NDM_NBNS_OUTPUT_FILTER" -> Chain default policy: RETURN ... == Chain _NDM_NBNS_OUTPUT_FILTER == src: 0.0.0.0/0, dst: 0.0.0.0/0, in: "*", out: "ppp+", proto: "UDP"; "udp" match, sports: 137-138; DROP src: 0.0.0.0/0, dst: 0.0.0.0/0, in: "*", out: "ppp+", proto: "UDP"; "udp" match, dports: 137-138; DROP src: 0.0.0.0/0, dst: 0.0.0.0/0, in: "*", out: "ovpn_br+", proto: "UDP"; "udp" match, sports: 137-138; DROP src: 0.0.0.0/0, dst: 0.0.0.0/0, in: "*", out: "ovpn_br+", proto: "UDP"; "udp" match, dports: 137-138; DROP src: 0.0.0.0/0, dst: 10.230.2.255/32, in: "*", out: "eth3", proto: "UDP"; "udp" match, sports: 137-138; DROP src: 0.0.0.0/0, dst: 10.230.2.255/32, in: "*", out: "eth3", proto: "UDP"; "udp" match, dports: 137-138; DROP src: 0.0.0.0/0, dst: 10.230.2.0/24, in: "*", out: "eth3", proto: "UDP"; "udp" match, sport: 5355; DROP src: 0.0.0.0/0, dst: 10.255.128.255/32, in: "*", out: "apcli0", proto: "UDP"; "udp" match, sports: 137-138; DROP src: 0.0.0.0/0, dst: 10.255.128.255/32, in: "*", out: "apcli0", proto: "UDP"; "udp" match, dports: 137-138; DROP src: 0.0.0.0/0, dst: 10.255.128.0/24, in: "*", out: "apcli0", proto: "UDP"; "udp" match, sport: 5355; DROP -> Chain default policy: RETURN А пакетики то сыпятся.... ----------- АААААААААА! Короче, оно дважды поломано. в CIFS NQ оно в фильтр не попадает, а в TSMB фильтра нет... Гы Это пакет на 2.14: 67 21:15:01.510990 10.230.2.5 255.0.0.0 NBNS 110 137 137 Registration NB WORKGROUP<00> А на eth3 у нас dst указан! src: 0.0.0.0/0, dst: 10.230.2.255/32, in: "*", out: "eth3", proto: "UDP"; "udp" match, sports: 137-138; DROP src: 0.0.0.0/0, dst: 10.230.2.255/32, in: "*", out: "eth3", proto: "UDP"; "udp" match, dports: 137-138; DROP src: 0.0.0.0/0, dst: 10.230.2.0/24, in: "*", out: "eth3", proto: "UDP"; "udp" match, sport: 5355; DROP Ну вот оно и...

2.15.A.4.0-6 (CIFS NQ) - есть, 2.15.A.5.0-1 (TSMB) - нет. Хм. Так. Кажется, картинка потихоньку складывается. Слишком много совпадений.. Оператор, вытащи меня отсюда! ... или не складывается. ЯННП, - в поисках флуда (другого) я дамплю broadcast на WAN кинетика 2. 15.A.4.0- 3/CifsNQ - в дампе замечаю SMB от себя. Полистав - замечаю, что подобное прилетает от других кинетиков в сети. Сейчас я начинаю понимать, что другие кинетики вполне могут быть на древних прошивках. Но тут возникает вопрос - насколько я понимаю, tcpdump показывает исходящие пакеты уже ПОСЛЕ iptables. Вначале была беглая мысль, что он показывает пакеты ДО iptables (которые не отсекаются), но ведь это же не так для OUTPUT. Хм. self-test я тогда не снимал. - на 2.15.A.5.0-1 его действительно ломают. И мой нынешний дамп уже на сломанном, хотя я тему создал, когда еще поломано не было. Гм. Сейчас проверил на Giga II @ 2.14 delta - в iptables правила есть, в исходящем tcpdump HostAnnouncement есть. Чо?

Ой-ой-ой. Тогда ответить не успел, свалился TSMB на голову, выжидал пока поправят. Короче, в WAN на самом деле летит очень много лишнего, например 90 17:35:31.332072 10.230.2.5 10.230.2.255 BROWSER 245 138 138 Local Master Announcement KEENETIC_GIGA, Workstation, Server, NT Workstation, NT Server, Master Browser Дампил на сетевушке ПК, подключенного к WAN Giga KN-1010 на 2.15.B.0.0-1, дамп по фильтру "ip.src == 10.230.2.5"

Giga KN-1010 @ 2.15.B.0.0-1, дефолтные настройки. Цепляюсь по Wireless ISP 5GHz к 1810 на такой же прошивке, BandSteering на 1810 выключен - работает А после перезагрузки гиги она к сети упорно не желает подключаться, пока не дернешь on-off. На 2.4 такого не наблюдаю

Не хотел вмешиваться во флуд, но всё-таки. Вы видели объемы современных игр? Если не в курсе - они исчисляются десятками гигабайт. И много у кого, потому что при ремонте не была заложена витуха до компа, а провод тянуть - некрасиво, игровой комп/ноут/PS4/XboxOne подключены по WiFi. И вот "синтетика" спидтеста, в том числе из-за особенностей системы загрузки конкретных сервисов, превращается уже во вполне себе реальный кейс загрузки игр и их обновлений (которые тоже немаленькие). Тут еще сами приложения подливают масла в огонь своими показометрами (погодой даже не на Марсе, а на Юпитере славится например Battle.net, хотя при понимании процесса цифры объяснимы, но попробуй это объясни юзерам...)

Хочу уточнить: состояние падения как выглядит? Просто не ходит трафик (но туннель/IPsec SA в UP), или именно туннель/SA дропается? У себя изредка наблюдаю ситуацию, когда до 7-часового rekey остается час-два, а трафик перестает ходить (хотя с обоих сторон SA как будто UP), и если не ребутать - то восстановится только по rekey. В моем случае туннель 6856<->7628 без NAT.

Чуть отходя от темы - тут недавно проскакивало где-то обсуждение, мол "сеть офиса на пару десятков компов и больше - это уже не уровень SOHO-кинетиков". Хотя у меня чуть другое мнение - с сожалением сейчас приходится осознавать, что таки да, кинетик для офиса уже не так сильно и отличается от M-k по необходимой настройке, только наоборот - слишком уклон в попсу-простоту по-умолчанию, скажем так.. Ну, серьезно. Сеть на простом SOHO D-k/T-k можно построить и оно как-то вполне будет ворочаться, но надо будет ребутать периодически. Сеть на M-k надо вначале грамотно настроить, зато потом будет работать как часы. И вот сейчас ситуация в том, что сеть на кинетиках получается тоже приходится настраивать вне рамок вебморды, просто потому что иначе у нас будет ARP-флуд, потому что некоторые фичи для офиса лишние, но фактически отрубаются только через консоль (навскидку UPnP например, хотя через морду можно радикально снести компонент). Преимущество HWNAT сейчас уже теряется, разгрузку IPsec на 7621 не сделали только ленивые. И как-то уже вопрос "M-k vs U-y vs Keenetic на сетку из 15+ устройств с приходящим эникейщиком" уже не стоит с точки зрения "в M-t нет HWNAT и надо знать как настраивать, в U-y для нормальной настройки надо тоже лезть в консоль", потому что у кинетика сейчас тоже надо лезть в консоль. Раньше тоже в некоторых случаях надо было чуть что лезть в консоль и потом не трогать ни в коем случае морду, но как-то ИМХО раньше надо было не всегда лезть, а сейчас - фактически всегда. Знакомые умудрялись вообще поставить Giga II на сетку из нескольких десятков компов (пачка свичей+потолочные ТД), не залезая ни разу в CLI, и оно очень даже безглючно работало. Сейчас по ощущением такая халява не прокатит в том числе по сабжевым причинам, от чего и грустно.

Имеется в виду ситуация, когда кинетик - ядро небольшой офисной сети (NAT+DHCP), а дальше в помещениях установлены свичи/ТД другого вендора. Т.е. навскидку (возможно я не так/не до конца понимаю проблему Hotspot), мы можем уменьшить объемы бродкаста (особенно в беспроводной сети), если будем ориентироваться например на список подключенных к AP, на его основе не слать часть бродкаста. Но этот список - это только проприетарщина между кинетиками по понятным причинам, а клиент, подключенный к ТД другого вендора - это просто проводной клиент для роутера, так что только arping'ом по идее и можно узнавать о хостах. Ну это скорее, ворчание на тему "раньше трава была зеленее" - раньше никому дело не было до необходимости знать онлайн ли хост, и никакого постоянного лишнего бродкастового трафика роутер не порождал. Точно так же как со счетчиками например, никто не считал - и все шли через HWNAT, а теперь у нас и по сети по-умолчанию бродкаста куча летает => быстрее мобильные устройства разряжаются, как не колдуй; и при большом количестве хостов мы неявно вываливаемся из HWNAT (но дури сейчас много, так что незаметно), и так далее и тому подобное.

Только, пожалуйста, без проприетарщины. Достаточно вспомнить про отсутствие у вас потолочных/уличных ТД и PoE. "Мы создадим себе проблемы, а потом героически будем их решать". В итоге любая настройка кинетика начинается с ip hotspot no auto-scan interface Home. Wait, MWS=контроллер? Только не надо завязываться на контроллер, речь в первую очередь о летающем в LAN.

Ага, тогда всё еще яснее. В итоге: 111, 69, 72 - смартфоны Android 5/6/7 разных производителей, просто лежащие подключенными к сети с выключенным экраном. 69 на скрине нет, но там такая же картина как и с 72/111. Ну, я еще подампил ra0/ra1 на роутере для уверенности... Смартфоны похоже периодически игнорируют одиночный ARP-request ради энергосбережения, через 30 секунд роутер начинает долбить 5 запросов, и на какой-то из них (не первый) смартфон таки решается ответить (не всегда). Дальше 30+30 секунд и по новой. Это у меня всего три смартфона, а если их два десятка, да по проводу пара ТД?

О, похоже, это буквально недавно добавили. До этого (буквально на 2.15.A.3.. или около того) в конфиге его не было, и после сброса вроде бы в RT2860AP RekeyInterval=0;0;..,. был конечно же на нужный

Небольшой UPD, дампы с подробностями потом. Роутер - ультра, доп. ТД нет, дамплю на ПК, auto-scan отключен: На подключенного клиента прилетает 1 ARP каждые 30 секунд. При этом периодически на подключенного по WiFi клиента каждые 30 секунд в LAN начинает прилетать пачка из 4 ARP-пакетов с интервалом в 1 секунду.

Возможно речь идет о том, что кинетики сейчас при выключенном auto-scan шлют ARP на "известные" адреса, по крайней мере на недавно отключившиеся (3-4 пакета на один IP каждые несколько десятков секунд в течение скольки-то там минут я видел, позже конкретизирую), или еще как-то так. Тогда делали вроде, чтобы он не рассылал бродкаст auto-scan в WiFi, но проблема в том, что он рассылает простые запросы в LAN и по идее его транслируют AP, подключенные проводом. А, ну и до кучи, может там не только ARP... какой сейчас в итоге-то rekey-interval по-умолчанию?