Подозреваю, что я не один такой, кто держит дома в режиме 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) обойтись не удастся.
Буду рад любым отзывам и замечаниям...
