id: Гость   вход   регистрация
текущее время 13:01 28/03/2024
создать
просмотр
ссылки

Легкий openvpn под windows


Нужен легкий клиент, чтобы не использовать сопроводительный софт к конкретным впн сервисам и такой клиент, который позволит работать совместно с другим оригинальным openvpn/openssh софтом не мешая друг-другу и который после себя не оставит разбитую "сетку" которая лечилась бы переустновкой виндов и т.д.
Ну чтобы можно было сделать дабблвпн своими руками. Причем, один софт уже поставлен оригинальный, а второй можно любой, коий и ищется )


 
Комментарии
— unknown (01/08/2013 17:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Зачем стого тэгов в теме? И описание в стиле "можно грабить корованы".
— SATtva (01/08/2013 17:11)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
[offtopic]
Зачем стого тэгов в теме?

В новом движке будет автобан авто-бан за избыточное применение тэгов и восклицательных знаков.
[/offtopic]
— ressa (01/08/2013 22:32)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
Оппа, проговорился))
Когда новый двиг? На чем? какие изменения существенные?)
— Гость (01/08/2013 22:47)   <#>

«О разработке нового движка и о переходе на него».


На питоне. Я уговаривал лично и уговорил не писать на пыхе.
— Гость (03/08/2013 03:33)   <#>
описание в стиле "можно грабить корованы"


стоит штатный openvpn клиент, а заказчик хочет поднять второй от известных vpn сервисов и нужно сделать так, чтобы они не конфликтовали, как? первый (корпоративный) софт уже стоит, а от внешнего сервиса можно поставить любой вбив туда конфиги этого сервиса.
вопрос в поиске второго openvpn "неконфликтного" софта под XP
так понятнее?
а теги... где-то на форумах пишут "задавайте больше тегов" а тут оказывается наоборот, ну извините, можете банить если хотите!
— Гость (03/08/2013 08:40)   <#>

Запускаем 2 стандартных OpenVPN-клиента, но с нестандартными конфигами, отключив в них автоматику вытягивания настроек с сервера (pull). Далее руками прописываем таблицу маршрутизации (gateway, статические маршруты) так, чтобы было Host → VPN-1 → VPN-2 → сеть. Примерная схема настройки после отключения всей автоматики:
  1. Отключаем провайдерский default gw в настройках.
  2. Прописываем руками статический маршрут к внешнему IP VPN-1 через gw прова: route add VPN-1-INET ISP-GW
  3. Запускаем IOpenVPN-клиент для VPN-1. Он создаёт виртуальный сетевой интерфейс, на котором будет его виртуальный IP, виртуальный IP VPN-сервера и виртуальный gw в этой виртуальной сети VPN-1-VIRT-GW (gw может автоматом не подцепиться, но выяснить, какой он, можно). Следим, чтобы этот VPN-1-VIRT-GW не прописал себя как default. Если прописал, то убираем default-флаг с него.
  4. Добавляем статический маршрут до VPN-2 через gateway первого VPN: route add VPN-2-INET VPN-1-VIRT-GW. Теперь весь трафик, предназначенный серверу VPN-2, пойдёт через VPN-1 (через уже созданный нами туннель).
  5. Запускаем OpenVPN-клиент для VPN-2. Аналогично первому клиенту он создаст свою виртуальную сеть с виртуальными IP, в которой будет (точнее, поддерживается серевром) некоторый виртуальный GW, назовём его VPN-2-VIRT-GW.
  6. Прописываем VPN-2-VIRT-GW умолчальным для всего трафика: route add default gw VPN-2-VIRT-GW.
  7. Всё работает, PROFIT.
В винде будут несколько другие команды, но смысл настройки в точности тот же. Оптимально ещё firewall сверху навесить, который бы контролировал траф в случае падения какого-то из серверов и т.д., для подстраховки. С небольшими изменениями это тот же метод, что и описанный в этом треде.

Другой вариант настройки — виртуалки или просто 2 физические машины. Во внешней ОС свой VPN-клиент, во внутренней — свой. Тут, возможно, всё заработает и искоробки без правок.
— Гость (07/08/2013 20:18)   <#>
Немного другой вопрос, но тоже в тему и тоже под винды уж простите любезные, не я принимал решения о выборе ОС )))
Поднимаю openVPN, затем поверх нужно запустить PPTP (или L2TP) и вроде все вяжется, но route.exe показывает, что маршрут идет ТОЛЬКО через гейты созданные первым !
С route.exe игрался долго, но так ничего и не добился :( Можно его вручную перенаправить трафик куда надо только с помощью route.exe ?
Нужно добиться следующего: Provider -> OpenVPN -> PPTPorL2TP -> Internet
— Гость (08/08/2013 02:49, исправлен 08/08/2013 11:15)   <#>

Эх... "Ламеры, ламеры, ламеры идут... щас мы их из плюсомета! ..." ;-)
Короче, давайте по-порядку?


На примере все айпишники кроме 128.0.0.0 взяты от балды.


Подключаемся к инету напрямую и route print 0.0.0.0 выдает допустим :



ВПНы еще НЕ подняты. ЧТО я должен делать на данном этапе ?


Ежели далее мы запускаем первый ВПН, то получаем примерно следующее :



кстати для тех кто боится что в случае падения ВПН трафик пойдет напрямую, можно набрать : route delete 0.0.0.0 mask 0.0.0.0 10.123.123.123 IF 0x10001 но мы этого делать не будем ради чистоты эксперимента


Дальше запускаем второй ВПН который связывается допустим с: 8.8.8.8 ( адресок взят по приколу )


Он вяжется и получаем :



Это если ничего не менять в процессе поднятия ВПНов.
Так вот вопрос, почему после всего этого трафик продолжает идти через ВПН1 ?
Может ли Гость (03/08/2013 08:40) или кто-нибудь еще на примере с вышеназванными айпишниками дать команды для route, которые нужно набирать в определенные моменты установления соединения?

— Гость (09/08/2013 12:38)   <#>

Удалить тот маршрут, который вы показали, из таблицы маршрутизации. Под маску сети 0.0.0.0 подходит любой IP, поэтому, если не найден более конкретный маршрут (маршрут с более меньшей(?) [более конкретной] метрикой), то он будет послан на тот gw, который соответствует 0.0.0.0. Т.о., 10.123.123.123 — ваш default gateway. Его надо удалить. Т.е. удалить этот маршрут из таблицы записей. Судя по вашей команде, это делается как
route delete 0.0.0.0 mask 0.0.0.0 10.123.123.123 IF 0x10001
После этого интернет пропадёт. Чтобы заработало соединение с первым VPN вы должны добавить маршрут к нему руками, это будет, если я правильно понимаю, что-то типа
route add VPN-IP mask 255.255.255.255 10.123.123.123 IF 0x10001
На этом этапе система знает, как послать пакет на VPN-IP. Как послать на любой другой — не знает.


Надо либо отключить poll в конфиге VPN, чтобы он не устанавливал себя в default (0.0.0.0), либо после его запуска руками удалить этот маршрут, оставив только нужный:
route delete 0.0.0.0 mask 128.0.0.0 10.222.222.222 IF 10.222.222.223 <хз, какой IF верный>
route add VPN-2 mask 255.255.255.255 10.222.222.222 IF 10.222.222.223 <хз, какой IF верный>
где VPN-2 — реальный адрес VPN-2.


Адрес напоминает DNS гугла. :)


Нужно всё делать попорядку: 1) Садка 2) Вязка 3) Склещивание 4) Развязка. И не забывайте промыть всё хорошо раствором.

Меня удивляет, что у вас 2 IF. Должно быть 3, разве нет? Основной сетевой, виртуальный от первого VPN и виртуальный от второго VPN. После поднятия 2-го VPN у вас его виртуальный IF появился, а после первого нет. Почему?


Потому, что маска 128.0.0.0 более конкретна, чем 0.0.0.0, а IP для обоих масок один и тот же — 0.0.0.0, потому более высокий приоритет получает маршрут 0.0.0.0 128.0.0.0 10.222.222.222 10.222.222.223. Так работает метрика. Таковы законы роутинга. Я вам предложил пофикс через замену 0.0.0.0 на конкретные адреса.


Не знаю. Скорей всего, там должен быть либо реальный gw (10.123.123.123), либо gw для второго VPN (10.1.1.1?). Более точно не скажу, потому что не знаю его логику.

Итоговая таблица должна быть примерно такой:
Активные маршруты:
Сетевой адрес           Маска сети        Адрес шлюза       Интерфейс
          0.0.0.0       0.0.0.0           10.1.1.1          10.1.1.1
          VPN-2         255.255.255.255   10.222.222.222    10.222.222.223
          VPN-1         255.255.255.255   10.123.123.123    10.123.123.123
но в последних двух колонках не уверен. Адрес шлюза и интерфейс точно совпадают, как вы написали в первой команде, которая ещё до запуска VPN-ов? Есть IP адрес, который присвоен компьютеру — это в идиотской виндовой терминологии шлюз или интерфейс? Наверно, интерфейс. Сетевой адрес + маска задают однозначно группу адресов, для которых пишется маршрут. Остальные поля в записи должны говорить о том, какая физически сетевая карта будет выбрана и какой gateway взят для этого набора адресов. Если IP назначен руками, его можно считать синонимом индентификатора сетевой карты в этой идиотской терминологии, но ей скорее соответствует идентификатор 0xXXXXX, чем IP.

Вообще, да, что-то мне подсказывает, что вы врёте. Первая команда должна давать вот это:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс 
          0.0.0.0          0.0.0.0      ISP-GW            ВАШ_IP
где ISP GW — провайдерский GW, который обычно получают автоматически по DHCP или статично прописывают в настройках сети, а ВАШ_IP — это ваш IP, и совпадать с ISP GW оно не может никак.

iОбъяснение, как настраивать оффтопик (т.е. винду) — это пропаганда его использования. Вот мне оно зачем здесь? Идите к дебилам, который сидят на оффтопике, и пусть они вам объяснят основы роутинга. Мне-то зачем поддерживать M$ посредством поддержки ещё одного её клиента — вас? Тем более здесь, на pgpru. Безопасность и анонимность несовместимы с проприетарными системами никак, на этом все ответы про винду должны заканчиваться.
— Гость (09/08/2013 13:46)   <#>
Гость (07/08/2013 20:18)

а чего на ixbt и ruboard не могут помочь? там почти все на Виндах )
— Гость (11/08/2013 15:26)   <#>

Если они примут решение, что вам нужно вниз головой попрыгать, вы тоже согласитесь с этим связаться?


Можно. Трафик VPN'ов идёт так, как это указывают системные настройки. Естественно, надо следить за тем, чтобы эти настройки не конфликтовали с теми, что у сервера и соответствовали им. Так всегда можно сделать.

Вообще, конфигурация, которую хочет гость, глючная, автоматика OpenVPN будет запутываться, действительно надо руками прописывать маршруты, чтоб заработало. Важная деталь — то, что в винде интерфейс для OpenVPN создаётся при его установке, а не запуске, и этот интерфейс один. Он есть в системе независимо от того, используется OpenVPN или нет. Если нужно больше интерфейсов (если хочется использовать более, чем один OpenVPN одновременно), необходимые интерфейсы надо досоздавать руками. К примеру, можно создать cmd-ярлык с названием add new tap32 adapter. И сначала нужно создать необходимые интерфейсы, а только потом запускать OpenVPN'ы.

Другой момент более концептуальный. При реальном использовании такой схемы не получается её настроить так, чтобы раз и навсегда. Провайдеры глючат, VPN'ы меняют свои сервера и настройки. Иногда надо зайти в личный кабинет провайдера и что-то там нажать, чтобы интернет заработал. Если интернет по каким-то причинам не работает, приходится выяснять почему, и на системе, где всё правильно настроено, а дыры для обхода файерволла заткнуты, это не так просто. Полностью менять конфигурацию сети только для того, чтобы провести диагностику — гемор. Лучше разные VPN запускать на разных машинах. Например, один у себя, а другой — на роутере.

Что касается doublevpn — это не VPN over VPN (вопрос чисто терминологический). Это значит, что трафик входит на один VPN-сервер, а выходит из другого, при этом клиента не колышит, как VPN-сервера связываются друг с другом — за это отвечает VPN-провайдер. Понятно, что подключение к doublevpn ничем не отличается от подключения к обычному, для клиента всё прозрачно. Если оба VPN'а принадлежат гостю, то коннектить их как vpn over vpn — гемор и оверхед, если же они принадлежат разным поставщикам, то это имеет какой-то смысл. Ключи на серверах хранить нет смысла, их можно загружать в память по сети после старта сервера и никогда не сохранять на локальный диск.

Если инфраструктура делается под себя, то делать двухоповую VPN-сеть тороподобной (с VPN over VPN) нет смысла. VPN-entry узел может работать гейтом трафика на VPN-exit, формально его пропуская и ничего не шифруя. Опционально на VPN-entry можно поставить свой VPN-клиент, который будет дополнительно шифровать трафик до VPN-эксита. Юзерский трафик в любом случае будет расшифровываться только на VPN-эксите. Правильный doublevpn может иметь много клиентов, много маршрутов и внутреннюю mix-сеть, что затрудняет привязку трафика к клиенту. Однако, всё равно надо понимать, что VPN — он не для анонимности, хотя и может в каких-то случаях затруднять деанон. Если вся VPN-сеть принадлежит одному поставщику, он и так знает все маршруты. Их же знает и клиент. Их же знает и посторонний наблюдатель — достаточно стать клиентом сети. Всё упирается в доверие поставщику VPN, и эта проблема не решается никак. Даже если говорить об анонимности, основное назначение VPN — вынос трафик в неподконтрольную зону, но не более того.

Проблема доверия к поставщику VPN — больная тема, но здесь есть много параллелей с сетью Tor. Как не трудно себе представить, спонсорская поддержка и разработка Tor осуществляется не с целью увеличения неподконтрольности интернета и его пользователей, как и не с целью защиты privacy обывателей, а для прикрытия совсем другой деятельности — например, операций спецслужб. Ради тех случаев, где им самим нужен Tor, они готовы потерпеть те неудобства, которые вызывает доступность Tor'а всем на планете. С VPN тоже может наблюдаться что-то похожее. Цель предоставления VPN-сервиса — не столько бизнес, сколько прикрытие чего-то иного. VPN-сеть может работать даже себе в убыток, если она справляется с основной целью своего существования. Реальные владельцы VPN не всегда известны, и при возникновении проблем бизнес иногда закрывают. Всё-таки VPN-бизнес — не уровень MS и гугла, которых всегда можно принудить к сотрудничеству и сливу ключей, да и закрыть VPN-бизнес и открыть потом снова в другом месте тоже не так сложно. Т.е. для уверенности, что все всегда сдают своих клиентов в 100% случаев нет реальных оснований, хотя вероятность того, что сдаст конкретный поставщик VPN, нельзя сбрасывать со счетов.

Есть ещё одно существенное опасение опасение по поводу VPN. Если какой-то клиент совершил криминал, то под подозрение, прослушку и пристальное внимание могут попасть все клиенты этого сервиса, причём им будет тем хуже, чем их меньше. В некотором смысле ответственность может распределится между всеми клиентами, и потом каждому придётся персонально доказывать, что он не верблюд, и что это был не он. Кроме того, с учётом того, что с эксита выходит личный трафик нескольких клиентов, по ошибке трафик одного могут приписать трафику другого, кто пользовался этим сервером в это же время. Теоретически такие проблемы могут возникнуть, но пока о них не было слышно. Тем не менее, забывать о них не стоит.
— Гость (23/11/2014 05:43)   <#>
> стоит штатный openvpn клиент, а заказчик хочет поднять второй от
известных vpn сервисов и нужно сделать так, чтобы они не конфликтовали, как?

Запускаем 2 стандартных OpenVPN-клиента, но с нестандартными конфигами,
отключив в них автоматику вытягивания настроек с сервера (pull). Далее
руками прописываем таблицу маршрутизации (gateway, статические маршруты)
так, чтобы было Host? VPN-1? VPN-2? сеть. Примерная схема настройки
после отключения всей автоматики:

1. Отключаем провайдерский default gw в настройках.
2. Прописываем руками статический маршрут к внешнему IP VPN-1 через gw
прова: route add VPN-1-INET ISP-GW
3. Запускаем IOpenVPN-клиент для VPN-1. Он создаёт виртуальный сетевой
интерфейс, на котором будет его виртуальный IP, виртуальный IP
VPN-сервера и виртуальный gw в этой виртуальной сети VPN-1-VIRT-GW
(gw может автоматом не подцепиться, но выяснить, какой он, можно).
Следим, чтобы этот VPN-1-VIRT-GW не прописал себя как default. Если
прописал, то убираем default-флаг с него.
4. Добавляем статический маршрут до VPN-2 через gateway первого VPN:
route add VPN-2-INET VPN-1-VIRT-GW. Теперь весь трафик,
предназначенный серверу VPN-2, пойдёт через VPN-1 (через уже
созданный нами туннель).
5. Запускаем OpenVPN-клиент для VPN-2. Аналогично первому клиенту он
создаст свою виртуальную сеть с виртуальными IP, в которой будет
(точнее, поддерживается серевром) некоторый виртуальный GW, назовём
его VPN-2-VIRT-GW.
6. Прописываем VPN-2-VIRT-GW умолчальным для всего трафика: route add
default gw VPN-2-VIRT-GW.
7. Всё работает, PROFIT.


Насколько я понимаю при такой схеме развертывания сначала запускается один VPN, а затем второй и у провайдера видно обращение сначала к одному VPN адресу, а затем ко второму?
То есть насколько я понял порядок поднятия VPN будет таковым:
Сначала: provider-VPN1-internet
Затем: provider-VPN2-VPN1-internet
То есть "паровозиком".
А можно ли сделать "куммулятивно"? То есть так чтобы у провайдера всегда был виден только один VPN который поднимается первым?
И цепочка была бы такой: provider-VPN1-VPN2-internet
А последовательность развертывания соответственно такая:
provider-VPN1-internet
provider-VPN1-VPN2-internet
Таким образом сервера VPN2 у провайдера не будут видны никогда.
В чем плюсы предложенной схемы думаю объяснять не нужно? Без "глобального наблюдателя" провайдер не будет знать о существовании VPN2 вообще.

ЗЫ
Гостю (11/08/2013 15:26) за развернутый комментарий отдельно респект!
— Гость (23/11/2014 13:58)   <#>

Предложенная схема – последовательная. Параллельная – 3 системы/устройства, каждый отдельно поднимает vpn, в таком случае, провайдер будет видеть 3 vpn соединения.
— Гость (23/11/2014 14:01)   <#>
Doblevpn вообще просто сделать. На хосте сождаете vpn соединение и затем в гостевой системе (соединение хост-гость как nat).
— Гость (23/11/2014 22:52)   <#>

А можно понятнее? ) Нужна именно ПОСЛЕДОВАТЕЛЬНАЯ схема, причем так как описано выше:

А последовательность развертывания соответственно такая:
provider-VPN1-internet
provider-VPN1-VPN2-internet
Таким образом сервера VPN2 у провайдера не будут видны никогда.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3