Soltik

Если не ошибаюсь, по http вообще транслировать невозможно. http (как и более подходящий RTSP) начнет передавать по запросу. Если нужна реальная трансляция, невзирая на запрос клиента, тогда что-то из UDPшного, вплоть до мультикаста.

Указываешь на поправку, что не в состоянии блочить урл, и показываешь отсутствие пинга на IP.

А одинаковые записи в реестре - это теперь тоже будет нормально? id=198 и id=786 отличаются только слешем в конце урла, приняты одной конторой в один день под разными номерами документов )))

24млн соединений??? нее, что-то там не так. Пусть будет 10тыс юзеров, получается по 2400 соединений на каждого, это анриал какой-то. Хотя сомневаюсь, что одна линуксовая машина столько народу тянет.

Действительно, я тоже порывался в csv превратить, но вовремя остановили. Формат будет меняться сто раз, это вам не IETF со своими RFC )) А xml хотя бы будет работать, хоть и без новых полей.

Сколько же народу за этим одним натом сидит? Может тогда подрезать им количество одновременных сессий, а то же торренты, например, совершенно ненасытны. Кроме того, имеет смысл обратить внимание на таймауты tcp и udp сессий (net.ipv4.netfilter.ip_conntrack_***), нынче инет не на диалапе чтоб счет вести на десятки минут, а то и на часы. Можно поанализировать файл /proc/net/ip_conntrack, там третье поле - длительность висящей сессии, если там большое количество записей с сильно большими числами - надо сокращать таймауты. Вот что-то такое например: cut /proc/net/ip_conntrack -d" " -f8 | sort -n | uniq -c если разбивать по пробелам, у меня это поле восьмым вышло, поэтому -f8

Интересней, что они с самим реестром делают, что он у них каждый час обновленным считается ))

Ну вот есть у меня урл и есть ssl запрос на ip адрес. А что дальше? Каким мне образом связать никому неизвестный ip с каким-то там сертификатом с имеющимся урлом? Никак. Я же говорю, это мне надо урл из реестра посетить вначале, слить его сертификат, а уже потом искать его в запросах. Нет уж, блочить по сертификатам нам директив не давали. Я читаю инструкцию так: если есть возможность блочить урл - блочить его, если нет такой возможности (а при хттпс ее нет), то блочить IP. Вот и все.

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

Есть возможность писать свои собственные скрипты сигнатур, но это такие дебри, что в них лезть совсем неохота. К тому же это мне надо вначале посетить этот хттпс, слить его сертификат, а потом его еще и пережевывать? Да ну их лесом! Для них буду ип блочить и все тут. DNS тоже не панацея, не только чужие днс и хостс спасают, но и просто сокс-прокси.

Какой-то чатланин гравицапу прощелкал, или машинку перемещения с кучей зарядов, вот нашедшего счастливчика и взяли.

Это она для постоянного тока, который в тестере замкнутая, а для радиоволны соответствующей длины - там два плеча с максимальной амплитудой на кончиках, так что получающемуся переменному току живется в ней очень даже комфортно. А относительно рефлектора - он просто обязан быть продолжением земли, что касается переизлучения поглощаемого ЭМИ (читай-отражения), то там все нормально в любом случае, а вот всякие наводки будут стекать куда им и положено - в землю.

Не, они снифер тоже ставить не будут. Они открывают браузер, открывают линк, а потом говорят, что за нафиг!?!? ну! ну! ну!

Дык дядьки "оттуда" не будут проверять мои конфиги и убеждаться, что я его внес, они тыкнут на него в браузере, а он откроется, ибо никакой снифер его не проснифит в SSL-потоке. Остается помимо DPI еще и обычный блеклист на домены и IP ставить, и в таких случаях блочить по ним. Вопрос к max1976, Дятел, alks, с кем обсуждали реализацию блеклиста на SCE через CLI-FTP-CSV. Есть идеи (у меня была:) )?

в реестре появилась пара строк с урлами https. Используем DPI для фильтрации урлов. Интересно, теперь еще добавлять отдельные, иные механизмы чтоб блочить по ip/домену? Ведь от урла https совершенно никакой пользы, ибо он не виден, GET идет уже зашифрованный. Или может, опираясь на наличие урла блочить ип, но только с 443 портом?

Идея интересная, но может для такого серьезного проекта лучше переписать все это на сях?

unbound , плагины - python. хотя плагины вероятно и на c можно - но тут точно не скажу. спасибо, бум вникать.

переходить на пппое и блочить на коммутаторах межклиентский трафик на основе маков.

Ну, "слухи" о Универсальной электронной карте давно ходят. Вроде бы, с 2013 года должны были начать выдавать всем желающим. Ну, выдавать неинтересно. В моей идее ключевое слово "приобрести" ;)

flow - это двустороннее соединение, не понимаю, как можно урезать в одном соединении часть, направленную в одну из сторон? И уж тем более не понимаю, как сделать два одинаковых сервиса? Даже если и получится, и в них все будет одинаково - отрабатывать будет первый по списку. очень просто, в классификациях создали все теже самые классификации что были в P2P только к именами добавили Upload в названии, а старым Download всем классификациям выставили нетворк инит: Download - Network Initiated Upload - Subscriber Initiated в пакадж вместо одного P2P у нас теперь P2P Download и P2P Upload и flows мы режем только на download потому-что когда мы резали просто на п2п, то получалась такая ситуация: у абонентов у которых торрент клиент уже забит старыми закачками, он постоянно что-то раздает кому-то и получается так, что например я поставил в час пик кол-во сессий 15 - и на закачку просто не остается сессий т.к. изза большого кол-во старых закачек, все занято раздачей. Сейчас такой ситуации нет. Идея понятна, но никогда не заморачивался с тем, что у клиента все потоки аплоадами забиты, сами виноваты )) Кстати, а не пробовали просто в одном пакете поставить приоритеты (которые LA) на Downstream чуть больше чем Upstream, например туда самый малый - 1, а обратно 2. Я понимаю, что приоритеты нужны при драке сервисов за место в одной тесной трубе, но мало ли, вдруг и flows будут вытесняться более приоритетными независимо от направления.

А тем временем в России принудительно заставят всех пользователей рунета приобрести и использовать квалифицированные электронные подписи для доступа к сайтам.

Ну слил и слил. ИМХО скрипт делает. Пусть железка работает. Так ведь не корысти ради, а пользы для! Это сейчас файло маленькое, и нас не особо много. Они и сейчас то умудряются подпись по 2 мин проверять, а когда запросов будет стопицот от всей нашей сказочной страны - загнутся. А так - кинул SOAP запрос, увидел дату обновления и вышел не напрягая ни их, ни себя.

Ну вообще-то чем терять столько времени на лишние разговоры, я бы давно влепил устройство в примерный фокус, высунулся бы в окно (на балкон/крышу итд) и начал подгонять. Собсно на заре wifi так и делал, и вполне успешно. Вот примерно такие штуки были очень даже работоспособны: А вот этот зверь пережил провайдера

фокус можно найти чисто механически. Наклеить несколько мелких осколков зеркала в разные точки поверхности, направить штырем крепежа на солнце, или достаточно далекий фонарик (чтоб лучи параллельные были) и смотреть где лучики сойдутся. Но опять-таки, зависит от крепежа, иногда он смотрит параллельно направленности антенны, а иногда может и нет.