Openvpn windows объединение двух сетей

📹 ВИДЕО: Как настроить OpenVPN соединение 2 офисов (конфиг сервера и клиента), сетевые папки Windows 💻↔️🖥️

👍 Смотрите как настроить OpenVPN сервер на Windows и сконфигурировать OpenVPN клиента. А также, как организовать с его помощью каналы между удалёнными офисами. Бывает, что необходимо построить связь между удалёнными компьютерами без лишних затрат на оборудование и ПО. В этом поможет такая бесплатная и известная программа, как OpenVPN — свободная реализация технологии виртуальной частной сети (VPN).

Видео о том, как создать VPN сервер на компьютере средствами встроенных в Windows инструментов и подключится к нему с другого ПК, уже есть на нашем канале. Ссылку на него оставляю в описании: https://www.youtube.com/watch?v=ZTnkEdggzPg

Случайное удаление файлов, форматирование диска, вирусная атака, системный сбой или ошибка файловой системы — это не полный список проблем, которые решают программы компании Hetman Software: https://hetmanrecovery.com/ru/ .

Итак, у нас есть два компьютера. Один из них будет использован как OpenVPN сервер. Второй – как клиент. Нам нужно обеспечить им возможность видеть друг друга в сети, через интернет, а также иметь возможность пользоваться общими сетевыми (расшаренными) папками и файлами.

Конфигурационный файл сервера:

proto tcp4-server
dev tun
tls-server
tls-auth «C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ta.key» 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ca «C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt»
cert «C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ServerVPN.crt»
key «C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ServerVPN.key»

dh «C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\dh4096.pem»
server 10.10.10.0 255.255.255.0
client-to-client
keepalive 10 120
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
client-config-dir «C:\\Program Files\\OpenVPN\\config»
verb 3
route-delay 5
route-method exe
push «route 192.168.0.0 255.255.255.0»
route 192.168.182.0 255.255.255.0

Конфигурационный файл клиента на сервере:

ifconfig-push 10.10.10.5 10.10.10.6
iroute 192.168.182.0 255.255.255.0
# disable

Конфигурационный файл клиента:

remote 176.122.115.66
client
port 12345
proto tcp4-client
dev tun
tls-client
tls-auth «C:\\Program Files\\OpenVPN\\config\\ta.key» 1
remote-cert-tls server
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

ca «C:\\Program Files\\OpenVPN\\config\\ca.crt»
cert «C:\\Program Files\\OpenVPN\\config\\ClientVPN.crt»
key «C:\\Program Files\\OpenVPN\\config\\ClientVPN.key»
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
verb 3
mute 20

Вот и всё. Как видим VPN подключение с помощью OpenVPN создано. Компьютеры могут подключаться в двух направлениях.

Ставьте лайк и подписывайтесь на канал Hetman Software. Задавайте интересующие вопросы в комментариях. Всем спасибо за просмотр. Всем пока.

Другие видео: #OpenVPN, #OpenVPNСервер, #OpenVPNКлиент, #VPNподключение, #WindowsVPN, #Windows10, #ВиртуальнаяСеть.

Источник

Переход с OpenVPN на WireGuard для объединения сетей в одну сеть L2

Хотел бы поделиться опытом объединения сетей в трех географически удаленных квартирах, в каждой из которых в качестве шлюза используются роутеры с OpenWRT, в одну общую сеть. При выборе способа объединения сетей между L3 с маршрутизацией подсетей и L2 с бриджингом, когда все узлы сети будут находиться в одной подсети, было отдано предпочтение второму способу, более сложному в настройке, но дающим бОльшие возможности, так как в создаваемой сети планировалось прозрачное использование технологий Wake-on-Lan и DLNA.

Часть 1: Предыстория

В качестве протокола для реализации этой задачи изначально был выбран OpenVPN, так как, во-первых, он может создавать устройство tap, которое без проблем добавляется в мост, а во-вторых, OpenVPN поддерживает работу по протоколу TCP, что было также немаловажно, ведь ни в одной из квартир не имелось выделенного IP-адреса, а использовать STUN мне не удалось, так как мой провайдер почему-то блокирует входящие подключения по протоколу UDP из своих сетей, в то время как протокол TCP позволял мне пробросить порт VPN-сервера на арендуемый VPS при помощи SSH. Да, такой подход дает большую нагрузку, так как данные шифруются дважды, но вводить VPS в свою частную сеть я не захотел, так как оставался риск получения третьими лицами контроля над ним, следовательно, иметь в домашней сети такое устройство являлось крайне нежелательным и было решено заплатить за безопасность большим оверхедом.

Для проброса порта на роутере, на котором планировалось развернуть сервер, была использована программа sshtunnel. Описывать тонкости ее конфигурации не буду — это делается достаточно легко, просто отмечу, что ее задачей был проброс TCP-порта 1194 с роутера на VPS. Далее был настроен сервер OpenVPN на устройстве tap0, которое заводилось в мост br-lan. Проверив подключение к только что созданному серверу с ноутбука — стало понятно, что идея с пробросом порта себя оправдала и мой ноутбук стал членом сети роутера, хотя физически в ней не находился.

Дело оставалось за малым: нужно было распределить IP-адреса в разных квартирах так, чтобы они не конфликтовали и настроить маршрутизаторы в качестве OpenVPN-клиентов.
Были выбраны такие IP-адреса маршрутизаторов и диапазоны DHCP-серверов:

192.168.10.1 с диапазоном 192.168.10.2 — 192.168.10.80 для сервера
192.168.10.100 с диапазоном 192.168.10.101 — 192.168.10.149 для маршрутизатора в квартире №2
192.168.10.150 с диапазоном 192.168.10.151 — 192.168.10.199 для маршрутизатора в квартире №3

Также было необходимо назначить именно эти адреса для маршрутизаторов-клиентов OpenVPN-сервера, путем добавления в его конфигурацию строчки:

и добавлением следующих строк в файл /etc/openvpn/ipp.txt:

где flat1_id и flat2_id — это имена устройств, указываемые при создании сертификатов для подключения к OpenVPN

Далее на роутерах были настроены OpenVPN-клиенты, устройства tap0 на обоих были занесены в мост br-lan. На этом этапе казалось, что все в порядке, так как все три сети видят друг друга и работают как единое целое. Однако, выяснилась не очень приятная деталь: иногда устройства могли получить IP-адрес не от своего маршрутизатора, со всеми вытекающими последствиями. По какой-то причине, маршрутизатор в какой-то из квартир не успевал ответить вовремя на DHCPDISCOVER и устройство получало не свой адрес. Я понял, что мне нужно отфильтровать такие запросы в tap0 на каждом из маршрутизаторов, но, как выяснилось, iptables не может работать с устройством, если оно является частью моста и мне на помощь должен прийти ebtables. К моему сожалению, в моих прошивках его не оказалось и пришлось пересобирать образы для каждого устройства. Сделав это и добавив такие строки в /etc/rc.local каждого маршрутизатора проблема была решена:

Такая конфигурация просуществовала на протяжении трех лет.

Часть 2: Знакомство с WireGuard

В последнее время в Интернете все чаще стали говорить о WireGuard, восхищаясь простотой его конфигурации, высокой скоростью передачи, низким пингом при сопоставимой безопасности. Поиск дополнительной информации о нем давал понять, что ни работа в качестве члена моста, ни работа по протоколу TCP им не поддерживается, что наводило меня на мысли о том, что альтернатив OpenVPN для меня по-прежнему нет. Так я откладывал знакомство с WireGuard.

Несколько дней назад по ресурсам, так или иначе связанным с IT, пролетела новость о том, что WireGuard наконец будет включен в ядро Linux, начиная с версии 5.6. Новостные статьи, как всегда, хвалили WireGuard. Я вновь погрузился в поиски путей замены старого доброго OpenVPN. На этот раз я напоролся на эту статью. В ней говорилось о создании Ethernet-туннеля поверх L3 при помощи GRE. Эта статья вселила в меня надежду. Оставалось неясно что делать с протоколом UDP. Поиск приводил меня к статьям об использовании socat в связке с SSH-туннелем, для проброса UDP-порта, однако, в них отмечалось, что такой подход работает только в режиме одного соединения, то есть работа нескольких VPN-клиентов оказалась бы невозможной. Мне пришла идея поднять VPN-сервер на VPS, а для клиентов настроить GRE, но, как оказалось, GRE не поддерживает шифрование, что приведет к тому, что в случае получения доступа к серверу третьими лицами, в их руках оказывается весь трафик между моими сетями, что меня не устраивало в принципе.

Вновь было принято решение в пользу избыточного шифрования, путем использования VPN поверх VPN по следующей схеме:

VPN первого уровня:
VPS является сервером с внутренним адресом 192.168.30.1
МС является клиентом VPS с внутренним адресом 192.168.30.2
МК2 является клиентом VPS с внутренним адресом 192.168.30.3
МК3 является клиентом VPS с внутренним адресом 192.168.30.4

VPN второго уровня:
МС является сервером с внешним адресом 192.168.30.2 и внутренним 192.168.31.1
МК2 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.2
МК3 является клиентом МС с адресом 192.168.30.2 и имеет внутренний IP 192.168.31.3

* МС — маршрутизатор-сервер в квартире 1, МК2 — маршрутизатор в квартире 2, МК3 — маршрутизатор в квартире 3
* Конфигурации устройств опубликованы в спойлере в конце статьи.

И так, пинги между узлами сети 192.168.31.0/24 ходят, пора перейти к настройке GRE-туннеля. Перед этим, дабы не терять доступ к маршрутизаторам, стоит настроить SSH-туннели для проброса 22 порта на VPS, таким образом, что, например, на 10022-ом порту VPS будет доступен маршрутизатор из квартиры 2, а на 11122-порту VPS будет доступен маршрутизатор из квартиры 3. Настройку проброса лучше всего выполнить все тем-же sshtunnel, так как он восстановит туннель в случае его падения.

Туннель настроен, можно подключаться к SSH через проброшенный порт:

Далее следует отключить OpenVPN:

Теперь настроим GRE-туннель на маршрутизаторе из квартиры 2:

И добавим созданный интерфейс в мост:

Аналогичную процедуру выполним на маршрутизаторе-сервере:

И, также, добавим созданный интерфейс в мост:

начиная с этого момента пинги начинают успешно ходить в новую сеть и я, с удовлетворением отправляюсь пить кофе. Затем, чтобы оценить, как работает сеть на другом конце провода, я пытаюсь подключиться по SSH к одному из компьютеров в квартире 2, но ssh-клиент «зависает», не предлагая ввести пароль. Пробую подключиться к этому компьютеру по telnet на 22 порт и вижу строку, из которой можно понять, что соединение устанавливается, SSH-сервер отвечает, просто по какой-то причине не предлагает мне войти.

Пытаюсь подключиться к нему же по VNC и вижу черный экран. Я убеждаю себя, что дело в удаленном компьютере, ведь к маршрутизатору из этой квартиры я спокойно могу подключиться по внутреннему адресу. Однако, я решаю подключиться к SSH этого компьютера через маршрутизатор и с удивлением обнаруживаю, что подключение удается, а удаленный компьютер работает вполне штатно, но при этом также не может подключиться к моему компьютеру.

Я вывожу устройство grelan0 из моста и запускаю OpenVPN на маршрутизаторе в квартире 2 и убеждаюсь, что сеть вновь работает как положено и соединения не обрываются. Поиском натыкаюсь на форумы, где люди жалуются на такие же проблемы, где им советуют поднять MTU. Однако, повысить MTU для VPN первого уровня (wg0) мне не удалось: при MTU выше 1420, который выставляется автоматически, начинаются обрывы, но при этом, VPN второго уровня wg1, работающий поверх wg0, корректно работал с MTU 1600. Этого достаточно для установки MTU в 1500 для устройства gretap, для того чтобы этот интерфейс имел то же значение MTU, что и мост br-lan, в который планировалось добавить gretap. Насколько я понял, мост выставляет MTU равное меньшему из доступных значений на всех устройствах.

Провел аналогичную настройку и на маршрутизаторе из квартиры 3, с той лишь разницей, что на маршрутизаторе сервере добавился второй интерфейс gretap с именем grelan1, который также был добавлен в мост br-lan.

Все работает. Теперь можно поместить сборку gretap в автозагрузку. Для этого:

Поместил эти строки в /etc/rc.local на маршрутизаторе в квартире 2:

Добавил это в /etc/rc.local на маршрутизаторе в квартире 3:

И на маршрутизаторе-сервере:

После перезагрузки клиентских роутеров я обнаружил, что они по какой-то причине не подключаются к серверу. Подключившись к их SSH (благо, я предварительно настроил sshtunnel для этого) было обнаружено, что WireGuard зачем-то создает маршрут для endpoint, при этом неверный. Так, для 192.168.30.2 в таблице маршрутов был указан маршрут через интерфейс pppoe-wan, то есть через интернет, хотя маршрут до него должен был быть направлен через интерфейс wg0. После удаления этого маршрута соединение восстановилось. Найти где-то инструкций о том, как заставить WireGuard не создавать этих маршрутов мне не удалось. Более того, я даже не понял, особенность это OpenWRT, либо самого WireGuard. Не став долго разбираться с этой проблемой, я просто добавил на оба роутера в скрипт, зацикленный по таймеру, строку удалявшую этот маршрут:

Подводя итоги

Полного отказа от OpenVPN я пока не добился, так как мне нужно иногда подключаться к новой сети с ноутбука, либо телефона, а настройка gretap устройства на них в общем случае невозможна, но, несмотря на это, я получил преимущество в скорости передачи данных между квартирами и, например, использование VNC теперь не доставляет неудобств. Пинг уменьшился незначительно, но стал более стабильным:

При использовании OpenVPN:

При использовании WireGuard:

На него в большей степени влияет высокий пинг до VPS, который составляет примерно 61.5 мс

Однако, скорость увеличилась значительно. Так, в квартире с маршрутизатором-сервером я имею скорость подключения к Интернету 30 мбит/сек, а в остальных квартирах по 5 мбит/сек. При этом, во время использования OpenVPN мне не удавалось достичь скорости передачи данных между сетями больше 3,8 мбит/сек по показаниями iperf, в то время как WireGuard «прокачал» ее до тех же 5 мбит/сек.

[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey =

[Peer]
PublicKey =
AllowedIPs = 192.168.30.2/32

[Peer]
PublicKey =
AllowedIPs = 192.168.30.3/32

[Peer]
PublicKey =
AllowedIPs = 192.168.30.4/32

В описанных конфигурациях для VPN второго уровня я указываю клиентам WireGuard порт 51821. По идее это не нужно, так как клиент установит соединение с любого свободного непривилегированного порта, но я сделал так, чтобы можно было запретить все входящие соединения на интерфейсах wg0 всех маршрутизаторов, кроме входящих UDP-соединений на порт 51821.

Надеюсь, что статья будет кому-то полезна.

P.S. Также, хочу поделиться своим скриптом, который шлет мне PUSH-уведомление на телефон в приложение WirePusher, когда в моей сети появляется новое устройство. Вот ссылка на скрипт: github.com/r0ck3r/device_discover.

UPDATE: Конфигурация OpenVPN-сервера и клиентов

Для генерации сертификатов использовал easy-rsa