В этой статье мы рассмотрим процесс настройки цепочки VPN серверов с помощью WireGuard на Windows. В Интернете есть множество руководств, посвященных построению и настройке цепочек VPN серверов, однако большинство из них основаны на Linux и требуют определенных навыков администрирования данной ОС. В предыдущей статье мы уже узнали, как настроить WireGuard VPN Server в Windows, здесь же мы используем ту же технологию для создания цепочки WireGuard VPN из двух хостов Windows с помощью WireGuard и WireSock.
К написанию данной статьи меня подтолкнул вот этот вопрос на Reddit. Если опустить детали грустной ситуации с Internet в Иране, то останется следующая задача:
So this is solution but i'm not expert in Linux so I didn't know how to do it technically
the solution?
1. buy one VPS Server located in Iran.
2. buy one VPS Server located out of Iran (Europe or USA)
3. tunnel Iran VPS to out side VPS
so when I connect to Iran VPS from my home or office , all my packet send to vps out of Iran. and from that VPS , we can access to internet.
Идея, как говорится, не нова, но за ней огромное будущее: клиент подключается к первому серверу WireGuard, который вместо пересылки клиентского трафика напрямую в Интернет туннелирует его на второй сервер WireGuard, который, в свою очередь, перенаправляет его в Интернет. Можно добавить и больше VPN-серверов в цепочку, получив Triple или Quadro VPN, однако, чем больше промежуточных серверов, тем больше задержки в цепочке и медленнее туннель.
Важное замечание: все серверы WireGuard в цепочке имеют полный доступ к незашифрованному клиентскому трафику. Чтобы избежать этого, мы могли бы рассмотреть возможность «вложения» одного туннеля в другой, чтобы только последний VPN-сервер в цепочке мог полностью его расшифровать. Однако это привело бы к увеличению потребления CPU на клиенте (двойное шифрование) и снижению пропускной способности из-за уменьшения MTU маршрута. Кроме того, клиенты WireGuard для Android и iOS не поддерживают более одного активного туннеля, поэтому в этой статье мы не будем рассматривать «вложенные» туннели WireGuard.
Для чего может понадобиться "двойной" VPN, кроме отмеченной выше ситуации с Internet в Иране? В случае классического VPN подключения, интернет-провайдер может видеть адрес VPN сервера, и сопоставив данные, теоретически можно вычислить активность пользователя в "подконтрольной" сети. При использовании "двойного" трансграничного VPN туннеля, сопоставить трафик на компьютере пользователя и на конечном ресурсе уже не получится.
Мы не будем рассматривать возможные конфигурации и провайдеров VPS, потому что существует множество прямых или косвенных факторов в каждом конкретном случае. Однако, если вы чувствуете себя комфортно с Windows Server Core, то VPS с 1 процессором и 1 ГБ ОЗУ должно быть достаточно для базовых потребностей.
Далее нам необходимо настроить каждый VPS следуя инструкции. Вкратце, нужно скачать и установить последнюю версию WireGuard for Windows и WireSock Gateway и запустив wg-quick-config -add - start создать начальную конфигурацию для сервера WIreGuard. Если вы выбрали Windows Server Core 2016/2019 для своего VPS, то процесс немного сложнее: нужно скопипастить и выполнить пять команд в PowerShell до запуска утилиты wg-quick-config.
При первом запуске wg-quick-config -add -start создает файлы конфигурации для сервера (wiresock.conf) и клиента (wsclient_1.conf), затем запускает туннель WireGuard используя wiresock.conf. Утилита также отображает конфигурацию клиента (wsclient_1.conf) в виде QR-кода, который можно отсканировать с помощью смартфона. Дополнительных клиентов можно добавить, вызвав wg-quick-config -add -restart.
До этого момента процесс установки и настройки идентичен как для VPN-сервера 1, так и для VPN-сервера 2, и в результате вы должны получить два работающих VPN сервера. Не забудьте настроить перенаправление портов и проверьте подключение к каждому из серверов. В случае возникновения проблем попробуйте просто перезагрузить VPS. WireSock Gateway основан на Windows Packet Filter, и в некоторых относительно редких случаях требуется перезагрузка после установки или переустановки драйвера.
Теперь давайте свяжем VPN-сервер 1 и VPN-сервер 2 через WireGuard туннель. Для этого на VPN-сервере 2 откройте wsclient_1.conf с помощью notepad.exe, скопируйте содержимое этого файла в буфер обмена, а затем вставьте его в локально работающий notepad, нам предстоит его немного отредактировать.
Все что нам нужно сделать, это разрешить split tunneling в этой клиентской конфигурации, потому что на VPN-сервер 1 будут работать два туннеля одновременно, к тому же если этого не сделать, то при активации клиентского туннеля мы потеряем связь с сервером. Сделать это очень просто, просто замените AllowedIPs = 0.0.0.0/0 на AllowedIPs = 0.0.0.0/1, 128.0.0.0/1. В итоге получилась такая конфигурация:
[Interface]
PrivateKey = GJVe3Qymog+y+qFdx6Pkszf/y9TnIJqLFchogWbbxWk=
Address = 10.42.42.2/24
DNS = 8.8.8.8, 1.1.1.1
MTU = 1420
[Peer]
PublicKey = AJ50qfhptc1VMcgcaFy0R10Zhgib4f8BMD+xNbKUclw=
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
Endpoint = 130.61.71.138:59075
PersistentKeepalive = 25Теперь создайте новый файл конфигурации на VPN-сервере 1 с именем vpn2.conf, скопируйте в него полученную конфигурацию и сохраните.
Есть два варианта, того, как запустить туннель между VPN-сервером 1 и VPN-сервером 2. Если VPN-сервером 1 работает под управлением Windows с интерфейсом рабочего стола, то можно использовать GUI клиента WireGuard для импорта и запуска только что созданного туннеля. Однако для этого руководства я установил два VPS c Windows Core Server 2019, поэтому выполним следующую команду в PowerShell: wireguard.exe /installtunnelservice "C:\users\vadim\vpn2.conf". Текущую конфигурацию туннелей VPN Server 1 можно посомтреть выполнив команду wg show:
Теперь, если вы подключитесь к VPN-серверу 1 с помощью клиента WireGuard и проверите свой внешний IP-адрес, вы заметите, что он принадлежит VPN-серверу 2.
Однако, если вы запустите DNS leak тест, вы заметите, что он обнаружит сети обоих серверов из нашей цепочки. Это происходит потому, что по умолчанию WireSock Gateway использует локальный DNS-сервер для ускорения разрешения DNS. Это может быть нежелательным поведением в случае цепочки VPN.
К счастью, это очень легко исправить. Сервис WireSock Gateway имеет специальный параметр командной строки, который определяет используемые DNS-сервера. Для этого запустите cmd от имени администратора на VPN-сервере 1 и перенастройте службу WireSock для использования любых нелокальных DNS-серверов (DNS запросы все равно будут перехвачены на VPN-сервере 2). В приведенном ниже примере мы используем 1.1.1.1 и 1.0.0.1 в этом качестве:
wiresock-service uninstall
wiresock-service install -start-type 2 -mode proxy -interface wiresock -log-level none -dns "1.1.1.1, 1.0.0.1"
sc start wiresock-serviceЕсли теперь запустите DNS leak тест, то увидите, что следов VPN-сервера 1 больше не обнаруживается.
Комментарии (34)
Evengard
28.07.2021 23:16Честно, вместо того чтобы городить туннель на туннеле, проще просто на первом сервере сделать редирект пакетов на второй. iptables DNAT/SNAT (линуксовые как правило дешевле, а для пары правил больше ничего конфигурировать и не надо), socat (его можно вроде и под виндой при желании поднять) или ещё что в помощь. Тогда первый сервер, например, даже не будет иметь доступа к незашифрованному трафику, ибо коннект будет приземляться сразу вторым.
SerpentFly Автор
28.07.2021 23:26Если не ошибаюсь, то socat это про TCP, значит просядем по скорости. Можно ещё ssh туннели прикрутить, как вариант. А вообще, правда считаете что это проще и быстрее? ;)
Evengard
28.07.2021 23:45С iptables DNAT/SNAT - однозначно проще и быстрее, да и по скорости точно не просядем. А socat умеет и по udp слушать-редиректить. Да и одна единственная команда socat-а тоже просто.
А вот накладные расходы на расшифровку и тут же зашифровку - вот это проблема, особенно для low-end проксирующих серверов.SerpentFly Автор
28.07.2021 23:54В таком случае, почему бы вам не написать статью и не описать процесс и сделать сравнительнные тесты?
И ещё один вопрос, как к вашей схеме прикрутить смартфон в качестве клиента?
Evengard
29.07.2021 00:48А в чём разница со смартфоном? Вы подключаетесь к одному IP, но по факту коннект уходит на другой. Стандартный вайргвардовский клиент разве это не прожуёт? Я просто с вайргвардом конкретно дела не особо имел, и сетапил подобную конфигурацию в своё время для SSTP, и всё прекрасно работало.
SerpentFly Автор
29.07.2021 01:08Стандартный клиент будет коннектится на указанный в конфигурации адрес. С другой стороны можно поправить конфиг изменив в нем endpoint на промежуточный сервер, который в свою очередь будет пробрасывать пакеты на конечный сервер. В такой конфигурации промежуточный сервер будет работать только как форвардер пакетов.
Из плюсов, меньше нагрузки на промежуточный сервер, из минусов такой трафик гораздо проще отследить. Это уже не двойной VPN, а одинарный с PAT/NAT через промежуточный сервер. Который, кстати несложно зафлудить, так как он форвардит все подряд с определённого порта без всякой авторизации.
Kenit
29.07.2021 09:06Проще отследить? Вот тут внешне хоть 20 штук друг в друга запихнуть паттерн поведения не поменяется и отслеживается будет с одинаковым уровнем сложности. Если бы там были разные протоколы тогда да, можно было бы запутывать следы. А так получается что для того что бы спрятать коня мы прячем его в другого коня для того что бы никто не понял что у нас есть конь.
Двойная нагрузка шифрования будет в любом случае, просто в данном случае мы смешаем её с промежуточного сервера на конечный, но при этом промежуточный уже не может подглядывать в трафик. А по поводу заслужить, да возможно, но тут открывается вся прелесть wireguard в виде минимальной поверхности для атаки, чтоб зафлудить надо чётко знать куда флудить и даже в процессе остаётся только верить что ты успешно флудишь, так как всё что не расшифровывается конечной точкой просто остаётся без ответа. Можно ошибиться портом и флудить в фаервол промежуточного сервера.
SerpentFly Автор
29.07.2021 09:26При одном туннеле через цепочку прокси если точка входа и точка выхода в условно "контроллируемой" сети, то пропадает весь смысл промежуточных прокси. При цепочке туннелей такой угрозы нет.
Кроме того, обратите внимание, что wiresock может работать как NAT и как TCP/UDP прокси. И в случае цепочки серверов у второго режима есть пара преимуществ:
Прокси ack-ет TCP пакеты на каждом сервере в цепочке, что позитивно сказывается на "видимом" стеком RTT и "общее" TCP окно маршрута как бы растягивается. Проще говоря это несколько компенсирует деградацию TCP из-за возросшего latency.
Характеристики пакетов (размеры) могут измениться после прохождения прокси. В принципе, это можно даже сделать специально. Таким образом входящий туннель не бьётся напрямую с исходящим. Можно ещё пару пару первых звеньев смешать на втором и перебросить через третий.
Так что со всем уважением, но цепочка из прокси и цепочка из wireguard туннелей это совсем не одно и то же с точки зрения отслеживаемости.
Kenit
29.07.2021 10:38Возможно я не совсем правильно донёс мысль, мой косяк. Я имел ввиду структуру не просто с прокси. Трафик заворачивается в wireguard и приходит на промежуточный сервер, промежуточный сервер пришедший трафик заворачивает ещё раз в wireguard и отправляет на конечную точку. Конечная точка последовательно снимает обёртки.
SerpentFly Автор
29.07.2021 11:09Мы в этой ветке обсуждали один WireGuard туннель через цепочку прокси, поэтому я и принял за продолжение темы. ;-)
С одной стороны вложенные туннели по типу 'матрешки' выглядят как более 'безопасный' вариант, но при этом он более медленный (сокращение MTU, нет компенсации RTT, как в режиме с прокси). Однако при нулевом доверии к промежуточным серверам, это может иметь смысл, например для того товарища из Ирана, чтобы иранский VPS не видел расшифрованный трафик.
Evengard
29.07.2021 12:17Так идея в том, чтоб трафик на промежуточные приходил зашифрованным, и расшифровывался только на конечном. Условно хост => недоверенный промежуточный => доверенный конечный. Трафик шифруется на хосте и расшифровывается только на конечном, все остальные сервера молча перенаправляют шифрованный трафик ничего с ним не делая.
Я такие сетапы делал в своё время для уменьшения пингов, более "прямые" маршруты получались проксированием через сервера, имеющие роуты получше чем у изначального хоста.
SerpentFly Автор
29.07.2021 12:41Да, я понимаю о чем вы. Сам прямо или косвенно поучаствовал в паре-тройке GPN проектов. Особенно проблема дешёвого медленного трафика актуальна для Австралии.
С точки зрения отслеживаемости, недостаток в том что по всему маршруту имеем одинаковые зашифрованные пакеты, что существенно облегчает сопоставление.
Evengard
29.07.2021 22:05Ну, это да, но вообще косвенно просто по объёму трафика в единицу времени можно сопоставить. Достаточно понять какой входящий трафик какому исходящему соответствовать. А таким странам как Иран врядли нужно будет что-то большее для "доказательств". =)
uyrij
29.07.2021 09:27DNS leak тест. Чем пользуетесь на windows server core? Get-DnsClientCache cmdlet retrieves the contents of the local DNS client cache. Это?
SerpentFly Автор
29.07.2021 09:38Имеется ввиду DNS leak тест со стороны клиента, например https://www.dnsleaktest.com/
vainkop
Windows для такого фу
vertnis
В случае линукса для вышеупомянутых задач, 128 мб ОЗУ оверкилл))))
SerpentFly Автор
128мб это минимум, чтобы lubuntu в принципе завелась... Как оно при таких ресурсах будет работать большой вопрос...
Aelliari
Lubuntu? А нафига на VPN сервере вообще GUI?
Или я чего то не понимаю ...
SerpentFly Автор
Хорошо, минималки:
Ubuntu core18: 256MB RAM, 256MB storage
Ubuntu core20: 384MB RAM
Windows Server Core 2019: 512MB RAM
vertnis
На debian 9 фана ради арендовал VPS со 128 мб ОЗУ, полет нормальный, хватало на туннелирование и веб-сервер, а если еще и zram поставить, прям залейся памятью
SerpentFly Автор
Обратите внимание, я нигде не утверждаю, что Linux в этом смысле хуже, скорее наоборот. И по ресурсам он дешевле и реализация в ядре всегда будет быстрее (при условии одинакового железа). Я даже подумываю портировать wireguard в ядро Windows, но работы многовато, а реальный эффект будет заметен только на гигабите.
SerpentFly Автор
Я не спорю, что на Linux выйдет дешевле по ресурсам... Но там и по готовому гайду настроить подобный конфиг сможет далеко не каждый.
vainkop
Так и хабр вроде ресурс не совсем уж для каждого?
К тому же Wireguard есть в ядре каждого современного ядра Linux и его даже не нужно устанавливать.
SerpentFly Автор
Возможно... С другой стороны наверное не только для администраторов Linux.
Kanlas
Так в инструкции все действия происходят в консоли. Какая разница в чьей консоли команды писать?
SerpentFly Автор
А вы пробовали развернуть double VPN на Linux? Не у всех получается, вот например:
https://qna.habr.com/q/912233
Kanlas
Пробовал, разворачивал, но не на базе wireguard.
По ссылке проблема с чьим-то скриптом автонастройки, это вообще к самому wireguard на линуксе отношения не имеет.
У кого-то и на винде возникают проблемы
SerpentFly Автор
WireGuard официально не поддерживается в качестве сервера на Windows. Его можно настроить в этом качестве используя ICS, но там есть определённые ограничения и ICS имеет свойство отваливаться при отключении туннеля. Но эту проблему я решил, написав wiresock.
Вообще задача то только в том, чтобы упростить жизнь определённой категории пользователей. На Linux выйдет дешевле по деньгам/ресурсам, на Windows быстрее и проще для не специалиста...
Kanlas
Стоило это обозначить, вы больно поскромничали. Я, даже прочитав предыдущую статью, не понял, что вы автор. С этой информацией обе статьи становятся несколько иного уровня: есть проблема на винде, и она решена вашей программой.
По-моему для неспециалиста в обоих случаях вводятся какие-то магические команды.
SerpentFly Автор
Виноват, не подумал, что очевидное для меня, не столь очевидно для читателя...
На десктопе в принципе всего одна команда нужна для запуска простого туннеля... На Server Core чуть больше возни... Надо как-нибудь заморочиться с GUI, но никогда не умел рисовать, поэтому 'больно' и трудно ;-)
SerpentFly Автор
Статья написана для тех, кому сложно или вовсе невозможно построить такое под Linux.