Comments 34
Windows для такого фу
В случае линукса для вышеупомянутых задач, 128 мб ОЗУ оверкилл))))
128мб это минимум, чтобы lubuntu в принципе завелась... Как оно при таких ресурсах будет работать большой вопрос...
Lubuntu? А нафига на VPN сервере вообще GUI?
Или я чего то не понимаю ...
Хорошо, минималки:
Ubuntu core18: 256MB RAM, 256MB storage
Ubuntu core20: 384MB RAM
Windows Server Core 2019: 512MB RAM
Обратите внимание, я нигде не утверждаю, что Linux в этом смысле хуже, скорее наоборот. И по ресурсам он дешевле и реализация в ядре всегда будет быстрее (при условии одинакового железа). Я даже подумываю портировать wireguard в ядро Windows, но работы многовато, а реальный эффект будет заметен только на гигабите.
Я не спорю, что на Linux выйдет дешевле по ресурсам... Но там и по готовому гайду настроить подобный конфиг сможет далеко не каждый.
Так и хабр вроде ресурс не совсем уж для каждого?
К тому же Wireguard есть в ядре каждого современного ядра Linux и его даже не нужно устанавливать.
Так в инструкции все действия происходят в консоли. Какая разница в чьей консоли команды писать?
А вы пробовали развернуть double VPN на Linux? Не у всех получается, вот например:
Пробовал, разворачивал, но не на базе wireguard.
По ссылке проблема с чьим-то скриптом автонастройки, это вообще к самому wireguard на линуксе отношения не имеет.
У кого-то и на винде возникают проблемы
WireGuard официально не поддерживается в качестве сервера на Windows. Его можно настроить в этом качестве используя ICS, но там есть определённые ограничения и ICS имеет свойство отваливаться при отключении туннеля. Но эту проблему я решил, написав wiresock.
Вообще задача то только в том, чтобы упростить жизнь определённой категории пользователей. На Linux выйдет дешевле по деньгам/ресурсам, на Windows быстрее и проще для не специалиста...
Но эту проблему я решил, написав wiresock.
Стоило это обозначить, вы больно поскромничали. Я, даже прочитав предыдущую статью, не понял, что вы автор. С этой информацией обе статьи становятся несколько иного уровня: есть проблема на винде, и она решена вашей программой.
на Windows быстрее и проще для не специалиста...
По-моему для неспециалиста в обоих случаях вводятся какие-то магические команды.
Стоило это обозначить, вы больно поскромничали. Я, даже прочитав предыдущую статью, не понял, что вы автор. С этой информацией обе статьи становятся несколько иного уровня: есть проблема на винде, и она решена вашей программой.
Виноват, не подумал, что очевидное для меня, не столь очевидно для читателя...
По-моему для неспециалиста в обоих случаях вводятся какие-то магические команды.
На десктопе в принципе всего одна команда нужна для запуска простого туннеля... На Server Core чуть больше возни... Надо как-нибудь заморочиться с GUI, но никогда не умел рисовать, поэтому 'больно' и трудно ;-)
Статья написана для тех, кому сложно или вовсе невозможно построить такое под Linux.
Спасибо большое за хороший гайд.
Честно, вместо того чтобы городить туннель на туннеле, проще просто на первом сервере сделать редирект пакетов на второй. iptables DNAT/SNAT (линуксовые как правило дешевле, а для пары правил больше ничего конфигурировать и не надо), socat (его можно вроде и под виндой при желании поднять) или ещё что в помощь. Тогда первый сервер, например, даже не будет иметь доступа к незашифрованному трафику, ибо коннект будет приземляться сразу вторым.
Если не ошибаюсь, то socat это про TCP, значит просядем по скорости. Можно ещё ssh туннели прикрутить, как вариант. А вообще, правда считаете что это проще и быстрее? ;)
С iptables DNAT/SNAT - однозначно проще и быстрее, да и по скорости точно не просядем. А socat умеет и по udp слушать-редиректить. Да и одна единственная команда socat-а тоже просто.
А вот накладные расходы на расшифровку и тут же зашифровку - вот это проблема, особенно для low-end проксирующих серверов.
В таком случае, почему бы вам не написать статью и не описать процесс и сделать сравнительнные тесты?
И ещё один вопрос, как к вашей схеме прикрутить смартфон в качестве клиента?
А в чём разница со смартфоном? Вы подключаетесь к одному IP, но по факту коннект уходит на другой. Стандартный вайргвардовский клиент разве это не прожуёт? Я просто с вайргвардом конкретно дела не особо имел, и сетапил подобную конфигурацию в своё время для SSTP, и всё прекрасно работало.
Стандартный клиент будет коннектится на указанный в конфигурации адрес. С другой стороны можно поправить конфиг изменив в нем endpoint на промежуточный сервер, который в свою очередь будет пробрасывать пакеты на конечный сервер. В такой конфигурации промежуточный сервер будет работать только как форвардер пакетов.
Из плюсов, меньше нагрузки на промежуточный сервер, из минусов такой трафик гораздо проще отследить. Это уже не двойной VPN, а одинарный с PAT/NAT через промежуточный сервер. Который, кстати несложно зафлудить, так как он форвардит все подряд с определённого порта без всякой авторизации.
Проще отследить? Вот тут внешне хоть 20 штук друг в друга запихнуть паттерн поведения не поменяется и отслеживается будет с одинаковым уровнем сложности. Если бы там были разные протоколы тогда да, можно было бы запутывать следы. А так получается что для того что бы спрятать коня мы прячем его в другого коня для того что бы никто не понял что у нас есть конь.
Двойная нагрузка шифрования будет в любом случае, просто в данном случае мы смешаем её с промежуточного сервера на конечный, но при этом промежуточный уже не может подглядывать в трафик. А по поводу заслужить, да возможно, но тут открывается вся прелесть wireguard в виде минимальной поверхности для атаки, чтоб зафлудить надо чётко знать куда флудить и даже в процессе остаётся только верить что ты успешно флудишь, так как всё что не расшифровывается конечной точкой просто остаётся без ответа. Можно ошибиться портом и флудить в фаервол промежуточного сервера.
При одном туннеле через цепочку прокси если точка входа и точка выхода в условно "контроллируемой" сети, то пропадает весь смысл промежуточных прокси. При цепочке туннелей такой угрозы нет.
Кроме того, обратите внимание, что wiresock может работать как NAT и как TCP/UDP прокси. И в случае цепочки серверов у второго режима есть пара преимуществ:
Прокси ack-ет TCP пакеты на каждом сервере в цепочке, что позитивно сказывается на "видимом" стеком RTT и "общее" TCP окно маршрута как бы растягивается. Проще говоря это несколько компенсирует деградацию TCP из-за возросшего latency.
Характеристики пакетов (размеры) могут измениться после прохождения прокси. В принципе, это можно даже сделать специально. Таким образом входящий туннель не бьётся напрямую с исходящим. Можно ещё пару пару первых звеньев смешать на втором и перебросить через третий.
Так что со всем уважением, но цепочка из прокси и цепочка из wireguard туннелей это совсем не одно и то же с точки зрения отслеживаемости.
Возможно я не совсем правильно донёс мысль, мой косяк. Я имел ввиду структуру не просто с прокси. Трафик заворачивается в wireguard и приходит на промежуточный сервер, промежуточный сервер пришедший трафик заворачивает ещё раз в wireguard и отправляет на конечную точку. Конечная точка последовательно снимает обёртки.
Мы в этой ветке обсуждали один WireGuard туннель через цепочку прокси, поэтому я и принял за продолжение темы. ;-)
С одной стороны вложенные туннели по типу 'матрешки' выглядят как более 'безопасный' вариант, но при этом он более медленный (сокращение MTU, нет компенсации RTT, как в режиме с прокси). Однако при нулевом доверии к промежуточным серверам, это может иметь смысл, например для того товарища из Ирана, чтобы иранский VPS не видел расшифрованный трафик.
Так идея в том, чтоб трафик на промежуточные приходил зашифрованным, и расшифровывался только на конечном. Условно хост => недоверенный промежуточный => доверенный конечный. Трафик шифруется на хосте и расшифровывается только на конечном, все остальные сервера молча перенаправляют шифрованный трафик ничего с ним не делая.
Я такие сетапы делал в своё время для уменьшения пингов, более "прямые" маршруты получались проксированием через сервера, имеющие роуты получше чем у изначального хоста.
Да, я понимаю о чем вы. Сам прямо или косвенно поучаствовал в паре-тройке GPN проектов. Особенно проблема дешёвого медленного трафика актуальна для Австралии.
С точки зрения отслеживаемости, недостаток в том что по всему маршруту имеем одинаковые зашифрованные пакеты, что существенно облегчает сопоставление.
DNS leak тест. Чем пользуетесь на windows server core? Get-DnsClientCache cmdlet retrieves the contents of the local DNS client cache. Это?
Имеется ввиду DNS leak тест со стороны клиента, например https://www.dnsleaktest.com/
Двойной VPN, или как построить цепочку из WireGuard VPN серверов на Windows