Windows Firewall и авторизатор

[Andrey Zentavr]

Перекатились с 5го на 6е ноября с УТМа на НоуДени. Одна и самых острых проблем, которые возникли - это проблемы на пользовательской стороне с авторизатором:
1) Многие пользователи при первом запуске с дуру нажимали блокировать программу-авторизатор, после чего соответстенно не могли выйти в интернет. Бедному оператору приходилось по 20-30 минут рассказывать что и как сделать, куда залезть чтобы убрать.
2) у хорошей так части населения есть роутеры (ну, к примеру всякого рода Dlink-320 и т.д.). В этом случае авторизатор то работает, то совсем не работает (чащзе всего не работает). Приходиться всем тыкать "всегда онлайн" через админку.

В связи с этим предлагаю авторам:
1) Внести фичу в авторизатор, которая при запуске проверяла бы исключение в WinFirewall и если его нет - вносила бы его.
2) а вот что делать во втором случае - честно говоря хз. Я вот подумываю уже ваять модуль админку для включения "всегда онлайн" самим юзером, как это было доселе в УТМе.

[Efendy]

Перейти на pppoe

[versus]

PPPoE попробуй это раз
Есть вэбадминка это два

[Efendy]

А, вообще, где вы таких неадекватных пользователей берете, которые для получения доступа в интернет нажимают "блокировать"? Они когда здороваются говорят "до свидания"?

[Cell]

Просто в утм авторизатор работает на tcp и файрволы с ним гораздо больше дружат, как впрочем и роутеры. Может имеет смысл задуматься? Лично я вообще отказался т.к. накушался этого по самое нехочу.

[elite]

Просто в утм авторизатор работает на tcp и файрволы с ним гораздо больше дружат, как впрочем и роутеры. Может имеет смысл задуматься? Лично я вообще отказался т.к. накушался этого по самое нехочу.

максим, время авторизаторов уже прошло надо уходить от такой схемы, как от изначально ущербной
нужно делать универсальные методы авторизации - PPPoE или веб-авторизация при изменении mac-адреса на порту коммутатора

[Andrey Zentavr]

Перейти на pppoe

тыщупиццот абонентов загнать в ПППоЕ - это какие железяки нужны? Тем более что в сетке поднят DC++ и торрент. По тоннелям это всё качать ИМХО не выход.
PPPoE используется для выдачи реального ИП.

[Andrey Zentavr]

Есть вэбадминка это два

Всех на всегдаонлайн? Это тоже не выход. А пользователю держать открытую страницу браузера не совсем удобно.

[Andrey Zentavr]

... или веб-авторизация при изменении mac-адреса на порту коммутатора

Можно примерную схему решения?
ПППоЕ используется, но не на всю катушку (причина постом выше)

[Efendy]

Перейти на pppoe

тыщупиццот абонентов загнать в ПППоЕ - это какие железяки нужны?

Сеть Fregat  в моем городе как раз юзает один софтовый  сервак на каждые  тыщупиццот pppoe абонентов

[Cell]

Просто в утм авторизатор работает на tcp и файрволы с ним гораздо больше дружат, как впрочем и роутеры. Может имеет смысл задуматься? Лично я вообще отказался т.к. накушался этого по самое нехочу.

максим, время авторизаторов уже прошло надо уходить от такой схемы, как от изначально ущербной
нужно делать универсальные методы авторизации - PPPoE или веб-авторизация при изменении mac-адреса на порту коммутатора

Так я что, против? Я использую VPN или PPPoE для раздачи интернета, MAC для выдачи динамического локального IP при помощи DHCP который одновременно выдает юзеру кучу статических маршрутов, которые ему нужны в обязательном порядке и о которых он даже не догадывается. При задолженности юзеро просто изменить каким-нибудь заведомо хитрым способом MAC в биллинге и он попадает в гостевую сеть, где у него ничегошеньки нет. В 99% случаев - этого оказывается достаточно, чтобы юзер оплатил услуги. И только в 1-2% это не помогает и нужно использовать отключение порта... так зачем платить больше? а, Мрья Ивановна? Управляемое оборудование на сегодняшний день не оправдано дорого стоит а при грозах горит точно так-же как мыльницы. Так, что Алексей... я пока воздержусь )) и посмотрю на твой пример )))

[Maks]

Перейти на pppoe

тыщупиццот абонентов загнать в ПППоЕ - это какие железяки нужны?

Сеть Fregat  в моем городе как раз юзает один софтовый  сервак на каждые  тыщупиццот pppoe абонентов

А не могбы пожалуйста подсказать параметры этого сервера?
а то окажется 4 головый  4 ядерный ксеон, только вопрос сколько он стоит и оправдано ли тогда PPPoE

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

[Efendy]

А не могбы пожалуйста подсказать параметры этого сервера?

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

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

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

[versus]

Просто в утм авторизатор работает на tcp и файрволы с ним гораздо больше дружат, как впрочем и роутеры. Может имеет смысл задуматься? Лично я вообще отказался т.к. накушался этого по самое нехочу.

Разницы нет для виндового файра удп траф будет слать нодени авторизатор или тцп. Ему важен факт что какая то прога просится на нестандартный порт отправлять соединения! Вот и спрашивает пользователя мол аааааа тут вот  эта, запретить ?

[Efendy]

Я объяснял уже (http://forum.nodeny.com.ua/index.php?topic=63.0):

Внимание! Существует серьезный нюанс, касаемый UDP-соединения. Обычно, как происходит обмен данными по UDP протоколу:

Хост_1 посылает UDP пакет на Хост_2 порт, допустим, 7723. При этом у пакета src-port устанавливается системой (обычно из верхних портов 1024...65535). В дальнейшем хост_2 посылает ответы именно на этот порт.

В NoDeny иначе. Сначало объясню почему иначе. В L2-авторизатор встроен механизм пингования между авторизаторами по команде сервера. Т.е. администратор может дать команду "авторизатор такого-то клиента пропингуй авторизатор такого-то клиента и предоставь статистику по потерям". Такой пинг интересен двумя моментами:

1) позволяет отловить проблемный линк. Допустим, мы находимся в центре сети и пингуем клиента А и клиента Б. Проблемный линк (плохо обжатая/поврежденная витая пара) находится между нами и ближайшим к нам клиентом. Следовательно, мы получим потери как при пинговании клиента А, так и клиента Б. Если же мы дадим команду авторизатору А пропинговать Б, то можем увидеть - есть ли проблемы на всем протяжении коммуникакций от А до Б.

2) пингование идет не по icmp протоколу, а по udp и, как вы могли дагадаться, на порт 7723. Почему так? Потому что icmp протокол часто запрещен фаерволом, а udp порт 7723 клиент вынужден открыть для работы авторизатора.

Пока фича не активирована (в nol2auth.pl) т.к. с появлением управляемого оборудования появились иные методы отлова проблемных линков. Тем не менее, изначальный протокол построен исходя из предположения, что авторизатор будет слушать 7723 порт, т.е принимать входящие соединения.

Еще раз. Когда хост_1 посылает куда-то пакет, он открывает сокет, на который принимает ответные пакеты. В авторизаторе мы изначально биндим 7723 порт, т.е принимаем пакеты, это уже иной сокет!

поэтому для фаервола это выглядит так, как будто сервер устанавливает соединение с клиентом! Любые входящие соединения фаерволы воспринимают стремно. Но такова специфика протокола. Можно его переделать, кстати, но мне этим заниматься пока некогда, да и не вижу смысла