Dns fallback openvpn что это
Перейти к содержимому

Dns fallback openvpn что это

  • автор:

Как защититься от DnsLeak на openvpn?

Как я понимаю, проблема в том, что openvpn не заворачивает в свой туннель dns запросы, которые могут ходить через своего провайдера как ни в чём ни бывало.

OpenVPN умеет запускать скрипты в момент установки соединения. Теоретически, можно попробовать написать скрипт который будет менять таблицу маршрутизации. И при завершении соединения воротать всё взад.
Однако.. а если соединение разорвётся само? Или хост выключится? Или просто гдето прав не хватит или ещё что.

Есть вменяемый метод?

Piter_prbg
12.02.16 18:30:16 MSK

Укажите днс сервер в конфиге сервера и будет счастье.

push "dhcp-option DNS ip-днс-сервера"

anc ★★★★★
( 12.02.16 19:24:45 MSK )

Однако.. а если соединение разорвётся само? Или хост выключится? Или просто гдето прав не хватит или ещё что.

Поднять на хосте свой DNS-сервер и вертеть там форварды как тебе вздумается

Pinkbyte ★★★★★
( 13.02.16 16:30:00 MSK )
Ответ на: комментарий от Pinkbyte 13.02.16 16:30:00 MSK

Поднять на хосте свой DNS-сервер и вертеть там форварды как тебе вздумается

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

Jameson ★★★★★
( 13.02.16 17:16:39 MSK )
Ответ на: комментарий от anc 12.02.16 19:24:45 MSK

anc, спасибо за ответ.
Эдак нужно несколько DNS серверов прописать, чтобы заменить все клиентские настройки по DNS серверам, я правильно понимаю?
push «dhcp-option DNS 8.8.8.8 8.8.8.4» или как?

Piter_prbg
( 14.02.16 01:06:16 MSK ) автор топика
Ответ на: комментарий от Jameson 13.02.16 17:16:39 MSK

Pinkbyte, Jameson,
ну что вы говорите, это же клиентский хост..

Piter_prbg
( 14.02.16 01:06:47 MSK ) автор топика
Ответ на: комментарий от Piter_prbg 14.02.16 01:06:47 MSK

ну что вы говорите, это же клиентский хост..

И что? Никаких религиозных запретов держать на хосте запущенным кеширующий bind с прописанными forward к разным DNS серверам для разных сетей нет, только неумение настоить. Я, например, люблю когда за разрешением интернет адресов bind напрямую к корневым серверам ходит, а forwardы на провайдерский и локальный DNS отвечают за внутрипрововские и локальные ресурсы. При поднятии тоннеля в разные локалки forward к DNS этой локалки добавляется к конфигурации bind автоматически. При поднятии vpn c default route bind делает свои запросы к корневым серверам через этот vpn, и ничего не течёт.

Соответственно у меня в resolv.conf всегда 127.0.0.1, всё остальное разруливает bind.

Jameson ★★★★★
( 14.02.16 14:39:54 MSK )
Ответ на: комментарий от Piter_prbg 14.02.16 01:06:47 MSK

ну что вы говорите, это же клиентский хост..

У меня на работе на рабочей станции стоит DNS-сервер — обслуживает только 127.0.0.1 и не является авторитетным ни для одной из зон — только форвардит запросы как мне надо на другие DNS-сервера.

Это единственный способ нормально заставить DNS работать например с парой VPN-ов, за которыми свои DNS-зоны.

Pinkbyte ★★★★★
( 14.02.16 16:50:06 MSK )
Ответ на: комментарий от Piter_prbg 14.02.16 01:06:47 MSK

Предлагаю перестать думать в категориях рабочих станций. Любой настольный Линукс от сервера отличается мелочами и настройками преимущественно. Мысли ширше, как сетевой админ. Например во времена сильно платного исчерпаемого трафика мне был актуален локальный Squid. Ибо кеши у браузеров есть конечно, но браузеров несколько, не считая тех что внутри виртуалок. А тут настроил их всех на локальный прокси и у всех браузеров можно собственный кеш в 0 выставлять.

Jameson ★★★★★
( 14.02.16 17:03:31 MSK )
Ответ на: комментарий от Pinkbyte 14.02.16 16:50:06 MSK

Это единственный способ нормально заставить DNS работать например с парой VPN-ов, за которыми свои DNS-зоны.

А это собственно и есть основной смысл использования VPN (virtual PRIVATE network). Сценарий, при котором туннель используется для смены точки выхода в интернет не основной, поэтому на нём косяки типа DNS leak и вылезают.

А вообще, правильный VPN провайдер должен снабдить тебя своим DNS, а правильный дистрибутив запихать его в resolv.conf. Если нет, правильный пользователь рабочей станции прописывает в настройках NetworkManager для этого соединения DNS 8.8.8.8 руками, после чего правильный дистрибутив запихивает это опять таки в resolv.conf. После опускания тоннеля всё должено возвращаться назад.

Jameson ★★★★★
( 14.02.16 17:11:42 MSK )
Последнее исправление: Jameson 14.02.16 17:12:56 MSK (всего исправлений: 1)

OpenVPN умеет DNSSec.

Iron_Bug ★★★★★
( 14.02.16 17:23:42 MSK )

А ещё мне вспомнился эпичный баг Networknanager https://bugs.archlinux.org/task/47535 , к счастью быстро пофикшенный. Суть в том, что vpn соединение устанавливалось, но default route не менялся, при этом никаких ошибок никуда кроме лога не писалось. В результате юзер пребывал в полной уверенности что он уже работает через vpn, но про факту продолжал светить трафик провайдеру. И формально нёс ответственность, так как софтина ему честно в лог сказала, «тоннель — смогла, маршрут — нет», но ктож эти логи читает? Тоннель взлетел? Взлетел. ЗначОк есть? Есть. Значит всё в поряде 🙂

Jameson ★★★★★
( 14.02.16 17:28:05 MSK )
Ответ на: комментарий от Piter_prbg 14.02.16 01:06:16 MSK

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

Не распарсил формулировку «чтобы заменить все клиентские настройки»

anc ★★★★★
( 15.02.16 03:13:33 MSK )
Ответ на: комментарий от Jameson 14.02.16 17:11:42 MSK

Господа, я рекомендуя вам вылезти чуть дальше своего сервера на локалхосте (в данном случае это про то что вы писали, а не намек на «админ локалхоста»). Случаев когда нужна именно раздача днс очень много и DNS leak не так уж и смешно как может показаться. А вот пользователям (именно пользователям) раздавать кроме ключей, паролей и т.д. еще и мануалы с инструкциями (под разные ОС) как настроить у себя днс сервер это все-таки перебор.

anc ★★★★★
( 15.02.16 03:24:11 MSK )
Ответ на: комментарий от anc 15.02.16 03:24:11 MSK

Уже написали же — запушить юзеру настройки DNS и всё, OpenVPN клиент сам всё пропишет, где надо.

Legioner ★★★★★
( 15.02.16 03:37:31 MSK )
Ответ на: комментарий от Legioner 15.02.16 03:37:31 MSK

Эммм. это вообще я был 🙂

anc ★★★★★
( 15.02.16 06:21:43 MSK )
Ответ на: комментарий от anc 15.02.16 03:24:11 MSK

Господа, видимо, не поняли сути проблемы ввиду моего не совсем ясного изложения.
Юзеры (то биш, виндовс десктопы) массово коннектятся к openvpn серверу. Я пытаюсь понять их защитить от DNSleak.

Piter_prbg
( 15.02.16 10:03:38 MSK ) автор топика
Ответ на: комментарий от anc 12.02.16 19:24:45 MSK

Чё-то я протормозил.
у меня и так стоит
push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»

и от утечки dns это не помогает.

Piter_prbg
( 15.02.16 10:21:32 MSK ) автор топика
Ответ на: комментарий от Piter_prbg 15.02.16 10:21:32 MSK

Хм, как определили? В конфиге клиента не запрещено случайно?

anc ★★★★★
( 15.02.16 12:51:06 MSK )
Ответ на: комментарий от anc 15.02.16 12:51:06 MSK

Не думаю, что на клиенте что-то запрещено.
вот конфиг клиента:

[br]client[br]dev tun[br]proto tcp[br]remote x.x.x.x 1194 #server's ip[br]nobind[br]persist-key[br]persist-tun[br]auth-user-pass[br]comp-lzo[br]reneg-sec 0[br]verb 3[br]

при соединении вижу:

[br]PUSH: Received control message: 'PUSH_REPLY,route 10.10.52.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.10.52.1,topology net30,ping 10,ping-restart 120,ifconfig 10.10.52.94 10.10.52.93'[br]

т.е. вроде как просасываются настройки.

Определили так
https://www.dnsleaktest.com/
Даже быстрый standard test запалил местонахождение.

Piter_prbg
( 15.02.16 18:05:18 MSK ) автор топика
Ответ на: комментарий от Piter_prbg 15.02.16 18:05:18 MSK

Походу винда новая, у меня старше семерки нигде нэма, там все работает норм. Вот что в инете есть http://habrahabr.ru/post/268173/
btw судя по нику, автор и здесь присутствует, ValdikSS Ваше творение?

anc ★★★★★
( 15.02.16 21:02:02 MSK )
Ответ на: комментарий от anc 15.02.16 21:02:02 MSK

Не понял вопрос(реплику?) про ник, но на всякий случай скажу, что на хабре не зареген, и на этом форуме у меня только один ник.

На винде пока не проверял, проверю вечером, напишу.
Ситуация такая: настраиваю openvpn-сервер на дебиане, хочу обезопаситься от dns leak.
Клиенты предполагается что будут на всех осях и девайсах.
Сам сижу на линукс минте, на нём проверяю.

Piter_prbg
( 15.02.16 21:51:34 MSK ) автор топика
Ответ на: комментарий от Piter_prbg 15.02.16 10:21:32 MSK

Так может тебе надо пушить внутренний ip впн сервера, а не гугла?
Тебе об этом в первом же комментарии написали.

xtraeft ★★☆☆
( 15.02.16 22:19:40 MSK )
Ответ на: комментарий от Piter_prbg 15.02.16 21:51:34 MSK

Не понял вопрос(реплику?) про ник, но на всякий случай скажу, что на хабре не зареген, и на этом форуме у меня только один ник.

Я написал что ValdikSS есть и здесь на лоре и предполагаю что судя по нику это один и тот же человек.

Клиенты предполагается что будут на всех осях и девайсах.

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

anc ★★★★★
( 15.02.16 22:39:32 MSK )
Последнее исправление: anc 15.02.16 22:41:58 MSK (всего исправлений: 1)

Ответ на: комментарий от anc 15.02.16 21:02:02 MSK

Piter_prbg , для начала определитесь, так ли важно для вас защищаться от DNS Leak. На Linux getaddrinfo будет пытаться резолвить хостнейм через следующий (не первый) nameserver только в том случае, если первый не ответил по таймауту. Т.е., в обычном случае, такое случается довольно редко (проблемы с сетью), но, конечно, если сеть контролируется злоумышленником (Wi-Fi хакера, к которой вы подключились), то он сможет произвольно устраивать вам DNS Leak (правда, для вас это будет выглядеть, как тормоза сети).

В Windows до 8 примерно такая же ситуация. Начиная с 8.1, Windows отправляет запросы на все ей известные DNS параллельно, байндясь к интерфейсу. Вот это уже плохо. Для устранения такого поведения можно использовать параметр

--block-outside-dns Block DNS servers on other network adapters to prevent DNS leaks. This option prevents any application from accessing TCP or UDP port 53 except one inside the tunnel. It uses Windows Filtering Platform (WFP) and works on Windows Vista or later.

Правда, эта опция будет вызывать отказ в подключении на Windows Vista. Будет исправлено в OpenVPN 2.3.11 (надеюсь). Либо же плагин, который делает то же самое: https://github.com/ValdikSS/openvpn-fix-dns-leak-plugin (тут и Vista уже работает).

Про OS X ничего не могу сказать. На Android DNS Leak нет.

OpenVPN в Linux сам по себе не умеет устанавливать DNS. Если вы запускаете его из консоли, используйте up-скрипт update-resolv-conf (в Debian находится в /etc/openvpn/update-resolv-conf). NetworkManager умеет устанавливать DNS, но, насколько мне известно, в Ubuntu все еще имеется баг из-за использования dnsmasq, он там как-то странно устанавливается. Я рекомендую закомментировать строку:

dns=dnsmasq

в файле /etc/NetworkManager/NetworkManager.conf и перезапустить NetworkManager:

sudo service network-manager restart

ValdikSS ★★★★★
( 15.02.16 23:16:39 MSK )
Последнее исправление: ValdikSS 15.02.16 23:22:32 MSK (всего исправлений: 2)

OpenVPN(VPN) и DNS — шифруется или нет?

Какие «дыры» или потенциальные опастности имеет OpenVPN? Случайно натыкаюсь на https://events.yandex.ru/lib/talks/2326/ — 1:06:46 там вопрос про OpenVPN(VPN) и ответ на 1-2 минуты. Не очень понял, поясните кто знает . Как понял я — что если мы настраиваем OpenVPN как шлюз в интернет, то все идет через ДНС провайдера и не шифруется верно? А вот, если я настраиваю OpenVPN без выхода в сеть, для доступа к внутренним ресурсам, доступных только внутри ВПН сети, то тоже получается, что не шифрованный трафик пойдет через ДНС провайдера? Раньше не задумывался, а тут, чтот задумался или еще хуже запутался) Разъясниете пожалуйста или где почтать можно про это?

Отслеживать

13.7k 12 12 золотых знаков 43 43 серебряных знака 75 75 бронзовых знаков

Не работает разрешение имен DNS при VPN подключении в Windows

date

19.12.2023

user

itpro

directory

Windows 10, Windows 11, Windows Server 2019

comments

комментариев 18

По умолчанию для всех VPN подключений в Windows используется режим Force Tunnel (в настройках VPN включена опция ‘ Use default gateway on remote network ‘/’ Использовать основной шлюз в удаленной сети ‘). В этом режиме для разрешения имен будут использоваться DNS сервера, которые назначены вашему подключению сервером VPN, и вы не сможете разрешать имена устройств в вашей локальной сети.

Для VPN подключения в Windows доступно два режима:

    Force Tunnel ( включена опция Use default gateway ) — весь трафик, в том числе DNS, отправляется в VPN туннель. В таком режиме после подключения к VPN вы теряете возможность резолвить DNS имена хостов в вашей локальной сети (после подключения к VPN вы также теряете доступ в Интернет через свою LAN). Доступ будет работать только по IP адресам (частично в этом случае спасает кэш DNS клиента);

В Google я нашел рекомендации по отключению IPv6 на локальном (LAN) подключении и это работает (если вы хотите использовать Force-Tunnel).

Windows 10/11 отправляет DNS запросы с сетевого интерфейса с наивысшим приоритетом (у которого самое маленькое значение метрики интерфейса). Чтобы вывести значения метрик сетевых интерфейсов компьютера, выполните PowerShell команду:

Get-NetIPInterface | Sort-Object Interfacemetric

Get-NetIPInterface

На данном компьютере есть два подключение:

Это значит, что ваши DNS запросы отправляются через интерфейс с меньшей метрикой (Ethernet) на ваши локальные DNS сервера, а не на DNS сервера VPN подключения. В такой конфигурации вы не можете резолвить адреса во внешней VPN сети.

Windows 10/11 задают метрики IPv4 сетевым интерфейсам автоматически в зависимости от их скорости и типа:

Скорость и тип подключения Метрика
Ethernet 1 Гб 25
Ethernet 100 Мб 35
Wi-Fi интерфейс со скоростью 50-80 Мб 50

Например, вы хотите, чтобы DNS запросы отправлялись через VPN подключение. В нашем примере это означает, что нужно увеличить метрику локального Ethernet адаптера и сделать его больше 100.

Вы можете изменить метрики сетевых интерфейсов из графического интерфейса или из командной строки.

установить метрику LAN интерфейса вручную в Windows 10

  • Откройте панель управления сетевыми подключениями ( ncpa.cpl ), откройте свойства вашего Ethernet подключения, выберите свойства протокола TCP/IPv4, перейдите на вкладку “Дополнительные параметры TCP/IP”. Снимите галку “Автоматическое назначение метрики” и измените метрику интерфейса на 120.
  • Также вы можете изменить метрику с помощью команд PowerShell для управления сетевыми настройками (используйте индекс вашего LAN интерфейса, полученный с помощью командлета Get-NetIPInterface ):
    Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 120
    Или netsh (нужно указать имя вашего LAN подключения)
    netsh int ip set interface interface=»Ethernet 3″ metric=120

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

метрика для VPN подключения

В такой конфигурации DNS запросы будут выполняться через VPN подключение.

Также вы можете изменить настройки вашего VPN подключения, изменив режим на SplitTunneling (трафик DNS по умочалнию идет в вашу LAN) и указать DNS суффикс для подключения c помощью PowerShell:

Get-VpnConnection
Set-VpnConnection -Name «VPN» -SplitTunneling $True
Set-VpnConnection -Name «VPN» -DnsSuffix yourdomain.com

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

Также можете указать трафик каких подсетей нужно всегда отправлять в VPN туннель:

Add-VpnConnectionRoute -ConnectionName $VpnName -DestinationPrefix 172.16.10.0/24

Add-VpnConnectionRoute -ConnectionName $VpnName -DestinationPrefix 10.24.2.0/24
См статью об автоматическом добавлении статических VPN маршрутов в Windows.

Если вы используете OpenVPN сервер, вы можете назначить клиентам дополнительные маршруты и DNS сервера с помощью опций:

push "route 10.24.1.0 255.255.255.0" push "dhcp-option DNS 192.168.100.11"

В версиях с Windows 8.1 до Windows 1703 по умолчанию включена опция Smart Multi-Homed Name Resolution (SMHNR). При активной SMHNR Windows отправляет DNS запросы на все известные системе DNS сервера параллельно и использует тот ответ, который пришел быстрее. Это не безопасно, т.к. потенциально внешние DNS сервера (которые указаны в вашем VPN подключении) могут видеть ваши DNS запросы (утечка ваших DNS запросов вовне). Чтобы предотвратить утечку DNS запросов, желательно отключить SMHNR с помощью групповой политики:

Turn off smart multi-homed name resolution политика DNS клиента

Set-ItemProperty -Path «HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient» -Name DisableSmartNameResolution -Value 1 -Type DWord
Set-ItemProperty -Path «HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters» -Name DisableParallelAandAAAA -Value 1 -Type DWord

Несколько полезных статей об использовании VPN в Windows:

  • Запустить VPN подключение до входа в Windows.
  • Автоматически переподключиться к VPN при разрыве соединения

Предыдущая статьяПредыдущая статья Следующая статья Следующая статья

Возвращаем 2007 год, или делаем Интернет без блокировок

Как известно, в 2007 году кроме того, что деревья были выше, а трава зеленей, еще и в Интернете не было особых ограничений — можно было открыть почти любой сайт и наслаждаться им. До ковровых блокировок Telegram оставалось ещё 10 лет. К сожалению, в наше время такой возможности уже нет. Причины тут всем известны, в частности, некоторые компании уже не предоставляют своих услуг в России.

Хорошо, что существует возможность в рамках домашней сети восстановить свободный Интернет таким, каким он был в 2007-м. Именно этим мы и займемся. Стоит отметить, что в 2007 году довольно часто можно было встретить подключения на скорости 64-128 Кб/с, а то и вовсе dial-up; Wi-Fi был редкостью, а мобильная связь — довольно дорогим удовольствием. Однако, эти особенности того времени мы постараемся не воспроизводить.

Представляю вашему вниманию Freeroute — простой маршрутизатор, который позволяет направлять трафик на разные шлюзы в зависимости от домена назначения. Free в названии, как водится, означает свободный, а не бесплатный.

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

Откуда идея

Помню, как я сделал себе первый VPN-сервер. Это было как раз во времена блокировок Telegram. Тогда я поехал в незнакомый для меня город, а Яндекс карты и Google Maps отказались работать — я не мог найти нужный мне адрес. В тот же вечер я сделал себе VPN-сервер, чтобы такое больше не повторялось.

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

Я думаю, что каждый человек вправе сам решать, какую информацию ему читать, а какую нет. У меня появилась идея создать такой маршрутизатор, который будет автоматически перенаправлять трафик для заблокированных сайтов через VPN, а для остальных — напрямую. Но довольно долго я просто размышлял о такой возможности.

Последней каплей стало то, что перестал работать GitHub Copilot — и мне пришлось постоянно сидеть с VPN. Поэтому я решил, что настало время воплотить мою идею в жизнь.

Как это работает

Я создал Freeroute. Это простой сервис на Python с небольшой админкой на React. Github проекта.

Freeroute устанавливается на отдельную машину с Linux в домашней сети (подойдёт также виртуальная машина в режиме моста). Адрес этой машины устанавливается на клиентах или на DHCP-сервере в качестве шлюза по умолчанию и DNS сервера. Freeroute резолвит DNS-запросы клиентов, получает IP-адреса запрашиваемых доменов и перенаправляет трафик на соответствующие IP-адреса через нужный шлюз согласно спискам доменов. Перенаправление трафика реализовано с помощью команды ip route add .

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

Также по умолчанию Freeroute раз в час будет скачивать списки заблокированных сайтов с https://antifilter.download/, спасибо коллегам за их замечательный сервис.

Возникает вопрос, почему не используется список IP-адресов заблокированных ресурсов с того же сайта? Для этого сразу несколько причин. Во-первых, этот список не решает проблему с Copilot и другими сервисами, которые не работают в России по собственному желанию. Во-вторых, данный список не совсем точный, например, в нем есть некоторые адреса youtube, что приводит к тому, что youtube берет местоположение VPN. В-третьих, списки IP-адресов сложнее редактировать, чем списки доменов, ну и IP-адреса, бывает, меняются. Ещё такой подход помогает бороться с замедлениями трафика, это полезно, например, для Twitter, который не заблокирован полностью, а поэтому его нет в списках заблокированных доменов, но он замедлен до той степени, что им невозможно пользоваться.

То же самое можно было бы сделать с помощью связки dnsmasq + nftables. Но такое решение имеет фатальный недостаток (если вы понимаете, о чём я), да и редактировать списки доменов там не так удобно. Пришлось бы что-то придумывать с автоматическим обновлением списков antifilter.

Установка и настройка

В каталоге с релизом есть скрипт install.sh , который установит Freeroute и настроит его. Этот же скрипт установит и настроит OpenVPN клиент.

Предполагается, что Freeroute будет развернут на чистой Debian 11 или 12. В итоге сервис будет работать от имени непривилегированного пользователя, а перенаправление трафика будет происходить с помощью команды sudo ip route . DNS-сервер будет работать на порту 5553, поэтому скрипт также настроит nftables, чтобы трафик с 53 порта перенаправлялся на 5553.

Запускается Freeroute от имени обычного пользователя с sudo-правами.

Для установки Freeroute, выполните следующие шаги:

  1. Скачайте последний релиз отсюда
  2. Распакуйте архив tar -xzf freeroute.tar.gz
  3. Запустите скрипт установки:
sudo ./install.sh  -- или -- sudo ./install.sh  -u -p
  • это основной сетевой интерфейс машины (например, eth0), через который она подключена к интернету;
  • это конфигурационный файл OpenVPN;
  • и это имя пользователя и пароль для VPN. Это опционально и заполняется, только если VPN требует аутентификации.

Настройка клиентов

В настройках DHCP домашнего роутера укажите адрес Freeroute в качестве шлюза по умолчанию и DNS сервера. Например, для своего Keenetic я сделал такие настройки:

Настройки DHCP

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

Файл конфигурации

В файле config.yaml находится конфигурация Freeroute. В нём можно настроить следующие параметры:

  • списки VPN подключений (по умолчанию будет одно, которое было задано при установке), но может быть полезно, если нужно подключаться к разным VPN, например, перенаправить трафик Steam через Казахстанский VPN;
  • списки доменов, которые нужно перенаправлять через VPN;
  • автообновление списков доменов и периодичность их загрузки;
  • на каком порту будет работать DNS-сервер;
  • на каком порту будет работать админка;
  • уровни логирования.

Списки доменов сохраняются в каталоге вместе с конфигом, и имеют имя вида list_.txt .

Ручные списки доменов применяются в том порядке, в котором они указаны в конфиге, затем применяются списки, загружаемые автоматически.

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

Админка

Админка доступна по адресу http://:8080/index.html . Здесь можно настроить списки доменов, а также посмотреть логи — какой адрес разрезолвился в какие IP-адреса и в какой шлюз трафик был направлен. Внешний вид админки представлен на скриншоте:

Внешний вид админки

Дальнейшие планы

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

Вот список того, что можно ещё сделать:

  • сделать контейнер Docker;
  • сделать админку более красивой и удобной;
  • написать тесты;
  • переписать сервис на C, чтобы проект можно было запускать прямо на слабых роутерах (возможна интеграция с https://github.com/karen07/antiblock);
  • улучшить работу DNS сервера, сейчас он резолвит только записи A и CNAME;
  • добавить поддержку IPv6;
  • добавить возможность подключаться к вышестоящему DNS серверу через DoH или DoT (сейчас это можно сделать на роутере).
  • Информационная безопасность
  • Сетевые технологии
  • Софт
  • Социальные сети и сообщества
Похожие публикации:
  1. Как добавить данные в таблицу sql
  2. Как посчитать цифры исходя из среднего значения
  3. Как сменить аккаунт на айфоне
  4. Что такое префикс и суффикс в программировании

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *