[krovozhadina]

Значится так... Имеем список доменов от РосКомНадзора. На своём named прописываем зоны, якобы они находятся у нас и ссылаются на внутренний IP http сервера. Там уже страничка с заглушкой.

Клиенты ходят в интернет через vpn и им выдаётся адрес DNS-сервера внутренний (кеширующий), так что все они видят на заблокированных доменах заглушку.

 

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

 

Как завернуть такие пакеты с iptables ?

iptables -t nat -A PREROUTING -i <IP_VPN_SERVER> -p udp --dport 53 -j DNAT --to-destination <IP_DNS_SERVER>
iptables -t nat -A PREROUTING -i <IP_VPN_SERVER> -p tcp --dport 53 -j DNAT --to-destination <IP_DNS_SERVER>
iptables -t nat -A POSTROUTING -p tcp --dst <IP_DNS_SERVER> --dport 53 -j SNAT --to-source <IP_VPN_SERVER>
iptables -t nat -A POSTROUTING -p udp --dst <IP_DNS_SERVER> --dport 53 -j SNAT --to-source <IP_VPN_SERVER>

 

Почему-то так не работает...

[ipaddr.ru]

Хочется завернуть все попытки обратиться к сторонним DNS завернуть на внутренний

Зачем?

[MMM]

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

Вероятно, поломаете резолв тем, у кого свой резолвер

[roysbike]

Я так понял, вам нужно завернуть запросы к DNS на ваш DNS, если даже клиент укажет 8.8.8.8?

$IPTABLES -t nat -A PREROUTING -p udp --dport 53 -s 172.30.0.0/17 -j DNAT --to ВАШ_DNS:53

Изменено 14 декабря, 2016 пользователем roysbike

[terrible]

РКН проверяет доступность сайтов согласно настроек оператора, а не 8.8.8.8, т.е. забивайте на это дело болт.

[krovozhadina]

ipaddr.ru, затем чтобы клиент при обращении к сайту xxx.com получал резолв не 1.2.3.4 , а мой сервер, на котором я могу показать заглушку. Можно конечно просто заблокировать обращение к 53 порту сторонних адресов, но это не очень хорошо... Хочется чтоб клиент не замечал подмены.

 

roysbike, именно так и хочется, но эта запись не работает... я в первом посте указал пример который я пробовал

 

terrible, нас теперь еще и радиочастотная служба контролирует, а у них есть ПО Ревизор. Это маленький бот, который мы обязаны поставить у себя в сети. С помощью этого бота они проверяют доступность ресурсов. Есть портал (portal.rfc-revizor.ru) на котором присутствует личный кабинет оператора. Внутри ЛК можно заказать отчет о выявленных нарушениях. Вот буквально пару дней назад РКН уже прислали гневное письмо, что у нас 0.1% не заблокировано оказывается. Думается мне, что эта цифра будет расти.

Изменено 15 декабря, 2016 пользователем krovozhadina

[roysbike]

roysbike, именно так и хочется, но эта запись не работает... я в первом посте указал пример который я пробовал

 

terrible, нас теперь еще и радиочастотная служба контролирует, а у них есть ПО Ревизор. Это маленький бот, который мы обязаны поставить у себя в сети. С помощью этого бота они проверяют доступность ресурсов. Есть портал (portal.rfc-revizor.ru) на котором присутствует личный кабинет оператора. Внутри ЛК можно заказать отчет о выявленных нарушениях. Вот буквально пару дней назад РКН уже прислали гневное письмо, что у нас 0.1% не заблокировано оказывается. Думается мне, что эта цифра будет расти.

Да ладно , не работает. Как натите и где? Я это указываю на тачке где NAT. Я сам иногда использую это опцию

[krovozhadina]

roysbike, вот что имею

DNS 10.0.0.4

NAT 10.0.0.11

клиент 10.0.0.222

iptables -t nat -A PREROUTING -i 10.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 10.0.0.4
iptables -t nat -A POSTROUTING -p tcp --dst 10.0.0.4 --dport 53 -j SNAT --to-source 10.0.0.11

 

Выставил вручную на компе DNS 8.8.8.8 . Проверяю

>nslookup zv.fm
╤хЁтхЁ:  google-public-dns-a.google.com
Address:  8.8.8.8

Не заслуживающий доверия ответ:
╚ь :     zv.fm
Address:  62.76.113.154

Изменено 15 декабря, 2016 пользователем krovozhadina

[krovozhadina]

Вот так заработало

selfip="10.0.0.11"
dnsip="10.0.0.4"
nw="10.0.0.0/24"
iptables -t nat -A PREROUTING -s $nw -p udp --dport 53 -j DNAT --to-destination $dnsip
iptables -t nat -A PREROUTING -s $nw -p tcp --dport 53 -j DNAT --to-destination $dnsip
iptables -t nat -A POSTROUTING -p tcp --dst $dnsip --dport 53 -j SNAT --to-source $selfip
iptables -t nat -A POSTROUTING -p udp --dst $dnsip --dport 53 -j SNAT --to-source $selfip

 

Проверяю

>nslookup zv.fm
╤хЁтхЁ:  google-public-dns-a.google.com
Address:  8.8.8.8

╚ь :     zv.fm
Address:  10.0.0.4

 

Всем спасибо за участие :)

Изменено 15 декабря, 2016 пользователем krovozhadina

[terrible]

terrible, нас теперь еще и радиочастотная служба контролирует, а у них есть ПО Ревизор. Это маленький бот, который мы обязаны поставить у себя в сети. С помощью этого бота они проверяют доступность ресурсов. Есть портал (portal.rfc-revizor.ru) на котором присутствует личный кабинет оператора. Внутри ЛК можно заказать отчет о выявленных нарушениях. Вот буквально пару дней назад РКН уже прислали гневное письмо, что у нас 0.1% не заблокировано оказывается. Думается мне, что эта цифра будет расти.

Дык у них дампы бывают кривые, вот и выползает 0.1%. У нас аналогично, но мы всегда прорабатываем неблокируемые сайты и о нашей работе в этом направлении всегда уведомляем РКН, проблем нет.

[Andrei]

terrible, нас теперь еще и радиочастотная служба контролирует, а у них есть ПО Ревизор. Это маленький бот, который мы обязаны поставить у себя в сети. С помощью этого бота они проверяют доступность ресурсов. Есть портал (portal.rfc-revizor.ru) на котором присутствует личный кабинет оператора. Внутри ЛК можно заказать отчет о выявленных нарушениях. Вот буквально пару дней назад РКН уже прислали гневное письмо, что у нас 0.1% не заблокировано оказывается. Думается мне, что эта цифра будет расти.

Дык у них дампы бывают кривые, вот и выползает 0.1%. У нас аналогично, но мы всегда прорабатываем неблокируемые сайты и о нашей работе в этом направлении всегда уведомляем РКН, проблем нет.

Как прорабатываете? Ручками/глазками? И как уведомляете РКН?

[terrible]

Как прорабатываете? Ручками/глазками? И как уведомляете РКН?

Брали как-то у РКН программу для оценки качества блокировки, она и писала, что незаблокировано.

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

 

А вообще можно и свою прогу написать, которая бы сама пробовала открывать указанные URL по списку.

[Andrei]

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

Можно, но они совершенно неудобоваримые, хотя ревизор у меня программный, но это не важно.

 

А вообще можно и свою прогу написать, которая бы сама пробовала открывать указанные URL по списку.

:)

[Andris]

krovozhadina

Хочется чтоб клиент не замечал подмены.

Это наивно — т.е. до первого технически грамотного клиента. А если он окажется ещё и подкованным юридически… ;)

Изменено 20 декабря, 2016 пользователем Andris

[myth]

А если он окажется ещё и подкованным юридически… ;)

У него что-то не работает?

[Andris]

myth, после таких манипуляций со стороны провайдера да, может не работать что-то, завязанное на собственные DNS.

[alibek]

прислали гневное письмо, что у нас 0.1% не заблокировано оказывается

Есть тип блокировки по IP-адресу и по подсети.

Таких адресов в реестре больше восьмисот.

Они через маневры с DNS не блокируются.

[myth]

замечательно блокируются маневрами с ipset

 

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

решается индивидуально. Пока таких клиентов нет.

[^rage^]

ipaddr.ru, затем чтобы клиент при обращении к сайту xxx.com получал резолв не 1.2.3.4 , а мой сервер, на котором я могу показать заглушку. Можно конечно просто заблокировать обращение к 53 порту сторонних адресов, но это не очень хорошо... Хочется чтоб клиент не замечал подмены.

у клиента может быть свой udp-протокол на 53 порту. например, vpn.

[sergsa]

можно 53 порт ревизору закрыть и все, использовать это как дополнительную фильтрацию перед DPI и вообще можно чисто над ревизором так издеваться.

проблема только в том, что по маске субдомена не заблокируешь ни чего, а еще ip как то отдельно блокировать, так что без dpi все равно ни как, но как допонительный фильтр годится

[myth]

а еще ip как то отдельно блокировать

ipset

[sergsa]

а еще ip как то отдельно блокировать

ipset

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

Интересно BIND не повесится от 60000 записей?

А поверх всего еще и DPI должен стоять...

Хорошо бы коммутатор с ACL на сотни тысяч записей для ip блокировок, какой нибудь древний и дешевый.

[alibek]

Интересно BIND не повесится от 60000 записей?

Зачем BIND то?

Есть Unbound и dnsmasq, последний должен быть оптимальным.

[sergsa]

Зачем BIND то?

Есть Unbound и dnsmasq, последний должен быть оптимальным.

BIND уже стоит, на нем соответственно висят PTR и А записи.

Просто не хочется городить огород ради второй линии обороны для ревизора, если без DPI все равно ни как не обойтись. Тем более СКАТ уже стоит, просто его тоже нужно резервировать.

[myth]

поверх всего еще и DPI должен стоять

зачем?