Subnets.ru

Добрый день,

имеем коммутаторы dlink, на них есть acl для разрешения работы или блокировки всего, кроме окна для биллинга.
есть шлюз микротик, на котором подняты фаервол и маршрутизация, с возможностью блокировки.
недавно стала задача отправлять заблокированных на страницу с напоминанием об оплате, решили открыть на коммутаторах acl'ом http трафик всюду, при любом состоянии, а на микротиках заворивачивать трафик на его прокси и отправлять на нужную страницу.

на коммутаторах:

Код: Выделить всё

create access_profile  ip  source_ip 255.255.255.255 destination_ip 255.255.255.255 tcp src_port 0xFFFF   dst_port 0xFFFF    profile_id 1
config access_profile profile_id 1  add access_id 1  ip  tcp dst_port 80        port 1-28 permit
config access_profile profile_id 1  add access_id 2  ip  tcp dst_port 81        port 1-28 permit
config access_profile profile_id 1  add access_id 3  ip  tcp src_port 80        port 1-28 permit
config access_profile profile_id 1  add access_id 4  ip  tcp src_port 81        port 1-28 permit
config access_profile profile_id 1  add access_id 5  ip  tcp dst_port 53        port 1-28 permit
config access_profile profile_id 1  add access_id 6  ip  tcp src_port 53        port 1-28 permit
create access_profile  ip  source_ip 255.255.255.255 destination_ip 255.255.255.255 udp src_port 0xFFFF   dst_port 0xFFFF    profile_id 2
config access_profile profile_id 2  add access_id 1  ip  udp dst_port 53        port 1-28 permit
config access_profile profile_id 2  add access_id 2  ip  udp src_port 53        port 1-28 permit

т.е. трафик 80 и 81 (там находится страница блокировки) открыт в обе стороны. хочу спросить, чисто логически я понимаю, что без каких либо настроек на стороне абонента (настроек прокси) надо настроить так чтобы абонентское оборудование могло общаться со всем миром, чтобы в итоге получить от искомого сервера (по факту от прокси шлюза) HTTP 307 Redirect, но может быть есть какой то более красивый способ, которым можно ограничить абонента от общения с внешним миром и в тоже время "подсунуть" ему другую страничку.

По-нормальному делается иначе.
Сервер доступа должен быть по умолчанию закрытым, т.е. при авторизации для клиента добавляется разрешающее правило в firewall и клиент выходит в инет, при грохании сессии правило удаляется. А вот дальше задача ставится иначе: вам нужно каким-то образом отдать серверу доступа данные о заблокированных людях, будь то радиус или просто скрипт. Скрипт переписывает в правилах таблицу с запрещенными хостами. Далее либо сервер отказывает клиенту в авторизации, либо его редиректит на страницу с требованием оплатить услуги. Вопрос встает только в том каким методом у вас проходит авторизация. А вот от прокси + навернем на него что-то еще + добавим песочницу, такое делать не надо.

И еще, по опыту администрирования сети и доступа клиентов в интернет могу сказать, что "на стороне клиента надо сделать..." - это уже прошлый век. ВСЁ должны делать вы за клиента, после этого у вас будет нормальный сервис.

И еще, по опыту администрирования сети и доступа клиентов в интернет могу сказать, что "на стороне клиента надо сделать..." - это уже прошлый век. ВСЁ должны делать вы за клиента, после этого у вас будет нормальный сервис.

да как бы это дело ясное =) потому и стараемся максимально облегчить жизнь хомякам.

Сервер доступа должен быть по умолчанию закрытым, т.е. при авторизации для клиента добавляется разрешающее правило в firewall и клиент выходит в инет, при грохании сессии правило удаляется. А вот дальше задача ставится иначе: вам нужно каким-то образом отдать серверу доступа данные о заблокированных людях, будь то радиус или просто скрипт. Скрипт переписывает в правилах таблицу с запрещенными хостами. Далее либо сервер отказывает клиенту в авторизации, либо его редиректит на страницу с требованием оплатить услуги. Вопрос встает только в том каким методом у вас проходит авторизация

авторизация у нас на порту коммутатора по dhcp.opt82 им выдает адрес и по acl не дает использовать никакой другой адрес на этом порту.
при активном (по состоянию биллинга) абоненте на шлюзе его адрес добавляется в access лист, при заблокированном в deny. на коммутаторе удаляется из acl c разрешением всего и добавляется в окно для страницы статистики. никаких vpn не используем.
с объяснением железкам кто должен иметь доступ, а кто нет. у нас всё хорошо.

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

simpl3x писал(а):авторизация у нас на порту коммутатора по dhcp.opt82

ну, дык эта... Повесьте правило типа:

Код: Выделить всё

rdr on port1 proto tcp from !<permgroup> to any port 80 -  > 192.168.0.1
permit from <permabonent> to any
permit from any to <permabonent>
deny any any


пример кода для pf ОС freebsd

По идее больше ничего и не надо. Нужно только грамотно настроить файрволл.
Я так понимаю, что у вас роутер mikrotik, на котором установлена горе RouterOS с поддержкой L3 И еще чего-то. Почитайте доки по этой ОСи. Сам я раньше ставил эту, так сказать, ОСь, но далеко в ней не продвинулся, хотя, думаю, что там нет ничего сверхъестественного, т.к. люди делали для людей.

Все дело в том как будет редирект происходить и как будет идентифицироваться клиент по своему статусу.

да, я так же пытался. на микротике редирект делаю, SYN до сервера с заглушкой долетает, и он отвечает SYN, ACK, а вот у себя я его уже не вижу. и по кругу, и по таймауту отбой. и между мной и заглушкой при обратном ответе уже ничего нет, в одной подсети сидим.

вру. обратные SYN,ACK от сервера с заглушкой прилетает. но ничего не происходит, когда делаю dnat всего что прилетает по 80 порту от абонента на сервер заглушки. т.е. как то по аналогии с rdr pf

Да зачем блокировать syn? О_о. в этом случае вы коннект не установите.
Вам надо редиректить весь трафик адресованный 80му порту внешнего сервера на свой внутренний, если у клиента нет доступа к инету.

simpl3x писал(а): когда делаю dnat

- тогда вы включаете нат на сервере, скорее всего.

rdr на нате служит для 2х вещей. Для portforwarding и для редиректа.

ЗЫ. Почитайте что такое tcp соединение и для чего надо syn. Сдается мне, у вас такая же каша, как у меня года 4 назад.

Да где тут написано, что я блокирую syn? Я просто описываю ситуацию которая у меня складывается.
улетает от меня syn (к яндексу), на шлюзе dst-nat разворачивает его на сервер со страницей заглушкой, сервер отвечает на него syn,ack и этот пакет летит ко мне, долетает до меня и ... Бестолку! Дальше все по кругу.

Нат на шлюзе и так включен. Часть клиентов натится, часть клиентов роутится. Между собой все роутится. После правил роутинга, перед правилами ната - ставлю правило dst-nat о котором идет речь выше. В итоге сервер видит мои пакеты с соим реальным адресом, я вижу пакеты сервера с его реальным адресом.

simpl3x писал(а):ничего лучше заворота на прокси не получилось сделать.

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

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

второй вариант это отключенным выдавать IP-адрес и определенной подсети с минимальным временем лизы и def gw на "заглушку"
или + к этому ещё и переводить таких абонов в отдельный влан, где опять же выдавать IPшник из пула (основываясь на номере влана, который прилетает по option 82)

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

Код: Выделить всё

20 X ;;; REDIRECT BALANCE
     chain=dstnat action=dst-nat to-addresses=IP_BACKEND to-ports=81 protocol=tcp dst-address=0.0.0.0/0 src-address-list=DENY_LIST dst-port=80