Linux настройка маршрутизации через vpn
Обновлено: 07.07.2024
Обычно, при создании VPN, используется подключение типа точка-точка к некоторому серверу, либо установка ethernet-туннеля с некоторым сервером, при котором туннелю назначается определённая подсеть. Сервер VPN при этом выполняет функции маршрутизации и фильтрования трафика для доступа к локальной сети через VPN.
Данная статья рассматривает другой подход к созданию виртуальной сети, при котором удалённые системы включаются в уже существующую локальную подсеть, а сервер VPN выполняет роль Ethernet-шлюза. При использовании такого подхода мы всё ещё имеем возможность фильтровать трафик на основании способа подключения (например, использовать для локальной сети и для удалённых пользователей разные фильтры), но исключается необходимость настройки маршрутизации, а удалённые машины включаются прямо в локальную сеть, видят ресурсы, даже способны использовать широковещательные посылки вообще без дополнительной настройки. Через такой VPN у них отображаются все компьютеры локальной сети Windows, все доступные XDMCP-серверы при XDMCP broadcast и т. д.
Структура сети и настройка сервера
Предположим, что имеется офис с локальной сетью, используется IP-подсеть 192.168.168.0/24. В эту локальную сеть мы включим домашних пользователей, то есть они будут иметь адрес из этой же самой подсети. Необходимо убедиться, что у них «дома» не встречается данная подсеть, и что никакие системы в локальной сети не имеют адресов из диапазона, который мы выделим для удалённых пользователей.
Поддержка моста в ядре
Для работы такой техники нам нужны некоторые ядерные драйвера. Это универсальный драйвер виртуальных сетевых интерфейсов tun, и драйвер ethernet-моста bridge. Можно включить их в ядро, или собрать модулями:
Если они будут собраны модулями, необходимо либо включить автоматическую загрузку модулей в ядре, либо загружать их самому перед установкой VPN-соединения.
Программное обеспечение
Для сервера потребуется OpenVPN и утилиты для обслуживания моста. В Gentoo они собираются следующим образом:
При использовании >=sys-apps/baselayout-1.12.6 этого достаточно, для более старых версий потребуются специальные утилиты для обслуживания tun/tap-устройств:
Настройка сети
Положим, eth2 — интерфейс, к которому подключена локальная сеть, с назначенным адресом 192.168.168.254. Его настройка выглядела примерно так:
Поскольку он будет участвовать в мосте, ему не нужно назначать адреса. Также, в мосте участвует вновь создаваемый виртуальный интерфейс tap0, которому тоже не назначается никакого адреса. Адрес, который использовался eth2, назначается теперь мосту br0:
Также нужно создать настроечные скрипты для указанных интерфейсов:
Достаточно автоматически загружать только интерфейс br0. depend_br0() автоматически поднимет все остальные необходимые ему для работы:
Создание ключей OpenVPN
Мы будем авторизовывать клиентов посредством RSA-ключей OpenSSL. Для упрощения процесса, для нас приготовили несколько init-скриптов:
Там есть файл vars, в который мы занесём общие значения:
Внизу этого файла мы заполняем наши переменные:
Загружаем переменные из этого файла и строим CA (Certificate Authority):
Ключ сервера
Для генерации ключа сервера с именем office, используем следующую команду:
На вопрос «Common Name» нужно ответить именем сервера (в нашем случае, office). На два вопроса в конце «Sign the certificate? [y/n]» и «1 out of 1 certificate requests certified, commit? [y/n]» отвечаем «y».
При необходимости, можно будет создать дополнительные ключи серверов. Например, это могут быть резервные серверы доступа для повышения надёжности системы. Они создаются той же командой, перед ней нужно выполнить source ./vars.
Параметры Диффи-Хеллмана
Здесь ничего дополнительно делать не придётся, но придётся подождать.
Этот файл нужен только на сервере.
Ключи клиентов
Каждому клиенту необходимо выдать свой ключ. Для клиента с именем client ключ создаётся командой
На вопрос о «Common Name» отвечаем именем клиента (в данном случае, client). На два вопроса в конце отвечаем согласием.
Сгенерированные ключи и сертификаты передаём клиентам через защищённый канал. При необходимости, можно создавать ещё ключи той же командой. Перед её запуском, необходимо загрузить окружение — выполнить source ./vars.
Настройка и запуск сервиса OpenVPN
Для запуска следует использовать следующую конфигурацию сервера (файл /etc/openvpn/openvpn.conf):
Ключ office.key должен иметь режим 600 (доступ только владельцу). Файлы office.crt и dh1024.pem имеют режим 644.
Настройка фильтрования
Поскольку мы используем мост, есть несколько особенностей организации фильтрования пакетов. Например, не все проходящие пакеты могут вообще оказаться IPv4. Для настройки работы моста в ядре существует несколько параметров:
- bridge-nf-call-arptables
Логическая переменная bridge-nf-call-arptables управляет передачей трафика ARP в цепочку FORWARD пакетного фильтра arptables. Установленное по умолчанию значение 1 разрешает передачу пакетов фильтрам, 0 – запрещает. - bridge-nf-call-iptables
Логическая переменная bridge-nf-call-iptables управляет передачей проходящего через мост трафика IPv4 в цепочки iptables. Используемое по умолчанию значение 1 разрешает передачу пакетов для фильтрации, 0 – запрещает. - bridge-nf-call-ip6tables
Действие аналогично предыдущему, только оно настраивает передачу трафика IPv6 для фильтрования в цепочки ip6tables. - bridge-nf-filter-vlan-tagged
Логическая переменная bridge-nf-filter-vlan-tagged определяет возможность передачи трафика IP/ARP с тегами VLAN программам фильтрации пакетов (arptables/iptables). Значение 1 (установлено по умолчанию) разрешает передачу пакетов с тегами VLAN программам фильтрации, 0 – запрещает.
Для фильтрования пакетов, проходящих через мост, используется соответствие physdev, которое различает, с какого и на какой порт моста следует пакет. Включаем его в ядре:
Кроме этого, конфигурация ядра должна разрешать передачу пакетов на фильтрацию iptables, т.е. bridge-nf-call-iptables=1 и bridge-nf-call-ip6tables=1 (если вы используете IPv6).
После можете использовать, например, такие правила для фильтрования:
Поподробнее про настройку фильтрации между портами поста можно почитать в статье Building bridges with Linux
Если вы не хотите делать никаких различий между пользователями LAN и пользователями bridged VPN, вы можете просто выключить эти параметры в ядре (они включены по умолчанию):
Клиенты
На клиенте необходимо создать конфигурационный файл OpenVPN следующего содержания:
Если сервер подключен через несколько провайдеров, можно повысить устойчивость сети к отказам. Для этого клиенту нужно прописать несколько опций remote, по одной на сервер, в порядке «сначала предпочтительные».
Имена файлов, указанные в параметрах ca, cert и key — это файлы, переданные через защищённый канал. Права доступа к файлу key должны быть установлены в 600.
Linux
Необходим universal tun/tap driver в ядре, либо модулем, но загруженный.
Gentoo
Соответственно, помещаем туда вышеприведённый конфиг, создаём симлинк и кладём скрипты в поддиректорию в /etc/openvpn/. В конфиге прописываем полный путь к ключу и сертификатам. Следите, чтобы имена файлов в конфиге не пересекались, во избежание неприятных эффектов!
Windows
Конфигурационный файл помещается в директорию «C:\Program Files\OpenVPN\config\» с именем вроде «office.ovpn», туда же помещаются остальные файлы — ключи и сертификаты. Если мы их помещаем в поддиректорию (например, хотим использовать несколько виртуальных сетей и все они предоставили файлы с одинаковым именем ca.crt), указываем полные пути к файлам.
Для запуска сетей можно либо запустить сервис OpenVPN (тогда будут запущены все конфигурации *.ovpn, найденные в config\), либо по отдельности — щёлкаем по файлу .ovpn правой кнопкой и выбираем «Запустить OpenVPN с этой конфигурацией».
Возможные проблемы
Проверить доступность сервера, если он запущен на TCP, можно обычным telnetом.
Windows
Нет свободного виртуального адаптера TAP
По логу OpenVPN видно, что клиент успешно присоединился к серверу, авторизовался, но не смог привязать виртуальную сеть к виртуальному адаптеру. Скорее всего, какие-то другие процессы уже задествовали все имеющиеся в системе адаптеры TAP-Win32. Это мог быть и сам OpenVPN, повисший и не отдавший адаптер.
Лечится перезагрузкой или выяснением, какие бы это могли быть процессы и принудительным их убиванием.
На удаленном сервере статический ip на нем поднят VPN сервер С компа с динамическим IP подключаюсь к серверу и мне требуется ходить на удаленный сайт через VPN сервер, так как на нем фильтр по допустимым IP адресам. Прописал маршрут на клиенте
, но на этом затык, похоже что не хватает на сервере маршрутов из впн в инет и обратно подскажите какой командой и как прописать?
На vpn туннеле обычно поднимаются какие либо внутренние IP адреса и запрос от клиента внутри тоннеля идет с этого IP. Маршрутизация обычно поднимается автоматом и с ней проблем не бывает. А вот то, что пакет сервер пытается передать с ip-отправителя из подсети поднятой на VPN - это наиболее распространенная проблема. Необходимо, что бы сервер передавая пакет дальше, поменял в нем адрес отправителя на свой IP, с которого он выходит в интернет. Для этого используется NAT, а обычно его разновидность маскарадинг. Настраивается утилитой iptables на сервере:
Если клиентов несколько и их ip находятся в одной подсети, то ip-клиента может быть задан в виде ip-адрес-сети/маска-подсети
Посмотреть поднятые правила:
Удаляются ненужные правила почти такой же командой, которая использовалась при добавлении (со всеми ключами и ip-адресами), только -A меняется на -D .
Иногда, возникает необходимость перенаправлять трафик к некоторым сайтам через другой сетевой интерфейс. Простой пример: сотрудники филиала большой компании, должны работать со служебными разделами корпоративного портала через VPN. Из сети Интернет, доступ к данным разделам закрыт, в связи с требованиями безопасности.
У нас есть Linux сервер, который, помимо прочего, функционирует в качестве маршрутизатора. Весьма распространенная ситуация, ее и будем рассматривать, как пример. На схеме изображена типичная структура сети основного офиса и филиала:
Будем исходить из того, что VPN соединение уже настроено; при подключении создается устройство соответствующего типа (ppp или tun).
Логически решение выглядит так:
Рассказывать как установить пакеты на вашей версии Linux я не буду, надеюсь вы уже можете это сделать самостоятельно. Тем более дистрибутивы разные, и приводить в качестве примера какой-то конкретный, считаю неправильным.
Для начала настроим dnsmasq.
В первую очередь, нас интересуют вышестоящие (upstream) DNS серверы, к которым будут направляться запросы. Сам по себе, dnsmasq является, своего рода, прокси сервером. По умолчанию данная информация берется из системных настроек, файла resolv.conf. Однако можно указать альтернативный файл с помощью строки (dnsmasq.conf)
Укажем список доменов для занесения соответствующих им IP адресов в ipset list с именем VIAVPN
Через разделитель «/» можно указать любое количество доменов. Обращаю внимание, что все субдомены тоже попадут в ipset. В конце строки указывается название листа, в нашем случае VIAVPN.
Теперь самое время завести тот самый список VIAVPN
Указывается тип списка – ip адреса со структурой хранения hash. То есть, с очень быстрым, фактически мгновенным, поиском IP адреса в огромном списке. Именно по этой причине используется ipset, а не напрямую правила iptables. Family inet говорит об адресах протокола IPv4.
Правило iptables, которое будет маркировать пакеты, к IP адресам доменов (то есть с пометкой VIAVPN), маркером 1. По сути, мы меняем одну метку на другую, но беда в том, что селкторы ip rule не могут работать с ipset, лишь с fwmark. Данное правило как раз служит исключительно для этого:
Команда не требует каких-то особых разъяснений, всё достаточно очевидно. Единственное, dst говорит о направлении трафика. То есть, извлекаем из пакета адрес назначения и проверяем его наличие в списке VIAVPN. Если присутствует, помечаем такой пакет меткой 1.
Переходим к маршрутизации
Ну, первое, конечно, заводим отдельную таблицу, назовем ее vpnrouting. Идем в файлик /etc/iproute2/rt_tables и добавляем туда строку
ID может быть любым свободным положительным числом до 255
Добавляем маршрут по умолчанию (default gateway) в созданную таблицу. Кроме него, в нашем случае, больше ничего не понадобится, однако, сюда можно добавить другие, более точные маршруты при необходимости
Почти всё готово! Осталось указать, в какой таблице искать маршруты для пакетов с меткой (fwmark) 1. Если добавлять маршруты через упрощенную утилиту route, то они, на самом деле, прописываются, в таблицу main. А правило для всех пакетов, по умолчанию, ищет маршруты именно в ней.
Выведем список всех правил поиска маршрута для наглядности:
Задача указать правило поиска ДО таблицы main. По умолчанию, оно будет добавлено с приоритетом 32765. Нам это вполне подходит (хотя можем указать приоритет явным образом, например 100):
ВАЖНОЕ ЗАМЕЧАНИЕ!
Не забудьте проверить состояние rp_filter
Для нормальной работы, результат должен быть либо 0, либо 2. Смысл данного фильтра в следующем. Когда пакет приходит на интерфейс, ядро проверяет для него обратный маршрут. И если ответ предполагает отправку через другой интерфейс, а не тот же самый, то он считается мусорным и сбрасывается. Структура, которую мы настроили, не позволяет ядру корректно определить маршрут через тот же интерфейс. Поскольку на данном этапе он еще не маркирован, и предполагает отправку через default gateway таблицы main.
Для более полной информации, стоит прочитать что такое rp_filter, для чего он нужен и смысл значений его параметров. Я рекомендую переводить его в значение 2 для интерфейса tun0, и 1 для всех остальных.
Организация каналов между офисами при помощи OpenVPN на платформе Linux
Так уж получилось, что за все время существования нашего ресурса мы ни разу не обращались к теме OpenVPN на платформе Linux. Несмотря на то, что это кроссплатформенный продукт, наши публикации, а точнее публикации наших авторов затрагивали только Windows платформу, поэтому мы решили устранить этот досадный недостаток и заодно самостоятельно проработать данную тему. Кроме того, данный материал, как и все наши материалы, органично связан с другими публикациями, что позволит легко вписать данный сервис в инфраструктуру созданную на основе наших статей.
Прежде всего несколько слов о том, что такое OpenVPN - это свободная реализация технологии виртуальной частной сети (VPN) с открытым исходным кодом. Что это значит для простого пользователя? Прежде всего независимость от вендора и лицензионную чистоту данного решения, а также способность работать на любой платформе, даже на недорогих роутерах, если они позволяют использовать альтернативные прошивки (OpenWrt и т.п.).
Следует понимать, что OpenVPN не накладывает каких-либо ограничений на платформы для работы сервера и клиентов, вы можете без проблем объединить в единую сеть устройства с разными ОС и аппаратными платформами и все это будет работать.
Отдельного внимания заслуживают богатые сетевые возможности продукта, который может успешно работать даже в сложных сетевых конфигурациях, не допускающих прохождения некоторых видов трафика (например, мобильные операторы), а также возможность автоматической конфигурации узлов сети, в т.ч. настройки маршрутов.
Схема сети и маршрутизация
Мы специально не стали разворачивать для OpenVPN отдельную конфигурацию в наше лаборатории, а воспользовались уже существующими виртуальными машинами. В качестве сервера центрального офиса мы использовали роутер на базе Ubunutu Server 14.04 LTS, за которым находится сеть 192.168.31.0/24, в которой находится рабочая станция под управлением Windows 10. В филиале OpenVPN установлен на сервер с Debian 8, который принадлежит сети 192.168.18.0/24, в которой находится рабочая станция с Windows 8.1 и которая выходит в интернет через простой роутер начального уровня.
Таким образом мы реализовали два основных варианта, когда машина с OpenVPN является шлюзом сети и когда она установлена на одном из узлов, что требует разной настройки маршрутизации.
В случае, когда OpenVPN расположен на одном из узлов сети ситуация несколько иная. Так, например, пакеты к сети 192.168.31.0/24 будут также направлены шлюзу, который их просто отбросит, так как диапазоны частных сетей ("серые" IP) не маршрутизируются. Поэтому нам потребуется явно задать маршрут к OpenVPN, который передаст эти пакеты дальше, согласно собственных настроек маршрутизации, а именно OpenVPN серверу. Это можно сделать, прописав соответствующий маршрут на роутере сети, либо, если роутер не позволяет этого сделать, непосредственно на каждой рабочей станции.
В нашем случае потребуется маршрут (на роутере или на клиентах):
который будет направлять все пакеты к сети 192.168.31.0 узлу с установленным OpenVPN, дальнейшая маршрутизация на другой конец туннеля будет выполняться также силами OpenVPN.
Мы настоятельно рекомендуем прорабатывать данный вопрос перед развертыванием VPN-сети, чтобы у вас уже на этом этапе было полное понимание ее структуры и схемы маршрутизации между ее узлами. Более подробную информацию по данному вопросу можно получить в статье: Организация VPN каналов между офисами. Маршрутизация.
Настройка сервера OpenVPN
Прежде всего установим необходимые пакеты:
Пакет easy-rsa предназначен для создания и управления сертификатами и по сути представляет собой автономный центр сертификации (CA), поэтом следует принять меры по недопущению доступа сторонних лиц к закрытым ключам CA. В тоже время мы считаем избыточными советы по выносу центра сертификации на отдельный хост, в небольших сетях это может оказаться более небезопасно, чем размещение на роутере, к которому имеет доступ только администратор.
Скопируем рабочую директорию easy-rsa в папку с настройками OpenVPN:
В своей работе easy-rsa использует библиотеку openssl и содержит конфигурационные файлы для разных версий библиотеки. В современных системах повсеместно используется openssl-1.0.x поэтому сразу делаем символическую ссылку на нужный конфигурационный файл:
Теперь откроем файл /etc/openvpn/easy-rsa/vars и отредактируем в нем следующие строки, указав собственные учетные данные, например, так:
Сохраним файл и перейдем к созданию собственного CA, для этого перейдем в директорию easy-rsa и загрузим переменные:
Затем произведем очистку и инициализацию нашего центра сертификации:
Первая команда произведет полную очистку рабочей директории с ключами и служебными файлами и ее случайное выполнение на работающем CA приведет к его уничтожению. Вторая команда создаст комплект из открытого и закрытого ключей центра сертификации.
В процессе создания ключа вы будете получать вопросы, ответы по умолчанию на которые содержатся в квадратных скобках и основаны на ваших данных из файла vars, поэтому просто подтверждаем их нажатием Enter (или вводим свои значения).
После выполнения данной операции в папке /etc/openvpn/easy-rsa/keys появятся файлы ca.crt и ca.key. Первый является сертификатом с публичным ключом и должен присутствовать на всех узлах OpenVPN сети, а файл с расширением .key - закрытый (приватный) ключ и доступ к нему должен быть ограничен. Файл ca.key нужен исключительно для работы центра сертификации и не должен никуда копироваться или передаваться, особенно по незащищенным каналам.
Закончив с центром сертификации перейдем к формированию ключей и сертификатов сервера. Но сначала создадим файл параметров Диффи-Хеллмана. Данный алгоритм шифрования используется для обеспечения режима прямой секретности, которая сводится к тому, что даже если злоумышленник получит ключи, то он не сможет расшифровать перехваченные ранее данные, так как они зашифрованы с уникальным сеансовым ключом, который нигде не сохраняется.
Результатом выполнения данной команды будет появление в директории с ключами файла dh2048.pem, который нужен только серверу, но в тоже время секретным он не является.
Наконец сформируем ключи собственно для сервера:
где server - имя ключа и сертификата сервера, мы рекомендуем давать осмысленные названия, например, по имени узла, чтобы потом не пришлось гадать, для какого именно сервера или клиента предназначен тот или иной сертификат или ключ.
В процессе генерации вам также придется подтвердить параметры из файла vars, либо указать свои, в конце вы получите два вопроса о подписи и выпуске сертификата, на оба отвечаем утвердительно.
Теперь перейдем к настройке самого OpenVPN. Прежде всего создадим директорию для хранения ключей, несмотря на то, что можно указать пути к папке с ключами easy-rsa, мы все-таки советуем хранить серверные ключи отдельно.
Перейдем в папку с ключами easy-rsa и скопируем необходимые ключи и сертификаты:
Затем распакуем и скопируем в /etc/openvpn шаблон файла конфигурации:
Напомним, чтобы не набирать длинные пути можно воспользоваться автодополнением по клавише Tab.
Откроем данный файл (/etc/openvpn/server.conf) и перейдем к его редактированию, если не указано иное, то приведенные ниже опции следует найти и привести к указанному виду, при необходимости раскомментировав. Опции перечислены в порядке их следования в файле.
Данные опции установлены по умолчанию и задают порт, протокол и тип туннеля, менять их не следует, однако на плохих каналах иногда имеет смысл использовать протокол tcp. Ниже добавим опцию, указывающую топологию создаваемой VPN-сети:
Затем найдем и откорректируем пути к ключам и сертификатам:
Синтаксис конфигурационного файла допускает указание относительных путей, в этом случае корневой будет считаться папка /etc/openvpn.
Зададим диапазон OpenVPN сети:
Следующая опция указывает файл для хранения выданных клиентам IP-адресов, так как OpenVPN прекрасно умеет назначать адреса мы не видим смысла делать это вручную:
Укажем путь к директории с конфигурационными файлами, выполняемыми при подключении клиента:
Затем перейдем к настройкам маршрутизации. Прежде всего укажем шлюз по умолчанию для OpenVPN сети, которым должен являться сервер:
Зададим маршрут к клиентской сети, если сетей несколько - то строк тоже должно быть несколько. Данная опция указывает OpenVPN при запуске создать маршруты в системе для указанных подсетей для направления предназначенных им пакетов в туннель.
Передадим всем клиентам аналогичную команду, но для сети за сервером:
Установим параметры проверки активности:
Данная опция устанавливает интервал проверки узла (10 сек) и время после которого, при отсутствии ответа, клиент считается неактивным.
Укажем тип применяемого шифрования, на выбор предлагается три вида шифра, но Triple-DES имеет самые большие накладные расходы, поэтому выбирать следует между Blowfish и AES. Однозначно дать рекомендации здесь трудно, но следует учитывать, что AES де-факто является промышленным стандартом и аппаратно поддерживается в процессорах Intel.
В целях безопасности понизим права запущенного сервера:
При этом обязательно проконтролируйте наличие следующих опций, которые обеспечивают правильную работу с ресурсами после понижения прав:
Укажем расположение логов:
Для отладки проблем с подключением уровень лога следует поднять до 5-6.
На этом настройка сервера закончена, сохраняем файл конфигурации и создаем директорию для конфигураций клиентов, иначе получите ошибку при запуске службы:
Теперь можно попробовать запустить сервер:
Убедимся в наличии сетевого интерфейса туннеля командой
И проверим таблицу маршрутизации:
Как видим - необходимые маршруты добавлены автоматически.
Настройка клиента OpenVPN
Настройка клиента начинается на сервере с генерации ключевой пары. Для этого снова перейдем в директорию easy-rsa и загрузим переменные (если вы создаете клиентские ключи одновременно с серверными, то повторно загружать переменные не нужно).
Выполним генерацию клиентских ключей и сертификатов командой:
где client1 - имя ключа и сертификата.
На компьютер клиента нам нужно передать ca.crt, client1.crt и client1.key, последний файл является секретным и не должен передаваться в открытом виде по незащищенным каналам.
Также создадим в папке ccd файл с инструкциями для клиента, которые будут выполнены при его подключении. Имя файла должно совпадать с именем сертификата клиента, точнее с полем CN в нем, если вы не меняли это поле при создании ключевой пары оно будет соответствовать имени файла сертификата.
Откроем этот файл и внесем в него строки:
Данная команда создает маршрут в OpenVPN сети, направляя пакеты предназначенные сети 192.168.18.0 на внутренний адрес данного клиента. В таблице маршрутов ОС данный маршрут не отображается, но без него маршрутизация в OpenVPN сети правильно работать не будет.
Теперь, взяв с собой необходимые ключи и сертификаты, переместимся на клиентский компьютер. В нашем случае это сервер с установленным Debian 8.
Установим необходимые пакеты:
Создадим директорию для ключей и разместим в ней ключи и сертификаты:
Скопируем файл с шаблоном конфигурации клиента:
И перейдем к его редактированию:
Данные опции задают режим - клиент, тип туннеля и протокол, последние должны совпадать с указанными на сервере.
Затем укажем адрес и порт нашего сервера:
Вместо доменного имени можно указывать IP-адрес, например, так:
Следующая опция предписывает бесконечное число попыток разрешить доменное имя сервера OpenVPN, рекомендуется для клиентов с нестабильным подключением к сети.
Понижаем права службы после запуска (если конфигурационный файл предназначен для Windows-машин данные опции не нужны):
Обязательно проверяем наличие:
Указываем расположение ключей и сертификатов:
Следующая опция предотвращает потенциальные атаки класса "человек посередине":
Затем укажем тип шифрования, он должен совпадать с тем, что вы указали на сервере:
Задаем расположение логов и их детализацию:
Сохраняем файл конфигурации и запускаем службу с явным указанием клиента, в противном случае будет выполнена попытка найти и запустить конфиг сервера:
Также убеждаемся в том, что туннельный интерфейс создался и необходимые маршруты добавлены:
На скриншоте выше несложно заметить маршрут в сеть 192.168.31.0 через туннель, но так как данный компьютер не является шлюзом сети, то нам нужно будет добавить на шлюзе или клиентских ПК маршрут к сети 192.168.31.0 через локальный адрес данного компьютера, о чем мы говорили в начале статьи.
Например, мы добавили такой маршрут на клиентском ПК c Windows 8.1:
После чего без каких-либо проблем смогли получить доступ к компьютерам в сети офиса (добавленный вручную маршрут мы выделили на скриншоте).
А также в обратном направлении.
Читайте также: