VPN-мост в локальную сеть
Прочитал топик habrahabr.ru/blogs/linux/67209 и решил выложить сюда свою статью, которая была до этого видна только в закрытой корпоративной Wiki.
Обычно, при создании 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. Для настройки работы моста в ядре существует несколько параметров:
Переменные этой группы сохраняются в файлах директории /proc/sys/net/bridge/. Их можно также настраивать в /etc/sysctl.conf, тогда они все получат префикс «net.brigde.»
- 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
При установке net-misc/openvpn создаётся скрипт /etc/init.d/openvpn. Этот скрипт запускает openvpn с конфигурационным файлом /etc/openvpn/openvpn.conf. Мы, однако, можем поддерживать несколько конфигураций OpenVPN одновременно, если сделаем симлинки вида /etc/init.d/openvpn.network-name -> /etc/init.d/openvpn — каждый такой скрипт запускает OpenVPN с конфигурационным файлом /etc/openvpn/network-name.conf.
Соответственно, помещаем туда вышеприведённый конфиг, создаём симлинк и кладём скрипты в поддиректорию в /etc/openvpn/. В конфиге прописываем полный путь к ключу и сертификатам. Следите, чтобы имена файлов в конфиге не пересекались, во избежание неприятных эффектов!
Запуск и останов сети производятся через управление сервисом /etc/openvpn.network-name.
Windows
Конфигурационный файл помещается в директорию «C:\Program Files\OpenVPN\config\» с именем вроде «office.ovpn», туда же помещаются остальные файлы — ключи и сертификаты. Если мы их помещаем в поддиректорию (например, хотим использовать несколько виртуальных сетей и все они предоставили файлы с одинаковым именем ca.crt), указываем полные пути к файлам.
Для запуска сетей можно либо запустить сервис OpenVPN (тогда будут запущены все конфигурации *.ovpn, найденные в config\), либо по отдельности — щёлкаем по файлу .ovpn правой кнопкой и выбираем «Запустить OpenVPN с этой конфигурацией».
Возможные проблемы
Проверить доступность сервера, если он запущен на TCP, можно обычным telnetом.
Windows
Нет свободного виртуального адаптера TAP
По логу OpenVPN видно, что клиент успешно присоединился к серверу, авторизовался, но не смог привязать виртуальную сеть к виртуальному адаптеру. Скорее всего, какие-то другие процессы уже задествовали все имеющиеся в системе адаптеры TAP-Win32. Это мог быть и сам OpenVPN, повисший и не отдавший адаптер.
Лечится перезагрузкой или выяснением, какие бы это могли быть процессы и принудительным их убиванием.
Ethernet Bridging
Ethernet bridging essentially involves combining an ethernet interface with one or more virtual TAP interfaces and bridging them together under the umbrella of a single bridge interface. Ethernet bridges represent the software analog to a physical ethernet switch. The ethernet bridge can be thought of as a kind of software switch which can be used to connect multiple ethernet interfaces (either physical or virtual) on a single machine while sharing a single IP subnet.
By bridging a physical ethernet NIC with an OpenVPN-driven TAP interface at two separate locations, it is possible to logically merge both ethernet networks, as if they were a single ethernet subnet.
Bridging Setup
This example will guide you in configuring an OpenVPN server-side ethernet bridge. Multiple clients will be able to connect to the bridge, and each client’s TAP interface will be assigned an IP address that is part of the server’s LAN.
There are two methods for handling client IP address allocation:
- Let OpenVPN manage its own client IP address pool using the server-bridge directive, or
- configure the DHCP server on the LAN to also grant IP address leases to VPN clients.
In this example, we will use the first method where the OpenVPN server manages its own IP address pool on the LAN subnet, separate from the pool used by the DHCP server (if one exists). Both methods are described more fully in this FAQ item.
For our example, we will use these bridge settings:
| Setting | bridge-start parameter | Value |
| Ethernet Interface | eth | eth0 |
| Local IP Address | ip | 192.168.8.4 |
| Local Netmask | eth_netmask | 255.255.255.0 |
| Local Broadcast Address | eth_broadcast | 192.168.8.255 |
| VPN client address pool | 192.168.8.128 to 192.168.8.254 | |
| Virtual Bridge Interface | br | br0 |
| Virtual TAP Interface | tap | tap0 |
The first step is to follow the HOWTO up to the “Starting up the VPN and testing for initial connectivity” section. Next, proceed below according to whether you are setting up the bridge on Linux or Windows.
Bridge Server on Linux
First, make sure you have the bridge-utils package installed.
Edit the bridge-start script below. Set the br, tap, eth, eth_ip, eth_netmask, and eth_broadcast parameters according to the physical ethernet interface you would like to bridge. Make sure to use an interface which is private and which is connected to a LAN which is protected from the internet by a firewall. You can use the Linux ifconfig command to get the necessary information about your network interfaces to fill in the bridge-start parameters.
Now run the bridge-start script. It will create a persistent tap0 interface and bridge it with the active ethernet interface.
Next, we will edit the OpenVPN server configuration file to enable a bridging configuration.
Comment out the line which says dev tun and replace it instead with:
Comment out the line that begins with server and replace it with:
| Now set up the Linux firewall to permit packets to flow freely over the newly created tap0 and br0interfaces: |
The OpenVPN bridge can now be started and stopped using this sequence::
- run bridge-start
- run openvpn
- stop openvpn
- run bridge-stop
At this point, the bridging-specific aspects of the configuration are complete, and you can continue where you left off in the HOWTO.
Bridge Server on Windows XP
This configuration requires Windows XP or higher on the bridge side. To my knowledge, Windows 2000 does not support bridging, however a Windows 2000 machine can be a client on a bridged network, where the other end of the OpenVPN connection where the bridging is occurring is a Linux or Windows XP machine.
When OpenVPN is installed on Windows, it automatically creates a single TAP-Win32 adapter which will be assigned a name like “Local Area Connection 2”. Go to the Network Connections control panel and rename it to “tap-bridge”.
Next select tap-bridge and your ethernet adapter with the mouse, right click, and select Bridge Connections. This will create a new bridge adapter icon in the control panel.
Set the TCP/IP properties on the bridge adapter to an IP of 192.168.8.4 and a subnet mask of 255.255.255.0.
Next, edit the OpenVPN server configuration file to enable a bridging configuration.
Comment out the line which says dev tun and replace it instead with:
Comment out the line that begins with server and replace it with:
| If you are running XP SP2, go to the firewall control panel, and disable firewall filtering on the bridge and TAP adapters. |
At this point, the bridging-specific aspects of the configuration are complete, and you can continue where you left off in the HOWTO.
Bridge Client configuration
Use the sample OpenVPN client configuration as a starting point. Comment out the line which says dev tun and replace it instead with:
Finally, ensure that the client configuration file is consistent with the directives used in the server configuration. The major thing to check for is that the proto (udp or tcp) directives are consistent. Also make sure that comp-lzo and fragment, if used, are present in both client and server config files.
Ethernet Bridging Notes
When using an ethernet bridging configuration, the first step is to construct the ethernet bridge — a kind of virtual network interface which is a container for other ethernet interfaces, either real as in physical NICs or virtual as in TAP interfaces. The ethernet bridge interface must be set up before OpenVPN is actually started.
There is no portable method for generating an ethernet bridge interface — each OS has its own method (see below for examples).
Once the bridge interface has been created, and appropriate ethernet interfaces have been added to it, OpenVPN may be started.
- A bridge interface is a kind of virtual network interface which is formed by combining one or more ethernet interfaces, each of which may be a physical NIC or a virtual TAP interface used for VPN tunneling.
- When you set up an ethernet bridge, you should manually set the IP address and subnet of the bridge interface and not use an ifconfig directive in the OpenVPN config. This is because unlike a TUN/TAP interface, OpenVPN cannot programmatically set the IP address and netmask of a bridge interface.
- The OpenVPN config should specify the TAP interface component of the bridge interface in its devdirective, not the name of the bridge interface itself.
- On Windows, use the dev-node directive to name the TAP-Win32 adapter which was added to the bridge (the dev-node name refers to the adapter name as shown in the Network Connections panel).
- On Linux/BSD/Unix, for the dev tap directive, use the explicit TUN/TAP unit number which you added to the bridge such as dev tap0.
- If you are running OpenVPN in point-to-point mode, omit an ifconfig directive, and if you are using client/server mode, use the server-bridge directive on the server.
- When bridging, you must manually set the TCP/IP settings on the bridge interface. For example on Linux, this can be done with an ifconfig command while on Windows XP it can be done by setting the TCP/IP properties of the bridge interface in the Network Connections panel (the Network Connections panel on Windows XP and higher allows for point-and-click bridging).
- Make sure to only bridge TAP interfaces with private ethernet interfaces which are protected behind a firewall. Never bridge a TAP interface with the same ethernet interface you use to connect to the internet, as that would create a potential security hole.
- The addresses used for local and remote should not be part of the bridged subnet — otherwise you will end up with a routing loop.
- An important point to understand with Ethernet bridging is that each network interface which is added to the bridge will lose its individual identity in terms of specific settings such as IP address and netmask. Only the TCP/IP settings of the bridge interface itself will be relevent.
- A common mistake that people make when manually configuring an Ethernet bridge is that they add their primary ethernet adapter to the bridge before they have set the IP and netmask of the bridge interface. The result is that the primary ethernet interface “loses” its settings, but the equivalent bridge interface settings have not yet been defined, so the net effect is a loss of connectivity on the ethernet interface.
- In most cases, it is possible to set up a usable bridge configuration with the ethernet-bridge itself only configured on the server side, not the client side. If this is done, the client machines will become multi-homed when they connect to the server, i.e. they will still have their regular ethernet interface, but upon connection to the OpenVPN server, they will now have a new TAP interface which is bridged with the server’s ethernet interface (and possibly all of the TAP interfaces of other connecting clients as well if the client-to-client directive is used on the server).
Notes — Ethernet Bridging on Windows
The Windows Notes page has additional information on ethernet bridging.