Vpn тоннель полное объединение сетей windows. Не совсем обычное VPN соединение обычными средствами

Разобравшись в с общими вопросами, сегодня мы рассмотрим варианты построения виртуальных сетей и тесно связанную с ними тему маршрутизации. Так как именно этот вопрос вызывает наибольшее количество затруднений у системных администраторов. Правильно выбранная структура сети и настроенная согласно этой структуры маршрутизация залог того, что ваша сеть будет работать именно так, как вы хотите.

Что такое маршрутизация? Не вдаваясь в долгие объяснения можно сказать, что это набор правил определяющих маршрут следования информации в сетях связи. Можно привести хорошую аналогию с дорожными знаками и разметкой.

Представьте себе чужой город и полное отсутствие каких либо указателей, знаков и разметки на оживленном перекрестке. Здесь есть от чего впасть в ступор. Также и в сетях. Любые сетевые пакеты направляются согласно набора правил - таблицы маршрутизации. Благодаря им документ посланный на печать уйдет именно на сетевой принтер, а электронная почта будет доставлена адресату в сети интернет.

Необходимость настройки маршрутов возникает когда вы хотите использовать VPN соединение для работы удаленных клиентов в корпоративной сети или объединяя сети филиалов. Иначе каким образом пакет определит, что ему надо именно через туннель попасть в вашу корпоративную сеть. Вы же не отсылаете письма с адресом "На деревню дедушке"?

Существует несколько вариантов построения виртуальной сети, каждый из них предусматривает свою схему маршрутизации. Рассмотрим их подробнее.

Клиенты получают адреса из диапазона локальной сети.

Данный вариант требует поддержки со стороны сервера Proxy ARP , который позволяет объединить две не связанные на канальном уровне сети в одну. Все хосты будут "считать" что находятся в одной физической сети и обмениваться трафиком без какой либо дополнительной маршрутизации.

К достоинствам такого варианта относится простота реализации и полный доступ удаленных клиентов к ресурсам сети. Однако безопасность этого решения крайне низка и требует высокого уровня доверия к удаленным клиентам, потому как практически невозможно разграничить доступ к ресурсам между клиентами локальной сети и VPN клиентами.

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

Этот вариант предусматривает выделение удаленных клиентов в отдельную подсеть, в нашем случае это 10.0.1.0/24. Как нетрудно заметить обе подсети могут быть частью общей сети 10.0.0.0/23. Мы можем управлять структурой сети двумя способами: при помощи маски подсети или маршрутизации. Первый вариант позволяет переместив ПК в сеть 10.0.0.0/23 (изменив маску с 255.255.255.0 на 255.255.254.0) дать ему доступ к обеим подсетям.

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

Для доступа клиентских ПК из одной подсети в другую нам потребуется прописать на них статические маршруты. Мы будем использовать запись вида:

X.X.X.X mask Y.Y.Y.Y Z.Z.Z.Z

где X.X.X.X сеть, Y.Y.Y.Y маска сети, Z.Z.Z.Z шлюз. Добавить маршрут в среде Windows можно командой:

Route add X.X.X.X mask Y.Y.Y.Y Z.Z.Z.Z

Route add -net X.X.X.X netmask Y.Y.Y.Y gw Z.Z.Z.Z

Действие данных команд сохраняется до перезагрузки и поэтому если вы что-то сделали не так, перезагрузите ПК и попробуйте снова. Убедившись что все работает нужно добавить маршруты на постоянной основе. В Windows это делается добавлением к команде ключа -p:

Route add X.X.X.X mask Y.Y.Y.Y Z.Z.Z.Z -p

В Ubuntu потребуется добавить в файл /etc/network/interfaces, после описания интерфейса, строки:

Up route add -net X.X.X.X netmask Y.Y.Y.Y gw Z.Z.Z.Z

Вернемся к нашим маршрутам. Для доступа удаленных клиентов в нашу локальную сеть необходимо прописать маршрут к ней:

10.0.0.0 mask 255.255.255.0 10.0.1.1

И наоборот, для доступа из локальной сети к удаленным клиентам, если такой необходимости нет, данный маршрут можно не прописывать:

10.0.1.0 mask 255.255.255.0 10.0.0.1

Клиенты получают адреса из диапазона который не маршрутизируется из локальной сети.

Данная схема обычно не предусматривает маршрутизацию из локальной сети в удаленную и применяется для подключения клиентов с низкой степенью доверия (заказчики, дилеры и т.п.). При такой реализации удаленным клиентам доступны только ресурсы опубликованные в VPN, для доступа к локальной сети одного указания маршрута (как в предыдущем случае) будет недостаточно, потребуется еще настройка сервера на трансляцию пакетов (NAT) из локальной сети в удаленную и наоборот.

Опубликовать ресурс в VPN можно несколькими способами: разместить его на VPN сервере и разрешить доступ к нему из удаленной сети, пробросить в удаленную сеть нужный порт или подключить нужный ресурс в качестве клиента удаленной сети. На нашей схеме мы опубликовали подобным образом терминальный сервер 10.0.0.2, который будет доступен в удаленной сети по адресу 172.16.0.2

Объединение двух подсетей

Данная схема применяется для объединения нескольких подсетей (центрального офиса и филиалов) в единую сеть, структура такой сети более сложна, но при понимании того, какие пакеты и через какие интерфейсы нам необходимо направлять все очень быстро становиться на свои места. В нашем случае X.X.X.X выделенный IP адрес в центральном офисе, филиалы могут иметь серые IP адреса. На роутере центрального офиса расположен VPN сервер, роутер филиала подключается как клиент.

Теперь разберемся с маршрутизацией. Клиенты подсети LAN1 должны передавать пакеты к подсети LAN2 на шлюз роутера, который в свою очередь должен передать их на другой конец VPN туннеля. Для подсети LAN2 потребуется аналогичная маршрутизация, только в обратном направлении.

Поэтому на клиентах подсети LAN1 прописываем маршрут к LAN2.

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

Постановка задачи: Получить доступ к узлам удалённой сети.

Здесь мы будем говорить о двух сетях, которые нужно объединить, одну из которых я буду называть «моя офисная сеть», а другую «удалённая сеть».
Системный администратор удалённой сети отказывается вносить наименьшие изменения, для подключения и единственное что можно сделать - это поместить своё оборудование в удалённой сети. Выход в интернет из этой сетиv4 производится через шлюз, который натит в мир. Нужно построить тоннель, между двумя офисами, чтобы узлы моей офисной сети могли получать доступ к узлам удалённой сети, при минимальных изменениях c обеих сторон.

Для выполнения задачи объединения двух сетей и построения виртуального тоннеля нужно использовать Virtual Private Network. В ходе поиска подходящего варианта подключения, для себя разделил VPN на два вида: клиент-серверный вариант и равноправный. В следующих моментах заключается принципиальное отличие:

В равноправном VPN, использующем глобальную сеть интернет, нужно иметь один реальный IP адрес, для каждого из узлов (минимум 2-ва узла). Здесь соединение может быть инициировано каждой из сторон (именно поэтому я так и обозвал его, равноправный), их может быть больше двух.
В клиент-серверном варианте, использующем глобальную сеть интернет, нужен только один реальный IP адрес, для сервера. Соединение здесь происходит по требованию клиента, сервер всегда ожидает, клиентов может быть больше одного.

Примечание1: В обоих вариантах должно соблюдается одно из условий (для клиент-серверного варианта, только для сервера):

A. VPN peer, должен находится непосредственно на шлюзе (должно быть установлено дополнительное ПО, или устройство должно быть способно устанавливать нужный тип VPN соединений).
B. Если же нет возможности запустить VPN peer непосредственно на шлюзе, нужно его сконфигурировать так, чтобы он смог пропускать порт на другое устройство, настроенное как VPN peer.

Примеры VPN протоколов:

Клиент-серверный VPN:

PPTP;
L2TP;
OpenVPN;
PPPoE;

Равноправный VPN:

IPSec;

Таким образом, становится очевиден выбор варианта - Клиент-серверный VPN . Так как менять со стороны клиента ничего не нужно в этом варианте.

Какой же из клиент-серверных вариантов выбрать?

И первое что приходит на ум - старый добрый PPTP. Недостатков в плане безопасности у него полно, хотя существуют его более продвинутые, новые, версии. Не смотря на огрехи в плане безопасности, у PPTP есть ещё одна очень не приятная особенность - это протокол GRE, используемый PPTP клиентом для установления соединения с сервером. В случае установки связи по схеме указанной в Примечании1.B оборудование которое производит перенаправление порта (Port Forwarding) должно уметь пропускать соединение по протоколу PPTP (Часто расположен в секции Application Level Gateway) через себя (Функция часто называется pass through PPTP, что с английского так и переводится пропустить PPTP через себя). Это связано с особенностями протокола и тем, что изначально PPTP не был рассчитан на работу через NAT. Если такой функции нет, то в этой схеме VPN канал установлен не будет по той простой причине, что сервер не увидит входящего запроса на соединение.
PPPoE, L2TP и PPTP использует далёкие от совершенства протоколы авторизации pap, chap, mscap1 и mscap2.

К счастью протокол OpenVPN лишен большинства выше перечисленных недостатков, не использует протокол GRE и был специально разработан с учётом особенностей сетей использующих NAT.
Немного об Open VPN: Работает на порту 1194, может использовать как TCP так и UDP протоколы. Протокол уровня приложения, по модели OSI.
Таким образом, выбор из этих протоколов стал тоже очевиден - OpenVPN . Конечно же, он не идеален и не панацея, но для этого случая подойдёт наилучшим образом.

Немного подрезюмируем.

Будем использовать OpenVPN сервер со стороны моей офисной сети (где я могу что-то менять, по большому счёту могу всё менять, просто не хочу) будет сервер, а со стороны удалённой сети будет клиент. Для того, чтобы сильно не менять схему своей офисной сети, в которой фаервол является аппаратным устройством (и у которого нет встроенного OpenVPN сервера), нужно поставить за ним устройство с OpenVPN сервером и пробросить на него порт 1194.
Теперь мы представляем, как будет устанавливаться связь между клиентом и сервером, но как узлы сети моего офиса смогут видеть узлы удалённой сети?
Чтобы не вносить изменения в маршруизаторы удалённой сети будем скрывать сеть моего офиса НАТом. Со стороны моего офиса, на маршрутизаторе, запишем маршрут, к удалённой сети через ВПН тоннель.
Недостатком маскирования, в данном случае, может стать, не возможность получения доступа узлов удалённой сети к узлам моего офиса, что в данном случае, скорее, преимущество.

Созревшая схема.

На схеме красным цветом отображен тоннель установленный клиентом к серверу, чёрным пунктиром отображен маршрут пакета от узла из моего офиса к узлу из удалённого офиса через тоннель.

На прокси-сервере 192.168.0.1-192.168.100.3 были добавлены маршруты:
Route 10.0.0.0/8 192.168.100.2
Route 192.168.1.0/30 192.168.100.2

Здесь мы заворачиваем все пакеты, адресованные сети 192.168.1.0/30 и 10.0.0.0/8 на маршрутизатор 192.168.100.2-192.168.1.1. На этом же маршрутизаторе работает OpenVPN Server. Все пакеты по умолчанию пересылаются в интернет через шлюз 192.168.100.1-Real_1, а для сети 10.0.0.0/8 пересылаются через виртуальный канал, построенный в сети интернет на OpenVPN Client 192.168.1.2-10.1.1.2.

Для нормальной работы OpenVPN Server"а на шлюзе 192.168.100.1-Real_1 проброшен на него порт 1194.
На OpenVPN Client"е прописан адрес из удалённой подсети 10.1.1.2. Шлюз по умолчанию для него 10.1.1.1. Клиент устанавливает связь в интернет через реальный IP адрес Real_1. Для сети 192.168.100.0/24 прописан маршрут через 192.168.1.1-192.168.100.2 для того чтобы пакеты пришедшие из моего офиса благополучно вернулись обратно. Здесь же, на клиенте, установлено правило в файерволе (таблица NAT): пакеты, пришедшие из сети 192.168.100.0/24, маскируются (masquerading) под адрес из этой подсети (10.1.1.2).

Теоретическая проверка прохождения пакетов

Так пакеты из моей сети будут попадать в удалённую сеть и обратно в соответствии с правилами:
Пакеты, посланные узлом 192.168.0.123 из моего офиса в удалённую сеть 10.0.0.0/8 на узел 10.0.0.123 будут замаскированы шлюзом 192.168.0.1-192.168.100.3 под адрес 192.168.100.3 и по правилу направятся в маршрутизатор 192.168.100.2-192.168.1.1, откуда они перенаправятся через адрес 192.168.1.1 на адрес маршрутизатора 192.168.1.2-10.1.1.2, где они снова будут замаскированы под адрес 10.1.1.2, откуда благополучно дойдут до адресата 10.0.0.123. Адрес 10.0.0.123 пошлёт ответ 10.1.1.2-192.168.1.2, который отошлёт ответ с адреса 192.168.1.2 на адрес 192.168.1.1-192.168.100.2, который вернёт пакет с адреса 192.168.100.2 серверу 192.168.100.3-192.168.0.1, который передаст пакет обратно 192.168.0.123 с адреса 192.168.0.1.
Эта подробная процедура прослеживания прохождения пакетов понадобилась для того чтобы удостоверится, что все настройки были сделаны правильно и ничего не было пропущено.

Какое оборудование выбрать в качестве OpenVPN сервера и клиента?

Можно использовать обычный компьютер с установленной системой *nix и пакетом ПО OpenVPN.
А можно использовать специализированное оборудование. Так сложилось, что у меня были два Mikrotik RB450.

Настройка RB450 или почему я не тестировал PPTP.

Дело в том, что первый раз я пытался тестировать всё на PPTP, но клиент не мог установить связь с сервером, хотя с компьютера под Windows установить связь было возможно.

Обновление Mikrotik RB450 с версии 3.22 на 4.20:

Только с версии 3.25 или выше можно обновляться до 4.20, так написано на официальном сайте www.mikrotik.com/download.html#2.php .
Поэтому в разделе загрузки выбираем нашу систему, а в разделе Software выбираем Legacy. Здесь я выбрал последний релиз 3.30, который без лишних вопросов ставится поверх 3.22:
Делал по аналогии со статьей www.asp24antenna.com.ua/obnovlenie-s-328-os-na-routeros-40 .
Открываем WinBOX заходим в files, перетягиваем туда файл прошивки 3.30, перезагружаемся и ждём двойного пика - всё прошивка уже стоит. Потом заходим в System>License и жмём обновить (роутер должен быть в это время подключён к сети интернет с настроенным DNS). После обновления снова скачиваем только уже новую прошивку и кидаем её в роутер, перезагружаемся - всё у нас самая новая прошивка! Провозился с обновлением обоих микротиков RB450 с версии 3.22 на 3.30 а потом на 4.20, но это не помогло и никак не исправило ситуации с PPTP:(

Решил строить сразу на OpenVPN.

По руководству этой стати wiki.mikrotik.com/wiki/OpenVPN я создал сертификаты и импортировал их. За подробностями обращайтесь к указанной статье. Опишу только ключевые моменты или те, которые вызывали трудности.
Создал аккаунт на CAcert.org , хотя это вовсе не обязательно, можно выдать самоподписанный сертификат.
На роутере, который будет OpenVPN server"ом, выполняем команды:

/certificate create-certificate-request
#Обязательно заполнить следующие поля:
passphrase:
(Your name) common name:

#Мы получим два файла
certificate-request.pem
private-key.pem

Открываем файл certificate-request.pem копируем его содержимое (скопировать на компьютер, к примеру, по FTP или перетяните на рабочий стол из WinBOX"а) и вставляем в форму на сайте CAcert.org (нужна регистрация) Server Certificates>New, полученный ответ копируем в файл certificate-response.pem (нужно залить на OpenVPN server).
Теперь импортируем сертификаты в WinBOX:

System> Certificates> Import
сначала добавим certificate-response.pem
потом private-key.pem

После чего у добавляемого сертификата появится пометка KR. Если вместо неё вы видите QR, импортируйте private-key.pem ещё раз (мне помогло).
Теперь приступаем к созданию сервера (не забудьте поменять под свои нужды):

/ interface ethernet
set ether1 name="ether1"
#Этого можно и не делать

/ interface bridge
add name="lan" arp=proxy-arp
#Внимание, этот аргумент важен arp=proxy-arp!

/ interface bridge port
add interface=ether1 bridge=lan

/ ip address
add address=192.168.1.1/24 interface=lan
#Это адрес сервера

/ ip pool
add name="ovpn-pool" ranges=192.168.1.2-192.168.1.2
#В пуле будет только один адрес.

/ ppp profile
add name="ovpn-profile" local-address=192.168.1.1 remote-address=ovpn-pool use-encryption=yes only-one=yes change-tcp-mss=default
#Странно, но это создается в / ppp %)

/interface ovpn-server server
set enabled=yes auth=sha1 netmask=24 certificate=cert1 max-mtu=1500 port=1194 cipher=aes256 keepalive-timeout=60 mode=ip require-client-certificate=no default-profile=ovpn-profile
#Настраиваем наш сервер на необходимый уровень безопасности
#Важно выбрать mode=ip !

/ ppp secret
add name="user-1" service=pptp password="123456" profile=ovpn-profile
#Обязательно указывайте имя пользователя и пароль в кавычках!

На роутере, который будет OpenVPN Client"ом выполняем:

/interface ovpn-client
add name="ovpn-out1" connect-to=Real_1 port=1194 mode=ip user="user-1" password="123456" profile=default certificate=none cipher=aes256 add-default-route=no
#Вместо Real_1 поставьте реальный IP вашего OpenVPN сервера.
#Имя пользователя и пароль указываем в кавычках!
#Важно выбрать mode=ip !

/ip firewall nat
chain=srcnat out-interface=ether1 src-address=192.168.100.0/24 action=masquerade
#Маскируем адреса пришедшие с 192.168.100.0/24
#На этом всё :)

Лирическое отступление

Интересно отметить, что, теоретически, есть возможность установки ВПН соединения, не имея ни одного реального IP адреса. Аналог такого соединения – устанавливаемое голосовыми интернет месагерами типа скайп. Суть такого соединения состоит в том, что есть несколько узлов и один сервер. Каждый узел соединён с сервером, но когда узел1 хочет установить сеанс связи с узлом2, он запрашивает параметры установленного соединения на сервер узла2, у сервера, после чего «вклинится» вместо сервера, до разрыва установленного соединения и установит его напрямую. Это реализуется при помощи протокола SIP (Session Initiation Protocol). Именно по этому сервера Скайп не загружены промежуточным трафиком, генерируемым клиентами. Результат таких изысканий установки соединения ВПН тоннеля используя SIP контроль привёл по ссылке

Существует два способа объединить сети при помощи SoftEther VPN.
1) Соединение мостом, при этом сети объединяются в один сегмент Ethernet. Этот вариант неудобен, т.к. если в обеих сетях есть сервисы, требующие работы в единственном экземпляре, то это приведет к конфликтам (например, DHCP). Кроме того, если узлов в сети много, то произойдет увеличение широковещательного трафика.
2) Второй способ основывается на первом. Но здесь создается виртуальный коммутатор третьего уровня OSI, который управляет трафиком между сетями. Также создается дополнительный виртуальный хаб (концентратор), к которому подключается удаленная сеть. Из минусов: не поддерживаются протоколы динамической маршрутизации, не поддерживается протокол IGMP, на узлах с общими ресурсами необходимо прописывать статические маршруты.

В данной статье рассматривается второй способ.

Преимущество данной схемы в том, что ненужно тратиться на дорогие роутеры с VPN, а параноикам использовать дырявый протокол PPTP. Включил ПК - и связь автоматически поднялась, если на другом конце ПК тоже включен. Производительность связи упирается в скорость вашего интернет-канала (включая производительность маршрутизации роутера) и мощность процессора ПК, т.к. шифрование трафика осуществляется именно им.

Имеем две сети, с центральными узлами в виде маршрутизатора с DHCP сервером и WAN. На ПК в одной сети необходимо установить SoftEther VPN Server, а в другой сети SoftEther VPN Bridge.

Установка VPN сервера на Windows

Установка SoftEther VPN Server достаточно проста. Проиллюстрирую ее картинками с небольшими комментариями. Скачиваем дистрибутив SoftEther VPN Server c официального сайта и запускаем.
Выбираем вариант установки - VPN Server и жмем «Далее».

Затем принимаем условия соглашения и выбираем стандартную установку.

После запуска VPN сервера появится окно администрирования, нажимаем кнопку «Connect». Задаем пароль администратора сервера.

Указываем тип сервера - Site-to-Site VPN Server. (Center)

Затем идет настройка функции dynamic DNS, жмем Exit. Позже её можно отключить, изменив в файле конфигурации строку на: “declare DDnsClient { bool Disabled true “ .

Далее необходимо указать физическую сетевую карту для соединения виртуального хаба с локальной сетью. Соединение осуществляется на канальном уровне OSI, поэтому виртуальный хаб не получает никакого IP адреса в сети. Однако некоторые роутеры могут заметить в локальной сети появление IP адреса подсети 172.31.0.0/16. Этот адрес используется для отслеживания соответствия ARP записей IP адресам или чего-то подобного.

Далее предлагается настроить доступ по L2TP и включить Azure VPN. Пропустим эти шаги, т.к. в этой схеме они не участвуют. Azure VPN можно отключить, если у вас белый IP. Если адрес серый, то не отключайте и используйте доменный адрес Azure VPN вместо IP.

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

По окончании первичной настройки попадаем в окно администрирования сервера. Первым делом, удалим ненужные порты (все, кроме 5555 - он используется для подключения к панели администрирования). Задаем какой-нибудь нестандартный TCP порт для прослушивания, например, 7710. Если у Вас нет белого IP адреса, то для использования Azure VPN необходимо слушать 443 порт.
Теперь необходимо создать второй виртуальный хаб, к которому будет подключаться удаленная сеть. Чтобы создать второй хаб, кликаем кнопку «Create a Virtual Hub». Назовем его, например, по номеру удаленной сети - 12. В этом виртуальном хабе создавать Local Bridge ненужно.

Далее, выбираем 12 хаб и нажимаем «Mange Virtual Hub», затем «Manage Users» создаем пользователя для удаленной сети. Назовем его «Network 12», вместо пароля будем использовать самоподписанный сертификат с тайным ключом.

Кликаем «Create Certificate» и заполняем строчку “Common name”.

Выбираем формат сертификата - X509 (сертификат отдельно, тайный ключ отдельно).

Сохраненный сертификат и тайный ключ необходимо будет загрузить в клиент SoftEther VPN Bridge.
Далее необходимо открыть порт в роутере - тот самый, который слушает сервер, и настроить трансляцию порта на ПК с сервером. Подробнее о том, как открывать порты, можно прочитать в этой статье. .
Например, в pfSense правило для открытия порта выглядит примерно так. pfSense - при создании правила для NAT, автоматически создает правило и для Firewall. Другие роутеры могут этого не делать, поэтому надо создавать оба правила ручками.

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

Если на компьютерах включен брандмауэр, то там тоже необходимо разрешить прохождение трафика для нужной сети.
Далее необходимо создать виртуальный роутер. Кликаем кнопку «Layer 3 Switch Settings», создаем новый виртуальный роутер и кликаем кнопку «Edit». Затем, необходимо создать виртуальные интерфейсы для каждого хаба. Для хаба с именем 10 создаем интерфейс с адресом 192.168.10.100, для хаба с именем 12 - 192.168.12.100. Адреса можно придумать свои, главное, чтобы они не были заняты и принадлежали каждый к своей подсети. Разработчики уверяют, что маршруты добавлять необязательно, но лучше на всякий случай добавить. Для запуска роутера нажимаем кнопку «Start».

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

Запускаем установку SoftEther VPN Server, при этом выбираем вариант установки SoftEther VPN Bridge. Жмем все время «Далее», затем задаем пароль администратора.

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

После этого попадаем в панель управления SoftEther VPN Bridge. Как видим, многие функции в этом режиме отключены.

Далее необходимо создать каскадное подключение к серверу SoftEther VPN. Нажимаем «Mange Virtual Hub» затем «Mange Cascade Connection» и заполняем данные для подключения.
Settings name - имя подключения.
Host Name - белый IP адрес или доменное имя DDNS роутера сети, где установлен сервер. Если у вас нет белого IP адреса, то используем службу Azure VPN и пишем доменное имя, полученное в этой службе (vpn123456789.vpnazure.net). Думаю, понятно, что без белого IP адреса открывать порты на роутере ненужно.
Port Number - порт, который слушает сервер.
Virtual Hub Name - имя виртуального хаба на сервере.
User Authentication Settings - настройки аутентификации пользователя. Поскольку мы решили использовать вместо пароля самоподписанный сертификат, то выбираем строчку «Client Certificate Authentication». Пишем имя пользователя (в примере это - Network 12). Кликаем «Specify Client Certificate», загружаем сертификат и тайный ключ шифрования.

Теперь необходимо настроить параметры соединения - кликаем “Advanced Settings”. Здесь необходимо задать количество TCP соединений, для широкополосного соединения рекомендуется 8.

Настройка маршрутизации

Настройка заключается в прописывании статических маршрутов в роутерах обеих подсетей.
На роутере 192.168.10.1 (см. схему) прописываем маршрут до сети 192.168.12.0. Выглядеть он будет так: 192.168.12.0 маска 255.255.255.0 шлюз 192.168.10.100.
На роутере 192.168.12.1 прописываем маршрут до сети 192.168.10.0: 192.168.10.0 маска 255.255.255.0 шлюз 192.168.12.100.
Для надежности перезагружаем оба ПК и роутера.

Доступ к общим папкам через SoftEther VPN

После произведенных выше настроек все компьютеры в сети должны нормально «пинговать» друг друга (если не запрещено брандмауэром). Однако, получить доступ к общим папкам Windows невозможно. Эта проблема решается прописыванием статических маршрутов непосредственно на компьютерах с общими ресурсами. Запускаем командную строку Windows от имени администратора и пишем команду:
для компьютеров, находящихся в сети 192.168.10.0:
route -p add 192.168.12.0 mask 255.255.255.0 192.168.10.100
для компьютеров, находящихся в сети 192.168.12.0:
route -p add 192.168.10.0 mask 255.255.255.0 192.168.12.100
На этом настройка завершена. Для анализа маршрута трафика советую пользоваться командной строкой Windows, командой pathping .

Вопросы задаем в комментариях.