Хитрая настройка DNS

[Negator]

Интересует простой вопрос.

Можно ли настроить DNS сервер таким образом, чтобы при попытке доступа к любому доменному имени выдавался бы определенный IP?

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

Edited September 5, 2008 by Negator

[Mnemoid]

Интересует простой вопрос.

Можно ли настроить DNS сервер таким образом, чтобы при попытке доступа к любому доменному имени выдавался бы определенный IP?

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

Мне кажется, что это не самый лучший вариант решать поставленную задачу средствами DNS сервера.

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

- для всех пакетов, у которых порт в адресе назначения равен 80, применить DNAT, подставив в качестве нового адреса назначения, адрес веб-сервера где лежит эта страница;

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

[ugluck]

фокус с ДНС-сервером, ресолвящим любой хостнейм заданным айпишником применим при PPP или DHCP, где юзеру динамически выдаются настройки IP, в т.ч. и DNS. такой левый ДНС-сервер выдаем неплательщикам. всем остальным - другой, нормальный ДНС-сервер. при переходе баланса через ноль необходимо переконнекчиваться, что при DHCP нереально. на PPPoE такая схема работает, проверено. Адрес ДНС-сервера назначается в отдельном радиус-атрибуте в акцесс-акцепте, там же навешивается (если надо) акцесс-лист или нат-инсайд

[disappointed]

А мне вот думается просто уводить неплательщиков в другой пул (если PPP) и на ДНСе сделать view секцию (если BIND) под них.

[ksm]

Интересует простой вопрос.

Можно ли настроить DNS сервер таким образом, чтобы при попытке доступа к любому доменному имени выдавался бы определенный IP?

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

С ДНСом плохая идея.

Неплохо работает такой вариант (radius+cisco+iptables+apache).

1. Отключенного юзера сажаем за нат с одним выделенным реальным ip (OFF_NAT_IP) - т.е. все отключенные юзеры имеют один и тот же реальный IP. Далее на циске роутмапом любой трафик с OFF_NAT_IP направляем на IP (OFF_SERVER_IP), где живет сайт со страничкой "Вы отключены".

2. На сервере в iptables указываем, что трафик с OFF_NAT_IP направлять на OFF_SERVER_IP.

3. На сервере рисуем нужную страничку.

4. Всё :-)

 

Важные моменты:

- на адресе OFF_SERVER_IP должен жить только веб сайт со страничкой "Вы отключены" (хотя на этом же сервере на других IP могут жить и другие веб сайты)

- отключенному юзеру на дать доступ на свой днс (чтобы резольвить имена) и на любой www трафик

 

Схема работает уже полгода и в общем достаточно неплохо.

 

[Negator]

фокус с ДНС-сервером, ресолвящим любой хостнейм заданным айпишником применим при PPP или DHCP, где юзеру динамически выдаются настройки IP, в т.ч. и DNS. такой левый ДНС-сервер выдаем неплательщикам. всем остальным - другой, нормальный ДНС-сервер. при переходе баланса через ноль необходимо переконнекчиваться, что при DHCP нереально. на PPPoE такая схема работает, проверено. Адрес ДНС-сервера назначается в отдельном радиус-атрибуте в акцесс-акцепте, там же навешивается (если надо) акцесс-лист или нат-инсайд

 

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

 

 

 

Значит уточню задачу

1-Внутри сети абоненты имеют статические ИП, соответтсвенно шлюз и ДНС. В интернет ходят через PPPOE.

Однако неплательщикам очень не хочется поднимать ppp сессию. Лишняя нагрузка на оборудование ни к чему. Слушаю ваши предложения.

Сразу говорю - схема адресации меняться не будет.

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

 

Оборудование везде управляемое. внутрисетевой шлюз - CISCO 3560G

 

Если бы внутри сети было DHCP- то проблем нет. Делаем отдельный пул адресов и вперед - кончились деньги - переводим абонента в другой специальный вилан, в котором есть интерфейс DHCP сервера.

 

Со статикой сложнее. есть порядка 20-30 подсетей /24.

 

Сейчас напишу то как я мыслю:

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

 

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

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

То есть у нас получается маленький аналог центральной циски в отдельном вилане. Типа для неплательщиков. И маршрутизирует всех их уже длинк.

Далее. На отдельной железке поднимаем днс сервер с таким же адресом что и прописан у абонентов и включаем его в тот же вилан.

 

Ну собственно далее уже был задан первоначальный вопрос.

 

 

2-Собственно все то же самое, но не используем железку вообще, а тупо создаем кучу интерфейсов на линуксовой машинке, подключенной в этот влан, редиректим весь траффик по 80 порту с нее на веб сервер с нужной страницей, режем весь траффик по другим портам на всякий случай. Длинк 3 уровня редиректить не умеет гад:)

 

 

 

Покритикуйте схему, может еще что нибудь кто нибудь предложит.

Edited September 8, 2008 by Negator

[ugluck]

если оборудование позволяет пересадить неплательщика в другой влан - то все ок, и 2-я схема мне кажется проще (читай: надежнее)

[mikevlz]

у 36-й серии гигабитных D-Link есть ACL-based policy routing. Пакетам, попадающим под правило меняет next-hop

[Negator]

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

Чувствую что есть простое и красивое решение.

Если не жалко - поделитесь у кого что реализовано на этот счет.

[GateKeeper]

Странно, что никто не вспомнил схему с transparent proxy.

 

Итак: абоненты, сожравшие все деньги провайдера, но еще не сытые, согласно правилу DNAT идут в порт прозрачной прокси. Сама прозрачная прокся при этом имеет ровно ноль доступа куда-либо наружу. При этом нельзя переусердствовать с правилами: никаких DROP/DENY, только REJECT/RETURN, чтобы страница с сообщением об ошибке доступа к сайту проксёй отдавалась мгновенно. А вот там, на этой странице...

[Negator]

И где вы предлагаете это делать? На центральном маршрутизаторе? А если абонент скажем ип адрес поменяет? Кроме того это не соответсвует условиям задачи.

Нет, не совсем верно. Надо исходить из того, что известны порты пользователей на конечных свичах.

[GateKeeper]

Ключевое здесь "в интернет ходят через PPPoE". Т.е. адрес они не поменяют. А условия задачи какие? Я там сейчас углядел только "PPP поднимать не хочется" - не поднимайте, сделайте так, что при отсутствии PPP-сессии у них дефолтный DNAT на порт прокси.

 

Ну, в общем, я лишь предположил. Настаивать не буду.

[EvilShadow]

Я там сейчас углядел только "PPP поднимать не хочется" - не поднимайте, сделайте так, что при отсутствии PPP-сессии у них дефолтный DNAT на порт прокси.

Есть подозрение, что абонент с неподнимающимся туннелем скорее позвонит в поддержку, чем попробует использовать интернеты без него. Поэтому "не хочется поднимать PPP" - это мечта. Либо Вы позволяете абоненту поднять туннель, а уже в нем режете все, кроме 80 порта, а 80 ДНАТите на сервер с нужными извещениями, либо придется каждому объяснять, что в случае ошибки при поднятии туннеля он должен не запускать ВПН, а пробовать интернеты без него. По-моему, проще рассказать, что в случае виндозной ошибки 691 при поднятии туннеля абоненту следует заглянуть на собственную страницу статистики.

[nuclearcat]

А что если как вариант, скажем если клиент проплатил - его порт залинкован на vlan реального роутера.

Если нет - его порт/vlan прилинкован к vlan где стоит "злобныйсервер", который хавает все запросы DNS и tcp на порт 80. Ну и выдает страничку и ip.

 

[Grey]

а что мешает откидывать соединение при отрицательном балансе и переводить в радиусе клиента в группу выключенных ... следующее соединение просто не будет поднято (не даст этого сделать радиус)?

[mr.Scamp]

а почему бы просто не тушить порт?

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

 

[Negator]

а что мешает откидывать соединение при отрицательном балансе и переводить в радиусе клиента в группу выключенных ... следующее соединение просто не будет поднято (не даст этого сделать радиус)?

так и делается. Речь не об этом. Речь о том чтобы страницу выдавать

а почему бы просто не тушить порт?

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

порт и так тушится через 15 дней. Но негуманно это.

 

Надо сделать для идиотов, которые не понимают что такое ошибка 691, которые не знают ничего. Таких стало много. У них на все один ответ - интернет не работает. А залезть проверить баланс - не в состоянии. По статистике звонков в техподдержку таких 30%. Для них и делается.

[nuclearcat]

Ну на линуксовом NAS я такое буду делать, в принципе делается очень просто.

При ip-up запускаем демона который делает правило в iptables - редиректить пакеты "куда-надо", и через 5 минут дисконнектить. Когда страничка открыта, на страничке буду делать контрольную картинку (что страничка загружена браузером а не каким-нить download managerom, если у юзера комп на автопилоте). Через минуту дисконнекчу юзера. После 2-3 коннектов с прочтением странички (по контрольной загрузке картинки) или 10-15 без прочтения - выносим юзера из радиуса, чтоб была ошибка авторизации.

 

[Negator]

Ну на линуксовом NAS я такое буду делать, в принципе делается очень просто.

При ip-up запускаем демона который делает правило в iptables - редиректить пакеты "куда-надо", и через 5 минут дисконнектить. Когда страничка открыта, на страничке буду делать контрольную картинку (что страничка загружена браузером а не каким-нить download managerom, если у юзера комп на автопилоте). Через минуту дисконнекчу юзера. После 2-3 коннектов с прочтением странички (по контрольной загрузке картинки) или 10-15 без прочтения - выносим юзера из радиуса, чтоб была ошибка авторизации.

а ведь отличная идея, попробуем

[ugluck]

насчет лишней нагрузки от неплательщиков... Вы хотите сказать, что ваш БРАС не рассчитан на нагрузку от _всех юзеров сети? И какой процент неплательщиков заложен в расчеты?

[Negator]

Есть несколько серверов PPPOE , при необходимости конфигурятся и ставятся дополнительно еще сервера. Этот процесс идет постоянно и с необходимым запасом по производительности. Если конечно ВСЕ абоненты войдут в сеть одновременно, то текущие сервера думаю не справятся, но теория массового обслуживание говорит что такого не бывает.

 

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

[EvilShadow]

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

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

[ugluck]

вообще-то БРАС (PPPOE/PPtP-сервер) для того и нужен, чтоб авторизовывать, редиректить, полисить юзеров. если функции БРАСа вынести на свич - то получим "совсем распределенный" БРАС, т.е. если свич будет авторизить, полисить и редиректить - то никакое PPPOE/PPtP и не нужно!

[Negator]

Да собственно уже почти готовы от PPPOE отказаться. Останавливает только то что надо переучивать и менять настройки у кучи абонентов.

[grfmaniak]

Интересует простой вопрос.

Можно ли настроить DNS сервер таким образом, чтобы при попытке доступа к любому доменному имени выдавался бы определенный IP?

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

Если используется bind9, то можно. Неплательщикам выдаем адрес из определенной подсетки, например 192.168.13.0/24 На dns прописываем view для этой подсетки, в которой показываем зоны .ru, .org, .com, .net из локального файла вида

 

@ IN A 192.168.13.254

* IN A 192.168.13.254

 

Таким образом на любой запрос клиент получит адрес 192.168.13.254 на который и пойдет. На этом адресе его должен ждать апач с нужной страничкой типа "заплати и лети". Для верности на апаче настроить по коду 404 выдачу этой же странички. Проверено, работает. Таким макаром, правда, выдаю клиентам страницу с требованием вирусы вылечить.

Edited September 15, 2008 by grfmaniak