Подозреваю, что я не один такой, кто держит дома в режиме 24/7 маленький и тихий системный блок с Windows в качестве сервера, на который можно зайти по RDP (с того же смартфона) и несколько переживает в связи с количеством «неслучайных» попыток к нему подключиться. Задача не новая и вполне себе решаемая, например можно рассмотреть следующие варианты:
Настроить OpenSSH сервер, начиная с Windows 10 1809 он официально часть дистрибутива, включить авторизацию по ключам и заходить на RDP через SSH тоннель. На маршрутизаторе соответственно настроить перенаправление только для SSH порта. Из плюсов - достаточно безопасно, из минусов:
Не очень понятно, можно ли зайти со смартфона (для iPhone вероятно понадобится какой-то гибридный RDP клиент).
Поддерживается только TCP, а RDP уже довольно давно умеет использовать преимущества UDP.
Обновления Windows имеют необъяснимое свойство отключать OpenSSH, не знаю с чем это связано, но несколько за год раз такое было.
Настроить VPN непосредственно на маршрутизаторе. В целом, решение рабочее и минусы тут довольно субъективные:
Не хочется вешать на маршрутизатор дополнительную «необязательную» нагрузку.
Открывается дополнительный вектор атаки непосредственно на маршрутизатор.
Требует определенных технических навыков.
Дополнительно установить Raspberry Pi и на нем настроить VPN (можно ещё много чего на ней запустить). До сих пор пользуюсь, отличный вариант, если есть необходимые навыки и немного денег на «малинку».
Скорее для полноты картины, чем для реального домашнего использования, можно установить Hyper-V на нашу машинку с Windows, создать виртуальную машину с Linux и на нем настроить VPN. Как и в предыдущем случае:
Требует определенных технических навыков.
Увеличивается нагрузка на наш не особенно могучий домашний сервер (у меня это обычно Intel NUC) .
Могут возникнуть проблемы при отключении питания (виртуальная машина окажется в состоянии Saved и VPN будет недоступен).
Ну и наконец, можно установить сервер VPN непосредственно на Windows. Выбор конкретного VPN дело глубоко личное, но мне последние пару лет посчастливилось изрядно поработать с WireGuard и даже реализовать специализированного клиента для Wandera, в связи с этим выбор был очевиден.
Предварительные изыскания
Я думаю, это ни для кого не новость, что WireGuard уже больше года как включен в основную ветку ядра Linux. С Windows не все так радужно, однако в силу специфики протокола официальный WireGuard для Windows вполне себе выполняет функцию сервера, ему не хватает только NAT. Благодаря Henry Chang и его вдохновленному им micahmo примерно известно как сделать это стандартными средствами Windows. Честно говоря, процесс выглядит немного сложновато, хотя надо отдать должное micahmo, который его частично автоматизировал. Помимо этого, меня заинтересовал следующий комментарий под оригинальным постом:
Good day, excellent article!
I have a Win10 machine that I plan to use as a wireguard server. This machine has a main internet network adapter + OpenVPN client connection that is used for selected routes.
If I understand correctly described above wireguard VPN setup will only allow my wireguard clients to access main internet interface but not the OpenVPN connection, please correct me I’m wrong.
Is there a way for a wireguard client to use all available connections and honor existing routes configuration on wireguard server?Thank you!
Думаю, что полный перевод не требуется, суть состоит в том, чтобы WireGuard использовал для выхода не какой-то один определенный интерфейс (это единственный вариант с Windows Internet Connection Sharing), а тот из них который определен согласно действующей таблице маршрутизации.
Итак, сформулируем задачу
Максимально упростить процесс установки и настройки WireGuard. Давление на компании предоставляющие услуги VPN нарастает и, согласитесь, было бы неплохо, если бы любой пользователь Windows мог бы:
Настроить WireGuard на сервере расположенном облаке, не погружаясь в особенности реализации. Я не призываю к обходу блокировок уважаемого Роскомнадзора, но это так же может быть необходимо, чтобы обойти географические ограничения на какие-то продукты или услуги. Например, до недавнего времени, Ghidra нельзя было скачать с российского IP адреса. Сайт и сейчас вас не пустит, но сам дизассемблер можно скачать с Github. Или цена (валюта расчетов) на авиабилеты может варьироваться в зависимости от страны, с IP которой Вы зашли на сайт авиакомпании. Или можем вспомнить недавнюю историю с "неофициально" ввезенными телевизорами Samsung, у которых "неожиданно" отключилась функция Smart TV. Вернуть телевизор к нормальной жизни можно было только подключив его через европейский VPN. И это только то, что я сходу смог вспомнить...
Установить WireGuard на домашнем Windows сервере и получить постоянный защищенный доступ в собственную сеть и пользоваться ВСЕМИ сервисами доступными ему дома независимо от того в какой точке мира он находится. Например, понравилась мне Яндекс Станция (это не реклама, я действительно их довольно много приобрел для себя, для семьи, в подарки друзьям), да так, что я даже одну привез на Тенерифе. И тут выяснилась удивительная подробность, Яндекс-музыка работает за границей, а вот КиноПоиск ссылается на географические ограничения и отказывается работать. Было бы обидно, но настроил WireGuard клиента на роутере Keenetic и подключил Яндекс станцию через домашний VPN в России. А еще не так уж давно я проделывал что-то подобное для Amazon Fire Stick, чтобы нормально пользоваться подпиской Prime. Могу ошибаться, но кажется где-то читал, что и сам WireGuard был изначально придуман, чтобы смотреть американский Netflix из Австралии.
Использовать некую альтернативу Internet Connection Sharing со всем уважением к имеющейся сетевой конфигурации.
Примерно месяц назад у меня появилось 3-4 относительно свободных дня на неделе и я приступил к ее постепенной реализации. Как раз на днях закончил "боевую" сборку, которая в настоящее время успешно крутится на паре домашних машинок с Windows 10 Pro и на VPS в Microsoft Azure (Windows Server 2019 Core, 1vCPU + 1Gb) и которую нестыдно показать. Сразу должен отметить, что по производительности реализация в ядре безусловно выигрывает и если вам не составляет особенного труда сконфигурировать WireGuard на VPS с Linux, то это более оптимальный выбор. Моя целевая аудитория - это обычные пользователи Windows далекие от IT. Насколько могу судить, в текущей реализации самое сложное это настроить перенаправление UDP порта (на роутере или в панели управления виртуальной машиной в облаке).
WireSock Gateway
И с WireGuard созвучно и по смыслу подходит, к тому же, как удачно, домен wiresock.net оказался свободен. Инсталляторы и краткая инструкция по установке есть на сайте. В двух словах, кроме того, чтобы скачать и установить приложение, необходимо запустить 'cmd' с правами Администратора и выполнить 'wg-quick-config -add -start'. wg-quick-config постарается определить внешний IP адрес и свободный локальный UDP порт, которые будут предложены по умолчанию. Если на маршрутизаторе настроен динамический DNS, то можно поменять IP на доменное имя. Если ISP/VPS провайдер выдает вам 'белый" IPv4 адрес, то после этого достаточно настроить форвард на роутере для выбранного UDP порта. Виртуальная сеть для WinTun адаптера по умолчанию 10.9.0.0/24, но так же по желанию может быть изменена.
wg-quick-config создаст файлы конфигурации для сервера (wiresock.conf) и клиента (wsclient_1.conf), создаст и запустит WIreGuard туннель, а так же отобразит конфигурацию клиента в виде QR кода, который можно отсканировать смартфоном. Дополнительных клиентов можно добавлять, вызывая 'wg-quick-config -add -restart'.
Основная работа выполняется сервисом Wiresock Service, который поддерживает два режима работы: NAT и Proxy.
Первый это классический NAT, сервис включает маршрутизацию (для некоторых типов соединений начиная с Windows 7 встроенная маршрутизация не работает, и они маршрутизируются "вручную"), определяет внешний интерфейс "по умолчанию" на котором и занимается подменой адресов во входящих/исходящих пакетах. Получает почти то же самое, что дает встроенный Internet Connection Sharing, но без ограничений на адреса клиентской сети.
Второй несколько интереснее и именно этот режим включается инсталлятором по умолчанию. Все TCP/UDP соединения (для UDP условно), кроме DNS и NTP, прозрачно перенаправляются на локальные TCP/UDP прокси, которые уже от своего имени устанавливают соединения к сетевым ресурсам. При этом если у локальной системы присутствуют системные настройки HTTP/SOCKSv5 прокси, то Wiresock Service со всем уважением будет их использовать. Что касается NTP и DNS, то они обрабатываются отдельно. Wiresock Service сам отвечает за NTP сервер, а для DNS запросы перенаправляются на локально сконфигурированные IPv4 DNS сервера, а если таковых по каким-то причинам не окажется, то используются 8.8.8.8 и 1.1.1.1. Единственный недостаток данного подхода - не будет работать ping на внешние адреса.
Таким образом, основные задачи вроде бы выполнены. И если к проекту будет интерес, то ему есть куда развиваться, например:
На данный момент (v.1.0.2.4) отсутствует поддержка IPv6.
"Белые" IPv4 постепенно становятся редкостью, поэтому хотелось бы организовать работу WireGuard сервера за NAT (или даже multi-NAT) Интернет-провайдера. Здесь правда без внешнего сервиса (с "белым" IP) обойтись не удастся.
Буду рад любым отзывам и замечаниям...
