Легкий openvpn под windows
Нужен легкий клиент, чтобы не использовать сопроводительный софт к конкретным впн сервисам и такой клиент, который позволит работать совместно с другим оригинальным openvpn/openssh софтом не мешая друг-другу и который после себя не оставит разбитую "сетку" которая лечилась бы переустновкой виндов и т.д.
Ну чтобы можно было сделать дабблвпн своими руками. Причем, один софт уже поставлен оригинальный, а второй можно любой, коий и ищется )
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
В новом движке будет
автобанавто-бан за избыточное применение тэгов и восклицательных знаков.[/offtopic]
комментариев: 1079 документов: 58 редакций: 59
Когда новый двиг? На чем? какие изменения существенные?)
«О разработке нового движка и о переходе на него».
На питоне. Я уговаривал лично и уговорил не писать на пыхе.
стоит штатный openvpn клиент, а заказчик хочет поднять второй от известных vpn сервисов и нужно сделать так, чтобы они не конфликтовали, как? первый (корпоративный) софт уже стоит, а от внешнего сервиса можно поставить любой вбив туда конфиги этого сервиса.
вопрос в поиске второго openvpn "неконфликтного" софта под XP
так понятнее?
а теги... где-то на форумах пишут "задавайте больше тегов" а тут оказывается наоборот, ну извините, можете банить если хотите!
Запускаем 2 стандартных OpenVPN-клиента, но с нестандартными конфигами, отключив в них автоматику вытягивания настроек с сервера (pull). Далее руками прописываем таблицу маршрутизации (gateway, статические маршруты) так, чтобы было Host → VPN-1 → VPN-2 → сеть. Примерная схема настройки после отключения всей автоматики:
- Отключаем провайдерский default gw в настройках.
- Прописываем руками статический маршрут к внешнему IP VPN-1 через gw прова: route add VPN-1-INET ISP-GW
- Запускаем IOpenVPN-клиент для VPN-1. Он создаёт виртуальный сетевой интерфейс, на котором будет его виртуальный IP, виртуальный IP VPN-сервера и виртуальный gw в этой виртуальной сети VPN-1-VIRT-GW (gw может автоматом не подцепиться, но выяснить, какой он, можно). Следим, чтобы этот VPN-1-VIRT-GW не прописал себя как default. Если прописал, то убираем default-флаг с него.
- Добавляем статический маршрут до VPN-2 через gateway первого VPN: route add VPN-2-INET VPN-1-VIRT-GW. Теперь весь трафик, предназначенный серверу VPN-2, пойдёт через VPN-1 (через уже созданный нами туннель).
- Запускаем OpenVPN-клиент для VPN-2. Аналогично первому клиенту он создаст свою виртуальную сеть с виртуальными IP, в которой будет (точнее, поддерживается серевром) некоторый виртуальный GW, назовём его VPN-2-VIRT-GW.
- Прописываем VPN-2-VIRT-GW умолчальным для всего трафика: route add default gw VPN-2-VIRT-GW.
- Всё работает, PROFIT.
В винде будут несколько другие команды, но смысл настройки в точности тот же. Оптимально ещё firewall сверху навесить, который бы контролировал траф в случае падения какого-то из серверов и т.д., для подстраховки. С небольшими изменениями это тот же метод, что и описанный в этом треде.Другой вариант настройки — виртуалки или просто 2 физические машины. Во внешней ОС свой VPN-клиент, во внутренней — свой. Тут, возможно, всё заработает и искоробки без правок.
Поднимаю openVPN, затем поверх нужно запустить PPTP (или L2TP) и вроде все вяжется, но route.exe показывает, что маршрут идет ТОЛЬКО через гейты созданные первым !
С route.exe игрался долго, но так ничего и не добился :( Можно его вручную перенаправить трафик куда надо только с помощью route.exe ?
Нужно добиться следующего: Provider -> OpenVPN -> PPTPorL2TP -> Internet
Эх... "Ламеры, ламеры, ламеры идут... щас мы их из плюсомета! ..." ;-)
Короче, давайте по-порядку?
На примере все айпишники кроме 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, которые нужно набирать в определенные моменты установления соединения?
Удалить тот маршрут, который вы показали, из таблицы маршрутизации. Под маску сети 0.0.0.0 подходит любой IP, поэтому, если не найден более конкретный маршрут (маршрут с более меньшей(?) [более конкретной] метрикой), то он будет послан на тот gw, который соответствует 0.0.0.0. Т.о., 10.123.123.123 — ваш default gateway. Его надо удалить. Т.е. удалить этот маршрут из таблицы записей. Судя по вашей команде, это делается как
Надо либо отключить poll в конфиге VPN, чтобы он не устанавливал себя в default (0.0.0.0), либо после его запуска руками удалить этот маршрут, оставив только нужный:
Адрес напоминает 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?). Более точно не скажу, потому что не знаю его логику.
Итоговая таблица должна быть примерно такой:
Вообще, да, что-то мне подсказывает, что вы врёте. Первая команда должна давать вот это:
а чего на ixbt и ruboard не могут помочь? там почти все на Виндах )
Если они примут решение, что вам нужно вниз головой попрыгать, вы тоже согласитесь с этим связаться?
Можно. Трафик 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. Если какой-то клиент совершил криминал, то под подозрение, прослушку и пристальное внимание могут попасть все клиенты этого сервиса, причём им будет тем хуже, чем их меньше. В некотором смысле ответственность может распределится между всеми клиентами, и потом каждому придётся персонально доказывать, что он не верблюд, и что это был не он. Кроме того, с учётом того, что с эксита выходит личный трафик нескольких клиентов, по ошибке трафик одного могут приписать трафику другого, кто пользовался этим сервером в это же время. Теоретически такие проблемы могут возникнуть, но пока о них не было слышно. Тем не менее, забывать о них не стоит.
Насколько я понимаю при такой схеме развертывания сначала запускается один 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) за развернутый комментарий отдельно респект!
Предложенная схема – последовательная. Параллельная – 3 системы/устройства, каждый отдельно поднимает vpn, в таком случае, провайдер будет видеть 3 vpn соединения.
А можно понятнее? ) Нужна именно ПОСЛЕДОВАТЕЛЬНАЯ схема, причем так как описано выше: