+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

DNS Wireguard не работает, как ожидалось

DNS Wireguard не работает, как ожидалось, RouterOS

dazzaling69

Guest

03.06.2024 10:21:00

У меня есть рабочий экземпляр WireGuard и Pi-hole, который блокирует кучу рекламы, всё это работает на одном роутере. Весь трафик принудительно направляется через Pi-hole с помощью правил NAT. Если я подключаюсь к своей сети без VPN и запускаю тест на блокировку рекламы (d3ward.github.io), блокируется примерно 64% рекламы. Если же я подключаюсь через WireGuard на роутере и запускаю тот же тест, блокируется всего 21%. Я не могу понять, как соединение WireGuard обходится без прохождения через Pi-hole, ведь весь DNS-трафик принудительно (через правило NAT на порт 53) идет именно туда. Я заявляю свой роутер как DNS-сервер и использую правило NAT, чтобы отправлять трафик на Pi-hole (который находится в другом диапазоне IP), так что я могу легко включать и выключать блокировку. Может ли в протоколе WireGuard, как он реализован в RouterOS, быть что-то, что обходит это правило NAT? Это единственное, что я могу придумать, почему это не работает.

dazzaling69 Guest	#2 0 26.06.2024 14:11:00 У меня все еще проблемы с этим. Кто-нибудь знает, почему pinhole не блокирует рекламу для WireGuard?

jvanhambelgium

Guest

26.06.2024 14:35:00

add action=dst-nat chain=dstnat comment= “Принудительно перенаправлять все UDP-запросы DNS, которые не идут на pihole, на pihole” dst-address=!172.17.0.2 dst-port=53 in-interface=“Local Bridge” protocol=udp src-address=!172.17.0.2 to-addresses=172.17.0.2
add action=dst-nat chain=dstnat comment= “Принудительно перенаправлять все TCP-запросы DNS, которые не идут на pihole, на pihole” dst-address=!172.17.0.2 dst-port=53 in-interface=“Local Bridge” protocol=tcp src-address=!172.17.0.2 to-addresses=172.17.0.2

Ну... ваши правила перехвата/NAT ожидают, что пакеты UDP/TCP на порт 53 будут приходить с “Local Bridge”??? Скорее всего, это не ваш интерфейс wireguard, поэтому эти правила не срабатывают для трафика WG?

llamajaja

Guest

26.06.2024 14:45:00

Я посмотрю. Цель — чтобы роад-варьеры или любой пользователь, подключающийся через Wireguard и выходящий в локальный интернет на порту 5009, шли через DNS Pi-hole.

(1) Добавляем Wireguard в LAN интерфейс:
/interface list member add interface="Local Bridge" list=listBridge
add interface=Vodafone list=WAN
add interface="Port 8 - WAN" list=WAN
add interface=dockers list=listBridge
add interface=wireguard1 list=LAN

(2) Правила файрвола у меня выглядят запутанными, но, кажется, ты учёл всё... Меня немного смущает, что dockers — это мост, а у него есть veth с другим IP, отличным от LAN. И пока не понятно, какой IP у PIhole на роутере??? Ладно, посмотрю позже!
Одна вещь, чего может не хватать — в цепочке FORWARD разрешить трафик с wireguard на dockers!!! Просто измени это правило...
Было:
add action=accept chain=forward comment="Docker forward rule" in-interface="Local Bridge" out-interface=dockers
На: (учитывая, что мы добавили wireguard в LAN выше)
add action=accept chain=forward comment="Docker forward rule" in-interface-list=LAN out-interface=dockers

(3) Принуждение трафика к Pi-hole кажется тоже запутанным. Давай попробуем упростить.
Мне непонятно назначение ПЕРВОГО ПРАВИЛА???
add action=dst-nat chain=dstnat comment=PiHole dst-address=10.160.100.1 dst-port=888 in-interface="Local Bridge" in-interface-list=all protocol=tcp to-addresses=172.17.0.2 to-ports=80

(4) Следующие два правила — распространённые. Одно заставляет весь DNS-трафик идти на нужный IP, кроме тех IP, которые админ не хочет туда пускать, плюс, конечно, адрес самого Pi-hole, чтобы избежать зацикливания — ха-ха.
add action=dst-nat chain=dstnat comment="force all users to DNS pihole" in-interface-list=LAN dst-port=53 protocol=udp src-address-list=!Excluded to-addresses=172.17.0.2
add action=dst-nat chain=dstnat comment="force all users to DNS pihole" in-interface-list=LAN dst-port=53 protocol=tcp src-address-list=!Excluded to-addresses=172.17.0.2

Где:
/ip firewall address-list
add address=172.17.0.2 list=Excluded
add address —> list=Excluded (любые другие отдельные IP или подсети и т.п.)

ГИБКИЙ ПОДХОД.

dazzaling69

Guest

30.06.2024 17:26:00

Спасибо за ваш ответ. На прошлой неделе я был в поездке, поэтому заметил проблему с трафиком и поэтому отвечал с опозданием. По поводу вашего вопроса: стоит ли добавлять Wireguard в локальную сеть — это хорошая, плохая или нейтральная идея? Обычно у меня сеть разграничена (в моём случае, например, по диапазонам IP и другим критериям), но я недостаточно хорошо разбираюсь в VPN, чтобы понимать все последствия и возможные проблемы. Почему вы думаете, что это может быть неудобно? Я в этом деле новичок, так что каждый день — это возможность чему-то научиться.

Правило для порта 888 открывает веб-интерфейс конфигурации для экземпляра pi-hole. Значит ли это, что нужно: а) вместо просто интерфейса указать список интерфейсов, и б) убрать исключение для адреса назначения pi-hole? Спасибо!

anav

Guest

30.06.2024 18:14:00

Ну, у тебя есть два варианта.
а. Отправлять трафик WireGuard без использования функционала PI, а PI работает для остальной части локальной сети.
б. Отправлять трафик PI не на 1.1.1.1 или 8.8.8.8, а на DNS-сервер провайдера, и тогда все пользователи WireGuard автоматически будут использовать твой PI-сервер. НО при этом и остальной трафик локальной сети тоже будет через него идти.

Можно разделить, чтобы WireGuard использовал PI, а локальный трафик шел через какой-нибудь DOH-сервис через Mikrotik...

dazzaling69

Guest

01.07.2024 11:45:00

Нет ли способа настроить маршрут к контейнеру PiHole/VETH и направлять туда DNS-трафик независимо от доступа к локальной сети? Я не понимаю, почему контейнер нельзя сделать доступным для WireGuard именно таким образом…

anav

Guest

01.07.2024 12:37:00

Мне не известно о такой возможности. Весь трафик WireGuard должен выходить через туннель, включая DNS. Просто запустите два DNS-сервера на Raspberry Pi: один для WireGuard, другой для локальной сети. Единственное отличие в том, что WI_PI использует сторонний DNS-адрес для получения DNS (в отличие от 1.1.1.1 или другого адреса на стороне локальной сети).

dazzaling69

Guest

01.07.2024 13:54:00

Спасибо. Логика в этом предложении есть, но мне интересно, зачем моей сети нужны два PiHole. У меня всё работает так: через DHCP я раздаю DNS адрес роутера из диапазона LAN — 10.160.100.1 — и перенаправляю его на PiHole с адресом 172.17.0.2, который не в LAN. PiHole, в свою очередь, использует роутер (10.160.100.1) как вышестоящий DNS-сервер, а он уже обращается к 1.1.1.1. По сути, ты предлагаешь разрешить Wireguard подключаться к другому серверу PiHole, который работает в другом IP-диапазоне, не совпадающем с Wireguard. Но если я так уже делаю для LAN, почему нельзя просто направить трафик Wireguard также на 172.17.0.2? В обоих случаях я беру IP-диапазон и перенаправляю его на DNS-сервер в другом диапазоне. Не понимаю, зачем для этого нужен второй PiHole — или я что-то упускаю?

dazzaling69

Guest

#10

01.07.2024 15:10:00

Разве я не могу просто добавить ещё одно правило NAT, похожее на те, что у меня есть, где в интерфейсе источника будет Wireguard (вместо локального моста), чтобы перенаправить NAT-трафик? Или, как предлагалось раньше, использовать список входных интерфейсов?

anav Guest	#11 0 01.07.2024 15:44:00 Я не на 100% уверена, так что пробуйте другие варианты, а я пока подумаю над этим ещё.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры