Vpn bridge что это

Объединяем свои устройства через интернет в одну сеть (VPN для самых маленьких, в картинках)

Подобных обзоров «как создать свой VPN» крайне много, но я так и не нашёл простого решения для новичка, с поддержкой создания полноценной локальной сети между двух и более клиентов с серым IP, находящимися за NAT.

Данное руководство я отношу к уровню подготовки «user+»: пользователь должен но не обязан знать что хочет получить, уверенно держит в руке мышь и видел командную строку в фильмах про хакеров.

Хочу обратить внимание начинающих хакеров: если вы взломаете пентагон с данного IP, скорее всего, ваш провайдер (Amazon в данном случае) сдаст вас «с потрохами» и от суровых людей с паяльником в руках спасения не будет.

ежемесячный платеж 350 рублей

Ежемесячный платёж 350 рублей, но вы можете сэкономить и не покупать выделенный IP у своего провайдера.

Собственно проходим по ссылке и регистрируемся lightsail.aws.amazon.com

окно регистрации AWS

Номер телефона и банковскую карту указываем свою, может придётся пройти проверку по телефону (звонит робот), мне не пришлось.

(дополнительно) для доступа по SSH нужно получить отдельный ключ

выбираем регион выбираем операционную систему выбираем тип сервера (я рекомендую самый дешевый) 1TB трафика в месяц должно хватить

резервируем статический внешний IP

Получив IP4 адрес, сразу закрепляем его за нашим виртуальным сервером.

закрепляем IP4 за нашим виртуальным сервером нажимаем на «Home» и возвращаемся на главный экран

Здесь важный момент (его можно сделать как до настройки сервера, так и позже). Рядом с кнопкой вызова терминала (выделена синим квадратом) нажимаем 3 точки, выбираем Manage затем Networking.

всплывающее меню прописываем входящие порты (по умолчанию 22, 80)

Открываем входящие порты для нашего сервера, добавлю только что 2012 выбран для shadowsocks.

Запускаем терминал и обновляем систему и устанавливаем пакеты (копируем построчно, нажимая enter и отвечая «y«).

терминал откроется в окне браузера ход выполнения

Я не осилил текстовый редактор vi, поэтому установим более простой вариант 🙂

Сохраняем и выходим ctrl+x, на вопрос о сохранении отвечаем «y«.

редактор «nano» обязательно перезагружаем сервер

Перезагружаем сервер: пишем в консоли reboot и нажимаем enter.

Скачиваем SoftEther VPN Client для Windows www.softether.org, устанавливаем оба приложения из списка во время установки.

официальный сайт SoftEther

После установки запускаем SoftEther VPN Server Manager.

создаем новое подключение создаем подключение к нашему удаленному серверу для создание центрального шлюза (для объединения наших сетей) включаем Site-to-site VPN можете поменять имя DDNS (а можем и подключаться по IP) включаем IPsec и L2TP (для совместимости со всем зоопарком устройств) VPN Azure по желанию для пользователя рекомендую оставить авторизацию по паролю больше ничего настраивать ненужно

В главном окне нажимаем «Encryption and Network» Выбираем шифрование для VPN подключений и скачиваем сертификат

главное окно устанавливаем шифрование скачиваем сертификат выбираем тип сертификата сохраняем сертификат включаем NAT нажимаем Enable SecureNAT

На этом настройка сервера полностью завершена, я рекомендую ещё раз перезагрузить свой удаленный сервер.

Устанавливаем сертификат, сертификат нужен на всех устройствах для подключения VPN (Windows: только в «локальный компьютер», по другому не работает SSTP VPN).

Создаём подключение SSTP VPN (Пуск\Параметры\Сеть и Интернет\VPN).

Панель управления\Все элементы панели управления\Сетевые подключения

Внимание: утечка DNS

Или SSL VPN (запускаем SoftEther VPN Client Manager).

Внимание: утечка DNS

Теперь, разные ПК подключённые к вашему VPN серверу, будут находится в одной сети.

Если вам нужен полный доступ между домашней подсетью и подсетью рабочего компьютера, вам понадобиться на рабочий и домашний компьютер установить SoftEther VPN Bridge.

SoftEther VPN Bridge

Бонус (shadowsocks)

Не всегда нужен полноценный VPN, иногда просто хочется безопасно посмотреть котиков в браузере. Для Windows скачиваем https://github.com/shadowsocks/shadowsocks-windows/releases

Shadowsocks Windows (не требует прав администратора)

В браузере Firefox скачиваем расширение FoxyProxy (так же и на Android), настройка: SOCKS5/127.0.0.1/1080

Для Android https://play.google.com/store/apps/details?id=com.github.shadowsocks выбираем только прокси (тогда не будет подниматься VPN канал).

Shadowsocks Android Shadowsocks скорость на провайдер МТС в Санкт-Петербург SSTP VPN (2 устройства в сети) скорость на провайдер МТС в Санкт-Петербурге

Источник

Настройка OpenVPN в bridge с физическим линком

Настройка OpenVPN в bridge с физическим линком это достаточно простая задача, хотя и с парой хитрых моментов, но сначала разберёмся зачем же это может быть надо? Ну во-первых мы можем раздавать пользователям адреса непосредственно из адресного пространства локальной сети предприятия, что в ряде случаев бывает важно. Во-вторых мы можем объединить openvpn-интерфейс в bridge с внешним линком сервера и выдавать клиентам реальные IP-адреса, что позволит например «вывести» наружу сервера, находящиеся в силу каких-то причин за NAT.

Приступим к решению задачи. Мы будем рассматривать установку OpenVPN-сервера на сервере под управленим Debian Squeze и двумя физическими интерфейсами:

Будем настраивать OpenVPN-сервер, который раздаёт клиентам адреса из диапазона 192.168.192.100-192.168.192.150. Установим необходимые пакеты:

Открываем «/etc/network/interfaces» и пишем конфигурацию для br0, предварительно закомментировав конфигурацию для eth1:

Теперь поднимаем br0:

Если на сервере был настроен iptables то во всех правилах надо заменить eth1 на br0, а так же добавить ещё одно правило, разрешающие трафик внутри групп интерфейсов, собранных в bridge:

Приступаем к настройке собственно OpenVPN-сервера. Сперва сгенерируем ключи для OpenVPN-сервера и клиентов точно так, как было описано в этой статье. Далее создадим файл «/etc/openvpn/server.conf», следующего содержания:

Хотя OpenVPN и поддерживает работу с интерфейсами, являющимися частью bridge, но по умолчанию интерфейс находится в состоянии «down» и не добавлен в bridge, по этому создаём ещё скрипт «/etc/openvpn/server_up.sh», который будет выполняться при старте сервера и «доделывать» работу по инициализации схемы:

На клиенте конфигурация будет выглядеть примерно так:

Если вы хотите раздавать реальные IP-адреса то надо настраивать bridge уже для eth0, ну и разумеется запросить у провайдера адреса, которые вы и будете раздавать.

Источник

Для системного администратора

—>
Notice: Undefined variable: t in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15

Notice: Undefined variable: r in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия

Настройка OpenVPN. Бридж между двумя локальными сетями

Задача стояла следующая – объеденить две локальные сети в разных городах в единую 192.168.0.0/24, так чтобы мог функционировать SMB. На обоих концах стояли ADSL-модемы D-Link в режиме роутера. С одной стороны (моего родного города) решено было установить сервер на базе Linux (CentOS), а в другом городе оставить компьютер на WinXP с двумя сетевыми картами, одна из которых подключена к локальной сети 192.168.0.0/24, а другая – к модему-роутеру, подсеть 192.168.1.0/24. IPSec в данном случае не подошел по нескольким причинам:

В итоге решено было остановиться на OpenVPN. Вот некоторые плюсы этого решения:

Настройка сервера

Итак, начнем мы с сервера. Он имеет интерфейсы eth0 с подсетью 192.168.0.0/24, и ppp0 внешнй с неким известным внешним адресом. В качестве операционной системы на нем работает CentOS 5.1. Необходимые для OpenVPN пакеты можно найти в репозитории rpmforge.

После этого устанавливаем OpenVPN:

Сначала мы сгенерируем ключи и сертификаты для сервера и клиента. Для этого, кстати, у нас должен иметься OpenSSL. Проконтролируйте! Удобнее всего это делать с помощью скриптов easy-rsa, которые идут в составе OpenVPN. Найти их можно в /usr/share/doc/openvpn-2.0.9/easy-rsa/ и скопировать весь каталог easy-rsa куда-нибуть в укромное место. Потом стоит пометить там файлы build-ca, build-dh, build-key, build-key-server, clean-all, vars как исполнимые. Остального нам пока что не надо. При желании редактируем файл vars и подставляем туда свои параметры, которые будут использоваться при генерации ключей и сертификатов.

Приступаем к генерации. Выполняем:

Большинство значений скрипт автоматически подставит из файла vars, надо будет только указать Common Name.

Сгенерим ключ для сервера:

В качестве Common Name указываем server. Положительно отвечаем на вопросы “Sign the certificate? [y/n]” и “1 out of 1 certificate requests certified, commit? [y/n]“.

Теперь очередь ключа клиента:

В качестве Common Name указываем все тот же client. Помните, что если вы делаете ключи для нескольких клиентов, то все они должны иметь уникальные имена!

Осталось сгенерить файл с параметрами Diffie-Hellman.

Эта процедура достаточно длительная.

Итак, у нас в каталоге keys имеется множество файлов. Запомните, что все файлы *.key весьма секретны, так что хранить и передавать их надо со всей ответсвенностью.

Теперь надо скопировать файлы ca.crt, dh1024.pem, server.crt, server.key в каталог /etc/openvpn. На всякий случай, надо им так же поставить права в 400.

Начинаем писать конфиг-файл для сервера OpenVPN.

/etc/openvpn/sample.conf

Итак, исходя из строчки server-bridge… сервер у нас будет иметь IP 192.168.0.1, маска подсети 255.255.255.0, а клиенты с 192.168.0.33 до 192.168.0.254.

Осталось разобраться непосредственно с бриджом. Для организации его нам понадобятся утилиты из пакета bridge-utils. Устанавливаем:

Я решил совместить стандартные скрипты bridge-start и bridge-stop из документации OpenVPN со стартовыми скриптами системы. В итоге получились два файла openvpn-startup и openvpn-shutdown, которые надо пометить исполнимыми и засунуть в каталог /etc/openvpn. Сборка OpenVPN в rpmforge будет их запускать автоматически из инит-скриптов. За остальные сборки не знаю. В любом случае, желающие могут придумать альтернативные методы достижения результата.

openvpn-startup

openvpn-shutdown

Осталось разрешить в брандмауэре весь обмен через интерфейсы tap0, br0 и открыть для входящих UDP-соеденений порт 1194 на внешнем интерфейсе.

Настройка windows-клиента

Сначала надо взять OpenVPN GUI for Windows с сайта http://openvpn.se. Скачать необходимо Installation Package (Both 32-bit and 64-bit TAP driver included). Установка проходит совершенно стандартно для этой операционной системы. В процессе будет установлен TAP-драйвер для виртуальной сетевой карты, так что надо ответить утвердительно на соотвествующий вопрос. После установки в списке сетевый подключений появится новое “Подключение по локальной сети”. Его лучше переименовать во что-то более понятное. Например, назвать его “openvpn”. Надо зайти в его “Свойства” – “Свойства TCP/IP” и убедится, что никакие адреса-DNS-ы не прописаны, и определяются автоматически. Теперь приступим к настройке непосредственно OpenVPN. Скопируем в папку C:\Program Files\OpenVPN\config (или куда вы там его поставили?) файлы ca.crt, client.crt, client.key. Там же создаем файл sample.conf следующего содержания.

sample.conf

Далее заходим опять в сетевые подключения, выделяем с помощью клавиши Ctrl два соединения – openvpn и подключение по локальной сети. Из контекстного меню выбираем “Создать мост”. Обратите внимание на то, что в Win2k этого еще сделать нельзя. Все, теперь кликаем правой кнопкой на иконку OpenVPN GUI в трее, выбираем “Connect” и ждем. Должно все получиться 🙂 Если что-либо пойдет не так, то открываем логи и думаем…

Этот пост February 15, 2008 at 11:22 am опубликовал molse в категории Сетевые технологии. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

2 Trackbacks

[. ]Настройка OpenVPN. Бридж между двумя локальными сетями | Для системного администратора[. ]…

Источник

OpenVPN Bridge

Материал из Xgu.ru

На этой странице описывается каким образом можно организовать перенос трафика тегированного с помощью тега 802.1Q поверх уровня IP. Решение этой задачи позволяет сохранить принадлежность трафика VLAN’у даже при переходе через границу сети на канальном уровне, что, в свою очередь, позволяет создавать сети с единым планом VLAN’ов независимо от того сколько сетей канального уровня входит в её состав.

Содержание

[править] Введение

Сейчас практически любая компьютерная сеть сегментируется при помощи VLAN’ов. Это делается по многочисленным причинам, в том числе с целью повышения безопасности сети, её эффективности и управляемости.

VLAN — это группа устройств, имеющих возможность взаимодействовать между собой напрямую на канальном уровне, хотя физически при этом они могут быть подключены к разным сетевым коммутаторам.

Обычно, это верно в случае, если устройства соединены между собой на канальном уровне. Если же устройства соединены между собой только на уровне IP (напрямую или через VPN, не важно), тегированный трафик VLAN не передаётся, и информация о принадлежности пакетов тому или иному VLAN’у теряется.

Такой подход не всегда удобен. Создание независимого множества VLAN’ов для каждой сети приводит к ненужному умножению управляемых сущностей, снижению гибкости и усложнению системы в целом. Например, если в сети используется аутентификация при доступе к сети 802.1X и пользователь попадает в тот или иной VLAN на основе своей учётной записи (подробнее: 802.1X и RADIUS), вы должны думать не только о том, какой пользователь входит в сеть, но ещё и о том, через какой коммутатор он подключается, и в какой из множества сетей этот коммутатор стоит.

Начиная с какого-то масштаба сети и уровня её распределённости усложнение становится настолько сильным, что теряется вся прелесть VLAN’ов.

[править] Задача

Существует две сети, соединённые на IP-уровне между собой. Необходимо сделать так чтобы между этими сетями мог прозрачно передаваться трафик, тегированный с помощью тега 802.1Q так как если бы это была большая коммутируемая сеть.

[править] Решение

Указанную задачу можно решить с помощью различных средств построения туннелей, в частности vtun и OpenVPN. Ниже описывается решение задачи с помощью OpenVPN.

Здесь есть несколько машин, соединённых в цепочку с помощью коммутаторов.

В качестве операционной системы используется Debian GNU/Linux. Рассматриваемая последовательность действий будет работать и и в других дистрибутивах Linux. В FreeBSD принципиальных отличий нет, но некоторые команды отличаются (настройка мостов и VLAN’ов).

Необходимо сделать так чтобы машина debian1 видела машину debian5 так как будто они находятся с ней в одной коммутируемой сети. Если трафик, передающийся в этой сети тегирован, теги должны сохранятся. Другими словами, если вместо машины debian1 будет коммутатор с настроенными на нём VLAN’ами, который будет смотреть на debian2 тегированным портом (и точно такая же ситуация будет с противоположной стороны), то компьютеры находящиеся в одном VLAN’е будут прекрасно видеть друг друга, независимо от того, в какой части сети они находятся.

[править] Программное обеспечение

Для выполнения процедуры потребуется установить программное обеспечение.

На debian2 и debian4:

На debian1 и debian5:

[править] Настройка OpenVPN

(здесь предполагается, что 192.168.2.2 — IP-адрес машины debian2 в условном Интернете)

Как и следовало ожидать, для поднятия туннеля и его использования в режиме моста, IP-адреса не нужны.

После того как туннель поднят

[править] Настройка виртуальных мостов

Необходимо создать мосты на обеих машинах (debian2 и debian4), и включить все необходимые интерфейсы.

[править] Проверка

Теперь машины debian1 и debian5 видят друг друга, так как если бы они находились в одной сети.

С машины debian1 можно пингануть машину debian5 и проследить маршрут:

Трассировка показала, что debian5 находится с debian1 в одной коммутируемой сети.

Мы также можем передавать тегированный трафик.

Источник

Прокладываем L2 туннели в OpenVPN

Недавно меня попросили разобраться в настройке L2 туннеля для моста между двумя удалёнными локальными сетями, и я был поражён, насколько мало удобных решений мне удалось найти. Раньше я не интересовался этой темой и наивно полагал, что любой адекватный VPN-протокол умеет ловить широковещательные пакеты и пересылать их по обычному L3 туннелю. К сожалению, доступных «из коробки» универсальных решений нет. Есть несколько протоколов и инструментов для них, большинство из которых работает в очень ограниченных условиях или вовсе объявлено deprecated. Самым приятным вариантом я поделюсь дальше.

Почему именно L2?

Этим вопросом я задался в первую очередь: я довольно редко работаю с сетевой периферией, и мне казалось что довольно давно уже всё оборудование умеет ходить по L3. Как бы не так: кому-то нужен доступ к офисным принтерам, кому-то к видеорегистраторам, а кто-то просто хочет зарубиться с другом в LAN-дуэли — не выходя из дома, разумеется. Также очень привлекательной выглядит идея общих/сетевых папок в офисе, доступных из дома, особенно в период повальной удалёнки.

При этом среди разработчиков VPN-клиентов L2-бриджи почему-то считаются чем-то вроде странного каприза одного-двух процентов пользователей, который по большому счёту никому не нужен. Совсем иначе обстоят дела в промышленных сетях, где много устаревшего или плохо совместимого оборудования, и концепция L2VPN (представленная кучей других аббревиатур) реализована на уровне сети и оборудования провайдера.

Технологии

Их много, и они все работают со странностями и ограничениями:

Мы часто пользуемся личным или рабочим VPNом, у многих он вообще включён на постоянной основе для обхода блокировок (хотя эта тенденция идёт на спад после снятия блокировки Telegram). В своих рабочих задачах я тоже постоянно пользуюсь удаленными хостами для разработки, и почти всегда использую OpenVPN. Долгое время я не понимал, зачем нужна связка OpenVPN Access Server + OpenVPN Connect на клиенте. Для моих задач мне всегда хватало классической версии с ручной правкой конфигов, и выделенные админки и GUI казались неуместными в стройном тонком клиенте. Но оказалось, что для настройки бриджа интерфейс гораздо удобнее чем простыни конфигов в терминале, хотя и с ним не всё идеально.

Настройка

Дело в том, что Access Server (AS) выходил как платный и довольно дорогой продукт, поэтому в него старательно напихали всевозможных плюшек, лишь бы купили. Таким образом в веб-админке появился подпункт меню, позволяющий выбрать режим сети (L2 bridging/L3 routing), а через какое-то время тихонько был оттуда выпилен по всё той же причине «это никому не нужно». Тем не менее, сам функционал бриджинга и соответствующие скрипты не удаляли и их по-прежнему можно настроить.

Установка

Нам потребуется сервер или виртуальная машина. Образ для неё находится на странице загрузки, а мы будем дальше разбирать кейс с установкой на сервер под Ubuntu 18.04:

После установки сервер поднимется самостоятельно, вы увидите такое сообщение:

Сразу нужно указать пароль для админской учётки:

Затем можно открывать админку в браузере (на :943/admin, как указано выше), логиниться под пользователем openvpn с указанным паролем и настраивать сервер.

Возвращаем бриджинг

Если всё прошло успешно, в выведенном json’е будет такое:

В админке статус «OSI Layer: 3 (routing/NAT)» поменяется на «2 (bridging)»

NB: в последних версиях может оставаться информация о L3 при включённом bridge. Почему — не разбирался, безопасные в этом плане версии около 2.4

Собственно на этом ноу-хау заканчивается, дальше вам нужно просто настроить под себя сервер, завести второго пользователя через тот же веб-интерфейс и залогиниться на пользовательскую страницу на 943 порту (без /admin). Там будут ссылки на скачивание клиентов OpenVPN Connect под все платформы с запечённым конфигом для подключения (кроме мобильных приложений, там придется вбить адрес вручную, а дальше всё само установится).

После успешного подключения и бриджевания клиентов, будет доступен L2-туннель с TCP/UDP трафиком. Клиенты могут выступать натом для внутренней сети, это всё тоже настраивается в админке.

Источник