Openwrt роутер настройка vpn
Обновлено: 06.07.2024
Недавно у меня появилась необходимость обеспечить доступ в интернет всех пользователей домашней сети через OpenVPN. Изначально для этих целей использовался древний IBM NetVista 6646-Q1G c Linux Centos 6 на борту.
Справлялся он с данной задачей хорошо, но, как говорится, нет предела совершенству. Захотелось заменить его на что-либо более компактное. Изначально выбор пал на Raspberry Pi Model B, но смущала цена в 50$, ведь с задачей, которую он должен был выполнять, успешно справлялся и текущий сервер. Я приступил к изучению альтернативных вариантов. И нашел, как мне показалось, идеальное решение – роутер + прошивка DD-WRT, которая содержит клиент OpenVPN. Далее настал черед выбора роутера. Я остановился на TP-Link WR841N. Поиск по базе показал, что DD-WRT его поддерживает.
Буквально в тот же день девайс был приобретен и прошит. Но тут меня ждало разочарование – в веб интерфейсе на вкладке VPN отсутствовала возможность настройки клиента OpenVPN. Найти причину данной несправедливости помог google очень быстро: “OpenVPN is only available on units with at least 8mb flash (except the Broadcom VPN build.)”.
Как говорят мудрейшие, внимательно читайте договор документацию.
Ладно, так даже интереснее. Беглый поиск альтернативных прошивок привел меня к OpenWRT. Ее отличие от DD-WRT в том, что в ней есть менеджер пакетов opkg с неплохим репозиторием и имеется возможность гибко настроить систему под свои нужды. Фактически, это очень сильно облегченная версия linux.
В OpenWRT настроить OpenVPN из коробки не получилось – проблема та же, что и с DD-WRT. Но, благодаря архитектуре данной прошивки, надежда, что все получится, была. Довольно много свободного места было обнаружено в tmpfs:
Как понятно из названия, в /tmp монтируется оперативная память роутера. Несколько минут гугления привели меня на страницу с вариантом решения данного вопроса.
К сожалению, мне он не подошел, так как после установки пакетов kmod-tun, liblzo и libopenssl в корневой файловой системе осталось критически мало места. Поэтому было принято решение немного модернизировать этот мануал. Вот что у меня получилось.
1. Подключаемся к роутеру по ssh и выполняем команды:
2. Редактируем init скрипт:
3. Копируем в папку /etc/openvpn файл конфигурации (в нашем случае my.conf), сертификаты и ключ.
4. Запускаем openvpn:
Если все прошло успешно, то при выполнении команды ifconfig увидим новый tun или tap интерфейс. Пример:
Если соединение не установилось, можно попробовать найти ошибку с помощью команды:
Далее необходимо добавить сетевой интерфейс и настроить фаервол для того, чтобы пустить трафик клиентов через VPN. Это можно выполнить с помощью веб интерфейса. Примеры на скриншотах ниже:
Данное решение успешно протестировано работает на роутере TP-Link WR841N, так же оно подойдет для других поддерживаемых OpenWRT устройств, имеющих ROM 4 мегабайта.
Данная статья является руководством для начинающих по установке OpenVPN соединения на OpenWrt. Основная цель данного документа - получить рабочий OpenVPN туннель и установить базовую платформу для дальнейшей настройки.
Ссылки на страницы дальнейшей конфигурации можно найти Other Considerations разделе этого руководства.
Сценарий использования (начальная настройка)
Пользователь хочет безопасно соединиться с OpenWrt маршрутизатором. На данный момент пользователь уже может получить доступ к OpenWrt маршрутизатору, но через внешнюю сеть, такую как Интернет. Конечным результатом станет прямое частное соединение между OpenVPN клиентом и сервером. В основном это будет выглядеть так, будто OpenVPN клиент находится в подсети маршрутизатора(но не в той подсети, которая является для маршрутизатора внешней).
Это руководство описывает 3 файла конфигурации для OpenVPN:
Стандартный (TUN) Сервер: Простейший вид OpenVPN сервера, Клиенты управляются исключительно OpenVPN, им также может быть выделена отдельная подсеть. Сервер в режиме моста (TAP) : Также может называться “ethernet-bridge”. Эта конфигурация создаст виртуальный ethernet кабель между сервером и клиентом. Это означает что OpenVPN клиенты будут такими же участниками подсети, как и те которые подключены к маршрутизатору физически. IP -адреса им будет раздавать DHCP -сервер. Клиент: OpenVPN будет работать в режиме клиента и соединится с OpenVPN сервером.Следует отметить, что TAP это не синоним сетевого моста, тем не менее TAP адаптер нужен для сетевого моста, в то же время рекомендуется использовать TUN, если не нужен сетевой мост. Для простоты мы будем использовать эти термины как взаимозаменяемые, так как сравнение терминов “сервер” и “сервер-мост” может привести к путанице. TUN будет использоваться для обозначения традиционного сервера, в то время как TAP будет относиться к “серверу-мосту”.
Можно настраивать OpenVPN на OpenWrt удалённо. Однако рекомендуется делать это локально, так как это упростит поиск и устранение неисправностей.
TUN сервер расходует меньше ресурсов и только отсылает трафик, предназначенный только для клиента. В то время, как TAP сервер менее эффективный и отсылает клиентам широковещательный трафик.
Для TUN сервера легче настроить безопасность, так как его клиенты могут находиться в отдельной подсети, которая может легко контролироваться межсетевым экраном. Благодаря тому, что клиентам в данном режиме не отсылается широковещательная информация, злоумышленник не сможет получить доступ к большому объёму данных.
Сервер TAP объединяет клиентов в сеть более бесшовной образом, это может упростить процесс настройки различных сетевых приложений. Обратите внимание на то, что независимо от выбранного метода, создание правил межсетевого экрана имеет более важное значение безопасности, чем выбор между TUN и TAP сервером.
При использовании TAP сервера рекомендуется изменить маску подсети на отличную от 192.168.0.XXX или 192.168.1.XXX. Они очень распространены и приведут к конфликтам в маршрутизации. Это обычно может быть достигнуто путём изменения IP -адреса OpenWrt/OpenVPN маршрутизатора к чему-то наподобие 192.168.7.1
Системные требования
Для работы по данному руководству нужен OpenVPN сервер на OpenWrt маршрутизаторе с запущенным OpenWrt 15.05 Chaos Calmer.
Установка необходимого ПО
Создание сертификатов
Если вы создаёте OpenVPN сервер (любого типа), вы должны создать сертификаты безопасности по нижеприведённым инструкциям. Если вы используете OpenVPN как клиент, требуемые сертификаты должны были быть предоставлены вам с вашими конфигурационными данными.
Вышеприведённые команды создадут сертификат сервера с именем my-server и сертификат клиента с именем my-client.
Путь сохранения сертификатов и ключей по умолчанию /root/pki.
Вы можете создать несколько клиентских сертификатов, запустив easyrsa build-client-full несколько раз и указав разные имена.
Вы можете создать новый набор сертификатов, запустив clean-all и те же команды снова.
Распределение сертификатов
Скопируйте ключи сервера в папку /etc/openvpn/.
Настройка сети на OpenWrt маршрутизаторе
Традиционный (TUN) Сервер
Разрешите входящие подключения клиентов открыв порт на сервере (по умолчанию 1194) в вашем межсетевом экране: Создайте зону межсетевого экрана (с именем vpn) для новой vpn0 сети. Это разрешит входящие и исходящие соединения, необходимые для VPN туннеля. Измените значение по умолчанию в соответствии с требованиями. Это (пока) не разрешит получить доступ к LAN или WAN сетям, но разрешит клиентам взаимодействовать с сервисами на маршрутизаторе и может разрешить соединения VPN клиентам, если это позволяет конфигурация вашего OpenVPN сервера: (Необязательно) Если вы планируете разрешить клиентам подключаться к компьютерам в вашей локальной сети, вам необходимо разрешить перенаправление трафика VPN и LAN зонами межсетевого экрана: (Необязательно) Точно так же, если вы хотите, чтобы ваши VPN клиенты имели доступ к интернету (WAN ) через туннель, вы должны разрешить перенаправление трафика межу VPN и WAN зонами межсетевого экрана:Сервер в режиме моста(TAP)
Разрешите входящие клиентские соединения, для этого откройте порт на сервере (по умолчанию 1194) в вашем межсетевом экране:Клиент
Создайте зону межсетевого экрана (с именем vpn) для новой vpn0 сети. Это разрешит входящие и исходящие соединения, необходимые для VPN туннеля. Отредактируйте эти настройки по своему усмотрению. Это (пока) не разрешит получить доступ к LAN или WAN сетям, но разрешит клиентам взаимодействовать с сервисами на маршрутизаторе и может разрешить соединения VPN клиентам, если это позволяет конфигурация вашего OpenVPN сервера Если вы планируете использовать OpenVPN как второй сетевой адаптер (или замену) WAN адаптеру, рекомендуется отклонять остальной сетевой трафик(см. комментарий в коде): (Необязательно) Если вы планируете разрешить общаться пользователям за вашим LAN с клиентами за VPN сервером, вам необходимо внести соответствующее правило(для входящих данных):(для исходящих данных)
Конфигурация OpenVPN
OpenVPN может быть настроен как с помощью интерфейса UCI(характерного для OpenWrt), так и с помощью традиционных конфигурационных файлов OpenVPN (*.conf). OpenVPN будет автоматически подгружать все *.conf файлы из /etc/openvpn/.
Пользователи, знакомые с OpenVPN, вероятно, предпочитают использовать файлы конфигурации, и этот выбор, вероятно, будет более простым и удобным для тех кто планирует запускать несколько экземпляров OpenVPN.
Для простоты и последовательности, остальная часть этого руководства будет использовать интерфейс OpenWRT UCI для настройки OpenVPN, как описано ниже. Следует отметить, что раздел Routing Traffic section содержит инструкции для UCI интерфейса (Пользователям, использующим традиционные файлы конфигурации, придется подкорректировать эти команды под свою систему).
Традиционный (TUN) Сервер
Сервер в режиме моста (TAP)
Клиент
Конфигурация клиента очень сильно зависит от настроек сервера. Вам необходимо откорректировать их в соответствии с данными сервера, к которому вы подключаетесь.
Если ваш сервер требует проверки подлинности пароля:
Файл password.txt должен содержать в себе логин на первой строке и пароль на второй. Этот файл следует хранить в безопасном месте.
Вы можете также использовать опцию route.nopull. Это отключит автоматическую маршрутизацию. Имейте ввиду, что вам придётся самостоятельно прописывать все маршруты, к тому же сервер по-прежнему будет сам определять свойства TCP /IP для вашего TUN/TAP устройства:
На этом вы закончили базовую настройку. Запустите OpenVPN:
Настройка клиентов на сервер
Создайте клиентский конфигурационный файл OpenVPN, сохраните его с .ovpn расширением для Windows или .conf для *nix систем и отошлите его вашему клиенту:
Традиционный (TUN) Клиент
Клиент в режиме моста (TAP)
Проверка туннеля
Поздравляем! Теперь ваш OpenVPN сервер или клиент должен быть в рабочем состоянии. Однако возможно, что сервер до сих пор не может отправлять трафик клиентам, так как всё ещё не настроена маршрутизация. Перед настройкой маршрутизации вы должны убедиться, что клиенты могут связаться с сервером.
Проверьте соединение в соответствии с инструкциями вашей ОС.
На OpenWrt это можно сделать с помощью команды traceroute.
Традиционный (TUN) Сервер
Проверьте соединение, введя команду:
Тем не менее соединение с интернетом не будет идти через OpenWrt сервер без соответствующих маршрутов
После проверки работоспособности соединения вам нужно настроить встраивание маршрутов клиентам.
Server-Bridge (TAP) Server
Если вам требуется только доступ к интрасети и не требуется направлять обычный интернет-трафик (WAN ) через VPN , ваша конфигурация завершена!
Client
Unless the OpenVPN option route-nopull was specified by the client, routes pushed by the server should be in place. If route-nopull was used, only the server will be accessible. Using traceroute on any address with a route pushed by the server should result in that traffic being sent through the VPN , while other addresses should be sent through the default gateway.
The OpenVPN gateway can generally be found on *nix systems using:
And you can then test it using:
If you are not using route-nopull, then your configuration should now be complete!
Routing Traffic
If you are running a client instead of a server, then the server you connected to should have pushed the appropriate routes to you already. Advanced users may wish to alter this behavior.
Traditional (TUN) Server
Server-Bridge (TAP) Server
Client
Корректные маршруты должны автоматически предоставляться сервером без дополнительной настройки. Однако, в зависимости от потребностей, продвинутый пользователь может изменить маршруты самстоятельно. Это можно сделать опцией клиента route-nopull, которая заставляет игнорировать маршруты указанные сервером. После поднятия VPN -канала пользователь может добавлять свои собственные маршруты вручную или скриптом. Это можно сделать с использованием приведенного ниже примера:
Обратите внимание, что использование опции route-nopull приведет к появлению ошибок в журнале OpenVPN, после того, как он отклонит перенаправленные маршруты сервера. Это нормально.
Маршрутизация из сети сервера в сеть клиента
Тем не менее разработчики технологии OpenVPN предусмотрели возможность такого взаимодействия, однако, на момент написания этой части статьи (июнь 2018) возможность настроек этих опций в интерфейсе Luci или в командной строке uci разработчиками OpenWRT не была реализована. Тем не менее этот механизм доступен для использования через подключения конфигурационного файла OpenVPN. На примере сервера TUN делается это следующим образом -
Через команды uci создается VPN -соединение
Файл /etc/easy-rsa/vpn.cfg/server.ovpn создается как стандартный конфигурационный файл OpenVPN, содержащий те же самые настройки, что и описаны в настоящей статье. Например:
Где строка push route 192.168.10.0 255.255.255.0 указывает на адрес сети сервера, а строка route 192.168.20.0 255.255.255.0 - маршрут к сети клиента
Основное назначение этого файла — обеспечение возможности использования опции client-config-dir и ccd-exclusive, которые на момент написания настоящей статьи (июнь 2018) не была реализована в интерфейсе uci . В опции client-config-dir сохраняется путь к каталогу содержащему индивидуальные конфигурационные файлы для маршрутизации к каждой из сетей клиентов. Имя файла должно совпадать с именем сертификата (Внимание! не путать с именем файла сертификата) В каждом файле прописывается правило маршрутизации для сервера OpenVPN пример конфигурационного файла (обычно) содержит две строки
iroute — адрес сети клиента к которому осуществляется маршрутизация из сети сервера
ifconfig-push — указание клиентскому маршрутизатору на адрес шлюза
Подробности можно найти в описании этих стандартных опций в документации на OpenVPN
Клиентские файлы читаются сервером при создании нового vpn-соединения
После указанных действий сеть клиента должна пинговаться из сети сервера.
Other Considerations
Troubleshooting
You can try temporarily disabling the firewall on the OpenVPN server: You can clear the OpenVPN configuration and start again from scratch:Asking for help
When asking for help, you should at a minimum include the contents of the following files:
- Last modified: 2021/07/24 01:45
- by someothertime
Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.
Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International
Содержание рабочего файла options.pptp ниже:
6. Статус подключенного соединения
7. В заключение настройте маршруты устройства таким образом, чтобы маршрут к сети 172.16.0.0/16 вел во вновь созданный интерфейс pptp. Более подробно понять использование маршрутов можно на этом примере.
Особенность 1
Для использования соединения с шифрованием вам необходимо в настройках соединения:
- использовать авторизацию MS-CHAPv2 и указать что будет использоваться шифрование (MPPE)
Для соединения без шифрования вам необходимо:
- использовать авторизацию CHAP и указать, что шифрование использоваться не будет .
Будьте внимательны,
все иные сочетания методов авторизации и шифрования будут приводить к неработоспособности подключения.
Особенность 2
Работа протокола PPTP осуществляется с использованием протокола GRE, с которым у некоторых интернет провайдеров России имеются технические сложности. Эти сложности не позволят вам использовать PPTP для построения VPN туннлей. К таким провайдерам относятся МГТС (Московская городская телефонная сеть), Yota, Мегафон. Однако, такая ситуация не во всех частях их сетей.
Для пользователя ситуация будет выглядеть так, что проверка имени пользователя и пароля проходить не будут. Точнее до этого момента даже не дойдет. В пункте меню "События безопасности" вы будете видеть начало успешного подключения и последней будет являться фраза, говорящая о том, что мы готовы проверять имя и пароль, но .
Access granted. No whitelist is set for user. Ready to check username / password.
Отсуствие соединения и дальнейших записей в логе (при том, что вы твердо уверены в том, что логин и пароль верные), скорее всего, говорит о том, что GRE у вашего провайдера не пропускается. Можете погуглить на этот счет.
На данный момент случайно заблокированных сайтов уже стало сильно меньше, чем пару лет назад, но мне так понравилось не думать об этих блокировках вообще, что я и дальше буду их обходить. Пожалуй, всегда. Не питаю никакого оптимизма по поводу людей, которые управляют этим рубильником, и не хочу зависеть от их спонтанных капризов.
Так как большая часть моего трафика всё-таки ходит к незаблокированной части интернета, то логично пускать через VPN лишь тот трафик, который в этом нуждается. Ну нет ведь смысла гонять через VPN просмотр видео на YouTube или какую-нибудь игру? В итоге получится просто более медленный доступ, а профита никакого.
Стоит отметить, что если вам нужен обход блокировок только на одном устройстве, там вам намного проще будет настроить VPN именно на нём. У многих провайдеров VPN есть программы-клиенты, которые в несколько кликов по красивым кнопкам настроят вам всё, что нужно — просто погуглите, сравните цены и условия. Ещё можете посмотреть в сторону таких бесплатных проектов, как АнтиЗапрет.
Опишу свой процесс настройки роутера на OpenWRT с точечным обходом блокировок. Мне уже приходилось делать это пару раз (то переезд со сменой провайдера, то смена роутера), и вот на третий раз я решил наконец задокументировать этот процесс, чтобы в следующие разы было легче. Может и ещё кому пригодится.
Роутер и прошивка
OpenWRT — это опенсорсный проект, который разрабатывает прошивки для роутеров на основе Linux. В той или иной мере, пожалуй, поддерживаются все существующие девайсы. Внутри есть даже свой собственный пакетный менеджер. Так как роутер с OpenWRT — это почти настоящая линукс-машина, то открывается огромное поле для различных извращений — файловые шары, торрент-клиенты, блокировка рекламы на уровне роутера, VPN — да что угодно.
Мой нынешний роутер — это Xiaomi Mi WiFi Router 3G. Выбрал его, потому что в нём достаточно мощи, чтобы на нём хорошо работала OpenWRT. Да и вообще, Mir3G — это, похоже, один из самых популярных девайсов в тусовке людей, которые занимаются дрессировкой роутеров, так что в сети по нему уже есть много мануалов и обсуждений на форумах. Если захотите купить такой же, то будьте аккуратны с конкретной моделью — их две под одним названием, а хорошая только та, у которой есть порт USB3. Такой роутер должно быть несложно купить на Авито или других досках объявлений.
У меня на данный момент установлена почти последняя версия прошивки:
Прошивка OpenWRT и базовая настройка роутера выходит за рамки этой статьи. Поищите мануалы для вашего роутера. Далее предполагается, что у вас уже есть роутер с OpenWRT, подключенный к интернету, и к нему настроен доступ по SSH.
Блокировки
Грубо говоря, существует два типа блокировок:
Нам нужно победить оба. Разберёмся с каждым из них по порядку.
Шаг 1. Шифрованный DNS
DNS (Domain Name System) — это распределенная система (нет, это не сеть магазинов), состоящая из множества серверов по всему миру, которая позволяет вашему компьютеру преобразовать человекочитаемое имя сайта в машиночитаемый IP-адрес, например, из github.com получить 140.82.121.3 . Этот процесс называется "разрешением" или "резолвингом" доменного имени.
Блокировка по доменным именам зачастую реализуется провайдером следующим образом: ваш роутер по умолчанию использует DNS-сервер, который контролируется провайдером и для заблокированных доменных имён возвращает специальный адрес сайта-заглушки. Именно это происходит, когда вы видите в браузере "доступ к ресурсу ограничен в соответствии со 149-ФЗ".
Кажется, что решение очевидно — просто не пользоваться DNS-сервером провайдера, а использовать, например, Google DNS, IP-адреса которого уже стоит знать наизусть как считалку — 8.8.8.8, 8.8.4.4 . Раньше это действительно работало, но сегодня провайдеры уже не дадут вам так просто себя обмануть.
Поскольку DNS — это очень старый протокол, в котором никак не было предусмотрено шифрование от слова "вообще", у провайдеров есть возможность перехватывать ваши запросы и подменять ответы, вставляя свой сайт-заглушку, даже если запрос шёл, например, к Google DNS. Именно этим они и занимаются. По сути, провайдер проводит против вас атаку DNS hijacking.
Вот как это работает, если всё хорошо. В таком сценарии можно даже не заметить этого "человека посередине" в лице вашего провайдера:
А вот так это работает, когда всё плохо. Провайдер наверняка даже не отправляет запрос к DNS-серверу, которому он предназначался, а просто сразу же возвращает ответ, подставляя адрес своей заглушки:
Но по-настоящему эффективное решение есть. Если провайдер не сможет увидеть, к какому домену происходит обращение, то не сможет и подменить ответ. А ещё лучше, если он вообще не будет знать, что происходит резолвинг имени. Этого можно достичь шифрованием.
Обновим список пакетов. Эту команду нужно выполнять после каждой перезагрузки роутера перед установкой пакетов:
Чтобы плагин для LuCI заработал, нужно сделать выполнить вот такую команду:
Готово! Теперь на компьютере, подключенном к роутеру, можно проверить как это работает:
Обратите внимание, что адреса возвращаются разные: до настройки DoH — неправильный, это результат подмены адресов провайдером, а после — правильный. Можно считать это маленькой победой!
Сам по себе обход блокировок по DNS вряд ли даст ожидаемый эффект, потому что, как правило, в довесок к доменному имени, ресурс блокируется еще и по IP-адресам — видимо, для надежности. Это следующий тип блокировок, которые нужно победить.
Стоит упомянуть про побочные эффекты от такой настройки — могут стать недоступными различные внутренние ресурсы провайдера. Например, когда у меня кончается интернет и я забываю его оплатить, провайдер просто не может меня переадресовать на страницу, куда он обычно направляет своих забывчивых абонентов. Для меня выглядит это всё так, будто интернет просто пропал, без каких-либо объяснений. Я даже первый раз из-за этого чуть не поругался с поддержкой, а оказалось, что это я сам дурак. Что ж, просто приходится платить заранее.
Если нравится статья, то подпишитесь на уведомления о новых постах в блоге, чтобы ничего не пропустить! А ещё читайте другие мои посты!
Шаг 2. Настройка VPN WireGuard
Для того, чтобы обходить блокировки по IP-адресам, придётся настроить VPN — другого способа нет. VPN "спрячёт" от провайдера ваши IP-пакеты так, что он не будет знать куда именно они направляются и что в себе содержат. В качестве протокола предлагаю использовать WireGuard — легковесный VPN-протокол, который к тому же довольно легко настраивать.
Всё описанное дальше вдохновлено и по сути является пересказом вот этой замечательной статьи на Хабре с некоторыми (минимальными) дополнениями от меня.
VPN — это клиент-серверный протокол. Наш роутер будет клиентом, но также нам обязательно нужен сервер. Можно либо поднять свой VPN-сервер самостоятельно (смотрите инструкцию в статье по ссылке выше, это не сложно), либо оформить подписку на какой-нибудь готовый VPN-сервис. Я пробовал оба варианта, но поддерживать свой VPN-сервер оказалось достаточно трудозатратно, и это тоже, как ни странно, стоит денег. Сложнее всего найти хостинг для своего VPN с незаруиненной репутацией. Проблема, с которой я столкнулся, заключалась в том, что все дешевые хостинги уже имеют плохую репутацию (спасибо вам, господа спамеры), и некоторые ресурсы, типа Пикабу (который тоже, как выяснилось, немножко заблокирован), сразу же заранее отвечают ошибкой 403. Намного проще купить готовый VPN, и пусть лучше кто-то другой за меня беспокоится о том, чтобы мне были доступны все нужные мне сайты.
В последнее время появляется очень много VPN-сервисов, которые работают по протоколу WireGuard — это нынче горячая тема. Недавно поддержка WireGuard была добавлена в основной состав ядра Linux. Погуглите, выбор сервисов действительно есть. Сейчас я пользуюсь RedShieldVPN, и меня пока что всё устраивает.
Бонус для читателей: при регистрации по этой ссылке вам подарят месяц бесплатного VPN.
Дальше буду описывать процесс для RedShieldVPN, но, думаю, для других подобных сервисов процесс должен быть похожим.
Переходим в раздел WireGuard, авторизуемся, выбираем страну и скачиваем конфиг. Я обычно выбираю какую-нибудь европейскую страну, чтобы пинг был приемлемым. В этот раз возьму Финляндию.
Вот примерно такой файл конфигурации скачался (ключи я заменил):
Переключимся на роутер и установим там нужную зависимость:
Дальше нужно настроить сеть. Это происходит в файле /etc/config/network . Открываем его при помощи vi (если не умеете пользоваться этим редактором, то лучше предварительно почитайте что-нибудь для подготовки психики) и дописываем в конец две секции вот такого содержания:
Приватный и публичный ключи замените соответствующими значениями из конфига. Поле list addresses заполняется IPv4-адресом из строчки Address в конфиге, а IPv6 адрес мы просто игнорируем — позже станет понятно почему. Поле Endpoint из конфига WireGuard распадается, соответственно, в поля endpoint_host и endpoint_port в конфиге OpenWRT. Остальные поля статичные.
Перезапустим сеть на роутере:
Если команда wg show выводит что-то подобное, то всё идёт хорошо.
Шаг 3. Скрипт для сбора списков заблокированных адресов
Это возможно благодаря крутейшему сервису antifilter.download, который обрабатывает выгрузки Роскомнадзора и отдает их в виде списков IP-адресов в машиночитаемых форматах. Мы настроим периодическую выгрузку списков заблокированных адресов с antifilter.download, чтобы всегда иметь актуальную информацию о блокировках. По моему опыту обновлять этот список раз в сутки (например, ночью) вполне достаточно.
Кроме того, нам нужно настроить файрволл роутера, чтобы он помечал пакеты, которые направляются к заблокированным адресам, специальным маркером. Такие маркированные пакеты должны маршрутизироваться роутером через VPN.
Начнём со скрипта, который реализует эту логику по обновлению списков заблокированных адресов.
Создадим файл /etc/init.d/hirkn со скриптом следующего содержания:
Этот скрипт скачивает два списка заблокированных адресов — один в виде сетей (иногда РКН блокирует адреса целыми подсетями), другой — обобщенный список отдельных заблокированных адресов. За счёт обобщения в небольшие подсети он содержит не миллионы строк, а всего лишь что-то около 15 тысяч. Нам нужны оба списка, они не пересекаются между собой. Файлы сохраняются в каталог /tmp , который в OpenWRT хранится в оперативной памяти — это должно работать быстро. В конце скрипт перезапускает файлволл. Настройка файлволла будет происходит позже.
Добавим этому скрипту права на выполнение:
Добавим скрипт в "автозапуск", чтобы он выполнялся при включении роутера после всех остальных скриптов:
Через cron запланируем выполнение этого скрипта раз в сутки:
В открывшемся редакторе нужно добавить на новой строке:
На crontab.guru можно посмотреть объяснение этой строчки.
Включим cron , потому что по умолчанию в OpenWRT он выключен:
Убедимся, что скрипт работает.
Если файлы со списками заблокированных адресов появились, то всё ок:
Шаг 4. Дальнейшая настройка
Теперь осталось настроить роутер так, чтобы он правильно маршрутизировал пакеты через VPN-туннель.
Создадим таблицу маршрутизации для VPN, добавив в файл /etc/iproute2/rt_tables строчку следующего вида:
Добавим дефолтный маршрут для VPN через туннельный интерфейс:
Чтобы сделать это изменение постоянным, чтобы оно переживало перезагрузки роутера, создадим файл /etc/hotplug.d/iface/30-rknroute с вот таким содержимым:
В файл /etc/config/network , который мы уже редактировали в процессе настройки WireGuard, добавим правило, которое будет перенаправлять маркированные пакеты в таблицу маршрутизации VPN:
Теперь приступим к настройке файрволла. Это самая важная часть логики, которая просматривает списки заблокированных адресов, и маркирует пакеты. В файл /etc/config/firewall допишем несколько абзацев:
Первый из них настраивает зону для VPN — из неё разрешён лишь выход пакетов и включён маскарадинг.
Второй абзац разрешает переход из зоны lan , где по умолчанию находятся все устройства, подключенные к роутеру, в зону для VPN.
Третий и четвертый абзацы заставляют файрволл загрузить файлы со списками заблокированных адресов и распихать по хеш-таблицам в памяти. Как известно, поиск по хеш-таблице происходит за константное время, так что роутер сможет эффективно определять направляется ли пакет к заблокированному адресу или к обычному.
Пятый и шестой абзацы отвечают за маркировку пакетов: "если пакет направляется на заблокированный адрес, то добавим ему пометку 0x1 ".
И запустим наш скрипт:
После этого трафик к заблокированным сайтам должен побежать через VPN. Если нет, то попробуйте перезагрузить роутер.
Шаг 5. Отключаем IPv6
Этот шаг мой самый нелюбимый, потому что я за всё новое и против всего старого. По моему глубокому убеждению IPv4 уже давно должен умереть и быть вытеснен шестой версией протокола. К сожалению, дела у IPv6 пока идут не так гладко, как хотелось бы (сейчас он занимает всего около 30% процентов трафика).
Проблема в том, что antifilter.download выдаёт только заблокированные IPv4 адреса. Это значит, что наш обход блокировок не будет работать по IPv6. Если разрешить вашему роутеру работать по IPv6, то многие ваши устройства предпочтут открывать сайты по IPv6 либо напарываясь на страницы с блокировками от провайдеров, либо просто получая ошибки подключения по таймауту.
Отключаем IPv6 (команды взяты отсюда):
После этого может потребоваться ещё одна перезагрузка роутера, чтобы он перестал раздавать вновь подключенным устройствам IPv6-адреса.
Вот как-то так можно при помощи несложных (ладно, сложных) манипуляций настроить свой роутер на точечный обход блокировок. Все незаблокированные сайты работают как обычно, а заблокированные — через VPN. С такой конфигурацией можно полностью забыть про мелкие пакости от Роскомнадзора и начать, наконец, жить :)
Читайте также: