Jump to content

Recommended Posts

Posted

Значится так... Имеем список доменов от РосКомНадзора. На своём 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>

 

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

Posted

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

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

Posted (edited)

Я так понял, вам нужно завернуть запросы к 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

Edited by roysbike
Posted (edited)

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

 

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

 

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

Edited by krovozhadina
Posted

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

 

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

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

Posted (edited)

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

Edited by krovozhadina
Posted (edited)

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

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

 

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

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

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

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

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

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

Posted

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

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

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

 

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

Posted

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

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

 

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

:)

Posted (edited)

krovozhadina

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

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

Edited by Andris
Posted

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

Posted

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

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

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

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

Posted

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

 

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

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

Posted

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

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

Posted

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

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

Posted

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

ipset

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

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

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

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

Posted

Зачем BIND то?

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

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

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.