Как добавить tap интерфейс openvpn windows

Записки IT специалиста

Админу на заметку — 24. Как настроить несколько одновременных OpenVPN подключений в Windows

• Автор: Уваров А.С.
• 10.03.2019

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

А в чем, собственно, проблема? А в том, что на платформе Windows при установке OpenVPN по умолчанию мы можем иметь только одно активное соединение в один момент времени, при попытке выполнить второе подключение мы получим ошибку:

Но в этом случае даже не нужно ничего искать, причина неудачного соединения написана красным по белому: все TAP-адаптеры в этой системе уже используются. Действительно, при установке OpenVPN в системе создается только один TAP-адаптер. Что делать? Добавить нужное количество адаптеров, по числу необходимых одновременных соединений.

Для этого перейдем в C:\Program Files\TAP-Windows\bin, где обнаружим пакетный файл addtap.bat, для добавления в систему еще одного TAP-адаптера следует запустить его с правами Администратора.

Если вам нужно добавить более одного TAP-адаптера — запустите данный файл нужное количество раз. В данной директории также содержится файл deltapall.bat, который позволяет удалить из системы все установленные TAP-адаптеры.

В нашем случае мы добавили два адаптера, что позволило без проблем иметь три одновременных подключения к разным OpenVPN серверам:

Как видим — ничего сложного нет, поэтому надеемся, что данный материал окажется вам полезен и позволит использовать OpenVPN с полной отдачей.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

How to create a 2nd TAP adapter for OpenVPN client on Win7/10 [closed]

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago .

I want to create 2 separate tunnels on 2 separate subnets, so I have 2 separate .ovpn (client) files.

The 1st tunnel comes up, but the 2nd one fails because of a conflict over the same TAP-windows adapter. Evidently the 2nd tunnel needs its own TAP-windows adapter.

How to create a 2nd TAP-windows adapter? Apparently there used to be a utility packaged with the Windows OpenVPN installer — but there no longer is.

2 Answers 2

+1, I actually had to dig for this because the Add TAP Adapter link that used to be in the OpenVPN folder isn’t there. This is because now it’s a separate install (see this ticket), and as such the utilities are located in the %PROGRAMFILES%\Tap-Windows folder, under that folder there is a bin folder, and you can run the AddTap.bat script to add a new adapter, with elevated permissions of course.

There is already a driver for new installation at:

You can simply install a new TAP adapter referring this path with the New Hardware Wizard at Control Panel (just running hdwwiz.exe on Win Vista and above). Select Manual Installation —> Network Adapter .

Tested on Windows XP SP3 and Windows 7 SP1.

Example of my Windows 7 SP1 computer with a physical NIC, 2 TAP adapters, a PPTP and a virtual NIC created by VirtualBox:

OpenVPN: How to Connect Multiple VPNs at the Same Time on Windows

OpenVPN client on Windows with default settings only supports one active VPN connection. When installing OpenVPN on Windows, only one virtual adapter of the TAP or Wintun type is created. If you want to connect to multiple OpenVPN servers at the same time, you need to create an additional WinTAP or Wintun network adapter.

If you try to start another VPN connection, an error will appear:

OpenVPN GUI
Connecting to VPN_name has failed
All TAP-Windows adapters on the system are currently in use
TCP/UDP: Socket bind failed on local address [undef]: Address already in use (WSAEADDRINUSE)

To fix this problem and allow simultaneous connection to two (or more) OpenVPN servers, you need to add another virtual TAP network adapter. Each VPN connection will use its own TAP network interface.

Open an elevated command prompt and go to the directory:

The BAT file will run tapinstall.exe with several parameters. This command will add an additional network adapter in Windows with the TAP-Windows Adapter V9 driver. Run the bat file as many times as you want to use concurrent OpenVPN connections.

Device node created. Install is complete when drivers are installed.
Updating drivers for tap0901 from C:\Program Files\TAP-Windows\driver\OemVista.inf.
Drivers installed successfully.

After that, a new device “TAP-Windows Adapter #2” will appear in the list of Windows network adapters.

Starting with OpenVPN 2.5, to manage TAP adapters in Windows, you need to use the tapctl.exe utility, which replaces the legacy tapinstall.exe.

To add a new TAP adapter, just run the command:

If you need to create a TUN adapter, run:

List OpenVPN network adapters:

You can list the TAP network adapters available to the OpenVPN client using the command:

Available TAP-WIN32 adapters [name, GUID]:
'Local Area Connection 2'
'Local Area Connection 3'

Or use the command:

Check the configuration files (.ovpn) of your VPN connections in the C:\Program Files\OpenVPN\config. Add the following options to the OVPN config files:

• nobind – use a dynamic UDP source port for each VPN session
• dev-node 'OpenVPN TAP-Windows2' – bind an OpenVPN connection to a specific network interface (the name of the network adapter is specified)

The OpenVPN client binds to a specific interface when a connection is established. You can add the command to connect to OpenVPN to Windows startup. In addition, you can assign a static IP address to the OpenVPN client.

If you do not bind OVPN profiles to a specific network adapter, then when you try to create a second OpenVPN connection, an error may appear:

TCP/UDP: Socket bind failed on local address [undef]: Address already in use (WSAEADDRINUSE)

Note that when using multiple OpenVPN connections, the server must send you the route to its subnets via the push (you can’t:

Now your OpenVPN client will allow you to run two or more active VPN connections at the same time. On Linux, multiple VPN connections are allowed by default when connecting to OpenVPN from the terminal.

I don’t have the tap-windows folder.
Is a separate download and installer?

Глава 6. “Режим клиент/сервер” с tap-устройствами

Другая модель развертывания для OpenVPN является — один сервер с несколькими удаленными клиентами, способных к маршрутизации трафика Ethernet. Мы называем эту модель развертывания режимом клиент-сервер с tap-устройствами.

Основное различие между режимами tun и tap заключается в типе используемого адаптера. tap-адаптер обеспечивает полностью виртуальный интерфейс Ethernet (уровень 2), в то время как адаптер tun рассматривается большинством операционных систем как двухточечный (уровень 3).

Компьютеры, подключенные с использованием (виртуальных) адаптеров Ethernet, могут образовывать единый широковещательный домен, который необходим для определенных приложений. С двухточечными адаптерами это невозможно. Также обратите внимание, что не все операционные системы поддерживают tap-адаптеры. Например, iOS и Android поддерживают только tun-устройства.

В этой главе мы начнем с базовой настройки клиент-сервер, которая очень похожа на базовую настройку, описанную в Главе 4, Режим клиент-сервер с tun-устройствами. Однако существуют тонкие различия, которые будут обсуждаться на нескольких примерах. Кроме того, режим tap включает настройку мостового соединения, при котором обычный сетевой адаптер соединяется с виртуальным tap-адаптером. Эта тема будет подробно обсуждаться как для операционных систем Linux, так и для Windows.

В этой главе будут рассмотрены следующие темы:

• Базовая настройка
• Включение клиент-клиентского трафика с использованием pf
• Bridging
• Соединение в Linux
• Соединение в Windows
• Использование внешнего DHCP-сервера
• Проверка широковещательного и не IP-трафика
• Сравнение режима Tun с режимом Tap

Базовая настройка

Базовая настройка OpenVPN в режиме tap практически такая же, как и в режиме tun. В режиме tap мы используем следующую строку в файле конфигурации сервера:

В режиме tun мы используем следующие строки:

Опция topology subnet не требуется, но представляет схему сетевой адресации, которая является более разумной и будет использоваться по умолчанию в будущей версии OpenVPN.

Для полноты картины сначала создадим файл конфигурации сервера:

Мы будем использовать этот основной файл конфигурации сервера в режиме tap в этой главе и других. Сохраните его как tap-udp-server.conf , чтобы мы могли использовать его позже.

Заметка

Параметр topology subnet был удален, поскольку параметр topology является параметром конфигурации, специфичным для tun. В режиме tap сервер всегда раздает каждому клиенту по одному IP-адресу с соответствующей маской сети.

Точно так же мы создаем файл конфигурации клиента, который снова почти идентичен файлу basic-udp-client.conf из главы 4, Режим клиент/сервер с устройствами tun:

Сохраните этот файл как tap-udp-client.conf . Аналогично, для клиентов Windows создайте файл конфигурации tap-udp-client.ovpn .

Запустите сервер OpenVPN и подключите клиент, используя эти файлы конфигурации. Журнал соединений на стороне сервера покажет некоторые тонкие различия по сравнению с настройкой в режиме tun, которые выделены в следующем разделе:

Последняя строка журнала подключения к серверу — самая интересная: строка MULTI: Learn показывает, что сервер теперь использует MAC-адрес удаленного клиента, чтобы отличать его от других клиентов, тогда как в режиме tun он может полагаться исключительно на IP-адрес, назначенный клиенту. Это необходимо, так как клиент на основе tap может также отправлять не-IP трафик, в котором не используется IP-адрес.

Включение клиент-клиентского трафика

Когда к серверу подключено несколько клиентов виртуальной частной сети (VPN) — им не разрешается обмениваться трафиком. Это верно как для режима tap, так и для режима tun. Чтобы включить трафик между клиентами, есть два варианта:

• Использование параметра конфигурации client-to-client . Он позволяет OpenVPN обрабатывать трафик клиент-клиент внутри системы, минуя таблицы системной маршрутизации, а также правила системного брандмауэра/iptables.
• Использование системной таблицы маршрутизации и правил брандмауэра/iptables для отправки трафика от одного клиента другому и обратно.

Первый вариант — самый быстрый как с точки зрения конфигурации, так и с точки зрения производительности. Если нет ограничений на трафик между VPN-клиентами — добавьте строку client-to-client в файл конфигурации tap-udp-server.conf , сохраните его как movpn-06-01-server.conf и перезапустите сервер OpenVPN, используя этот файл конфигурации:

Переподключите VPN-клиентов. Первому клиенту назначен IP-адрес 10.222.0.2, а второму — 10.222.0.3. Теперь клиенты могут связаться друг с другом:

Высокая задержка (то есть время проверки связи более 300 мс) на предыдущем снимке экрана немедленно показывает один из недостатков использования трафика клиент-клиент по VPN. Весь трафик проходит через сервер OpenVPN, таким образом, пинг от client1 к client2 занимает больше времени:

1. Сообщение запроса ping отправляется с client1 на сервер OpenVPN.
2. Сервер OpenVPN пересылает сообщение на client2 .
3. client2 отправляет обратно ответное сообщение ping снова на сервер.
4. Сервер OpenVPN пересылает ответ ping обратно на client1 .

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

Фильтрация трафика между клиентами

Недостатком опции client-to-client является отсутствие фильтрации. Когда эта опция добавлена, весь трафик между всеми клиентами разрешен в обход правил системного брандмауэра/iptables.

Вторым способом обеспечения прохождения трафика между клиентами является использование таблиц маршрутизации системы. В режиме tun это сделать довольно просто, но немного сложнее при использовании режима tap. Когда client1 желает связаться с client2 , он сначала должен знать MAC (аппаратный) адрес client2 . Запрос ARP отправляется через адаптер tap клиента и достигает сервера OpenVPN. Серверный процесс OpenVPN перенаправляет ARP-запрос из своего собственного tap-адаптера и ожидает ответа. Однако ответ должен прийти от другого VPN-клиента, который подключен к тому же адаптеру. Таким образом — ARP-запрос должен быть отправлен обратно всем подключенным клиентам сервера OpenVPN. Обычно повторная выдача ARP-запроса не выполняется и трафик клиент-клиент терпит неудачу.

В современных ядрах Linux (2.6.34+ или в ядрах с опциями обратного переноса) для каждого интерфейса может быть установлен специальный флаг proxy_arp_pvlan . Этот флаг указывает ядру Linux повторно отправить ARP-запрос обратно с того же интерфейса, откуда он поступил. Именно этот флаг необходим для работы трафика клиент-клиент. Таким образом мы включаем трафик клиент-клиент в режиме tap, не используя опцию client-to-client , устанавливая этот флаг:

Заметка

Этот системный флаг можно установить только после настройки адаптера tap0. Адаптер tap может быть создан до запуска OpenVPN (см. Раздел Мостовое соединение в Linux) или флаг может быть установлен после запуска OpenVPN. В этом случае, он может быть установлен автоматически с использованием скрипта, как описано в Главе 7, Скрипты и плагины.

Когда client1 хочет связаться с client2 — поток сетевого трафика с этим установленным флагом выглядит следующим образом:

1. client1 отправляет запрос ARP из своего tap-адаптера.
2. Сервер OpenVPN получает ARP-запрос и перенаправляет его из собственного адаптера tap0.
3. ARP-запрос проходит через системную маршрутизацию и таблицу пересылки iptables.
4. Если запрос разрешен — он отправляется всем сетевым интерфейсам на сервере OpenVPN, включая адаптер tap0, откуда был отправлен. Последнее вызвано флагом proxy_arp_pvlan .
5. OpenVPN получает ARP-запрос и перенаправляет его всем подключенным клиентам OpenVPN.
6. client2 получает запрос и отвечает. ARP-ответ теперь отправляется обратно на сервер OpenVPN.
7. Сервер OpenVPN пересылает ARP-ответ client1 .
8. client1 теперь знает, где найти client2 и может отправлять сетевой трафик client2 .

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

Обратите внимание, что блокируя трафик в одном направлении, оба клиента не смогут связаться друг с другом. Для однонаправленной блокировки требуются более продвинутые правила iptables .

Заметка

Нет эквивалента для флага proxy_arp_pvlan в операционных системах Windows или Mac OS, но это неточно.

Недостаток метода proxy_arp_pvlan

Основным недостатком использования этого флага ядра является то, что он не превращает VPN в один широковещательный домен Ethernet. С флагом proxy_arp_pvlan клиенты VPN могут связываться друг с другом с помощью ARP-сообщений. Однако они не будут получать широковещательный трафик, приходящий от других клиентов. Когда используется опция client-to-client — все подключенные VPN-клиенты автоматически получают широковещательные сообщения друг друга, но фильтрация трафика сложнее (как мы увидим в следующем разделе).

Фильтрация трафика с использованием фильтра OpenVPN pf

Второй метод фильтрации трафика от клиентов OpenVPN — это использование встроенного фильтра OpenVPN pf . Этот фильтр также полностью поддерживается в OpenVPN Access Server — коммерческом предложении от OpenVPN Technologies Inc. Поддержка фильтра pf является элементарной по сравнению с большинством брандмауэров, но она полностью функциональна и доступна на всех платформах. Теперь мы пройдемся по шагам для использования этого фильтра в свободной версии OpenVPN. Этот пример приведен только в качестве доказательства концепции; станет ясно, что для обслуживания на уровне продакшена необходим другой подход и/или инструмент.

Чтобы использовать фильтр pf — должен использоваться интерфейс управления OpenVPN. Это достигается с помощью следующего файла конфигурации:

Сохраните этот файл как movpn-06-02-server.conf и запустите сервер OpenVPN. Сервер OpenVPN запросит (новый) пароль управления. Этот пароль будет использоваться для аутентификации всех соединений с интерфейсом управления; VPN-клиенты аутентифицируются отдельно. Параметр management-client-pf требует чтобы также был установлен параметр management-client-auth . Недостатком же является то, что теперь каждый клиент должен предоставить (поддельные) имя пользователя и пароль и каждому клиенту должен быть предоставлен доступ на стороне сервера с использованием интерфейса управления.

Файл конфигурации клиента теперь становится:

Сохраните его как movpn-06-02-client.conf (или movpn-06-02-client.ovpn для Windows).

На стороне сервера сначала запустите интерфейс управления, используя telnet :

Затем запустите клиент OpenVPN. Соединение с сервером не будет завершено пока клиенту не будет предоставлен доступ через интерфейс управления. В интерфейсе управления вы увидите это:

После получения всех строк >CLIENT авторизуйте клиента для подключения. Для этого требуются идентификатор клиента (CID) и идентификатор ключа (KID). Это параметры в самых первых строках >CLIENT при подключении клиента OpenVPN. В этом примере и CID, и KID равны 0 . Чтобы предоставить этот клиентский доступ, команда client-auth-nt CID KID должна быть введена в интерфейсе управления:

Первый клиент OpenVPN теперь имеет доступ. Теперь мы можем применить правила контроля доступа к этому клиенту, используя команду client-pf CID . Это многострочная команда. После первой строки мы сначала указываем подсети, к которым этому клиенту разрешен доступ:

Мы предоставляем клиенту доступ ко всем подсетям, кроме 10.0.0.0/8.

Далее мы указываем, к каким клиентам этот клиент может обратиться:

Мы разрешаем клиенту связываться со всеми другими клиентами VPN, кроме клиента с именем сертификата /CN = client3 . С помощью двух операторов END , одного с квадратными скобками и одного — без, мы закрываем команду client-pf :

Этот клиент OpenVPN теперь сможет обращаться ко всем подсетям на стороне сервера, кроме 10.0.0.0/8, и может связываться со всеми другими клиентами OpenVPN, кроме client3 .

У этого подхода много недостатков, но он работает на всех платформах. Основными недостатками являются следующие:

• Каждый клиент должен предоставить поддельное имя_пользователя/пароль
• Каждый клиент должен быть аутентифицирован с использованием интерфейса управления
• Для каждого клиента должен быть установлен фильтр pf
• Интерфейс управления в настоящее время не имеет команд для просмотра текущих фильтров

В настоящее время для свободной версии OpenVPN нет инструмента для отправки этих команд в интерфейс управления. Однако коммерческое программное обеспечение OpenVPN Access Server обеспечивает необходимый механизм для применения правил фильтрации.

Использование устройства tap (мост)

Особый вариант использования конфигурации на основе tap — мостовое соединение. Термин мостовое соединение применяется к функции операционной системы для соединения двух сетевых адаптеров вместе. Когда два (или более) адаптера соединены мостом — весь трафик Ethernet, полученный на одном из адаптеров, перенаправляется на все остальные адаптеры, которые являются частью этого моста. Это позволяет объединить (соединить) два сегмента сети вместе и создать впечатление что это один широковещательный домен Ethernet. Типичные случаи использования мостов:

• Клиенты VPN должны быть полностью и прозрачно интегрированы в LAN на стороне сервера. Обратите внимание, что тот же эффект часто может быть достигнут с помощью настройки proxy-arp .
• Некоторые старые компьютерные игры разрешают многопользовательские игры только тогда, когда все компьютеры являются частью одного и того же широковещательного домена.
• Некоторые устаревшие сетевые протоколы, особенно оригинальный протокол Microsoft NetBIOS (не основанный на TCP/IP), не работают должным образом на сетевых маршрутизаторах или даже предполагают полностью «плоское» сетевое пространство со всеми клиентами, подключенными напрямую.

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

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

К сожалению, до сих пор распространено заблуждение что для использования общего доступа к файлам Windows через установку OpenVPN необходимо использовать мосты. В разделе Включение общего доступа к файлам через VPN в Главе 5, Расширенные сценарии развертывания в туннельном режиме, подробное объяснение дается о том, как достичь общего доступа к файлам с помощью tun-установки и сервера WINS.

В некоторых случаях мостовая установка остается желательной или необходимой. Теперь мы покажем, как настроить мостовую конфигурацию OpenVPN на платформах Linux и Windows.

Соединение в Linux

Рассмотрим следующую схему сети:

На стороне сервера используется сетевой мост между адаптером LAN eth0 и виртуальным адаптером OpenVPN tap. В Linux это достигается созданием адаптера tap до запуска OpenVPN. Для этого должен быть установлен системный пакет bridge-utils . Шаги следующие:

1. Сначала мы создаем скрипт для запуска сетевого моста:

1. Сохраните его как movpn-bridge-start и убедитесь, что он исполняется с помощью следующей команды:

1. Затем запустите мост, используя следующую команду:

1. Теперь мы создаем файл конфигурации для мостовых настроек, используя следующие команды:

1. Сохраните его как movpn-06-03-server.conf . Аргументами к server-bridge являются сетевой шлюз, маска подсети, начало пула и конец пула. Адреса пула — это адреса, которые могут быть назначены клиентам.

Заметка

Строка dev tap0 в предыдущем примере имеет решающее значение для работы мостового соединения. Мы создали адаптер tap для моста до запуска OpenVPN. Чтобы использовать этот адаптер — мы должны явно указать имя адаптера. В противном случае OpenVPN создаст новый адаптер без моста при запуске.

1. Запустите сервер OpenVPN и подключите клиента с помощью файла конфигурации tap-udp-client.conf , созданного ранее в этой главе. На клиенте Linux в журнале подключений будет показано следующее:

Клиенту назначается первый адрес — 192.168.122.128 из пула доступных адресов.

1. Наконец, мы проверяем, что можем достичь хоста в локальной сети на стороне сервера:

Разрыв моста

Когда процесс сервера OpenVPN останавливается — сетевой мост также не отключается автоматически. Поскольку мост был создан до запуска самого OpenVPN — он сохраняется до тех пор, пока не будет разорван вручную. Следующие команды останавливают и удаляют мост, созданный командой movpn-start-bridge :

Соединение в Windows

Рассмотрим следующую схему сети:

Единственная разница между предыдущим сетевым макетом и этим — выбор используемых IP-адресов.

В Windows адаптер OpenVPN TAP-Win устанавливается при установке самого OpenVPN. Обычно имя для адаптера TAP-Win назначается операционной системой и будет примерно таким же, как для Подключение по локальной сети 4. Аналогично имя адаптера Ethernet, к которому подключена локальная сеть, также будет иметь имя подобное Подключение по локальной сети 2.

Для ясности (и некоторого здравого смысла) мы хотим переименовать интерфейс VPN (TAP):

1. Сначала мы идем в Центр управления сетями и общим доступом, а затем Изменение параметров адаптера.
2. Переименуйте адаптер TAP-Win как tapbridge щелкнув по нему правой кнопкой мыши и выбрав Переименовать. На используемом тестовом компьютере адаптер Ethernet, подключенный к локальной сети, был переименован в eth0. В столбце Состояние укажите сетевую группу, к которой принадлежит интерфейс. В нашем случае он принадлежит TheShire.
3. Выберите два адаптера, которые необходимо соединить, зажав клавишу Ctrl и щелкнув по каждому адаптеру, а затем щелкнув правой кнопкой мыши и выбрав Настройка моста.

1. Убедитесь, что вновь созданный Сетевой мост является частью той же сети, что и исходный адаптер eth0. Вы также можете видеть что оригинальный сетевой адаптер теперь имеет метку Мост в поле Состояние:

1. Нет необходимости настраивать статический IP-адрес для моста. Сетевой мост имеет свой собственный (виртуальный) MAC-адрес (или Физический адрес на следующем скриншоте) и, следовательно, ему присваивается свой собственный IP-адрес DHCP-сервером в локальной сети на стороне сервера:

1. Создайте файл конфигурации сервера OpenVPN с помощью текстового редактора или Блокнота:

Сохраните файл конфигурации как movpn-06-04-server.ovpn в каталоге конфигурации OpenVPN (обычно это C:\Program Files\OpenVPN\config ).

Заметка

Файл конфигурации сервера для версии OpenVPN для Windows аналогичен файлу конфигурации для Linux. Основными отличиями являются полные пути к файлам сертификатов и ключей, а также способ указания адаптера TAP-WIN с помощью ключевых слов dev и dev-node . Также обратите внимание, что параметры user/group и daemon/logging были удалены.

1. Запустите сервер OpenVPN (с повышенными привилегиями):

Обратите внимание, что версия OpenVPN для Windows в командной строке выглядит и ведет себя почти так же, как версия для командной строки Linux.

1. Брандмауэр Windows отобразит предупреждение безопасности, когда OpenVPN попытается настроить VPN. Нажмите Разрешить доступ, чтобы предоставить разрешение OpenVPN для настройки VPN как показано на следующем снимке экрана:

1. Если мы вернемся к экрану Настройки адаптера — теперь мы видим что и адаптер локальной сети eth0 и адаптер TAP-Win tapbridge в состоянии Включен и имеют статус Мост. Это показано на следующем снимке экрана:

Затем подключите клиент Windows с помощью файла конфигурации tap-udp-client.ovpn , созданного ранее в этой главе. Клиенту будет назначен первый адрес — 192.168.3.128 из пула доступных адресов.

Наконец, мы проверяем, что можем достичь хоста в локальной сети на стороне сервера:

1. На сервере нажмите функциональную клавишу F4 в командном окне для остановки процесса сервера OpenVPN. Для настройки производственного уровня желательно запускать и останавливать OpenVPN с помощью службы OpenVPN, устанавливаемой вместе с OpenVPN.

Использование внешнего DHCP-сервера

В мостовой конфигурации можно еще больше интегрировать клиентов в серверную сеть. В большинстве сетей для назначения IP-адресов используется DHCP-сервер. Обычно OpenVPN назначает IP-адреса своим клиентам с помощью одной из следующих команд:

Или с помощью следующей команды:

Также можно использовать внешний DHCP-сервер для назначения адресов клиентам OpenVPN. Для этого просто удалите спецификацию любых диапазонов IP-адресов после параметра server-bridge как показано в следующем (ориентированном на Linux) файле конфигурации:

Сохраните его как movpn-06-05-server.conf и запустите сервер OpenVPN.

Когда клиент подключается и запрашивает IP-адрес с помощью DHCP — запрос будет перенаправлен на сервер DHCP в локальной сети на стороне сервера. DHCP-сервер назначает адрес, который отправляется обратно клиенту через сервер OpenVPN.

На клиенте OpenVPN это можно проверить, посмотрев IP-адрес соединения vpn0 :

Чтобы убедиться, что этот адрес был назначен сервером DHCP на стороне сервера, мы проверяем таблицу клиентов DHCP на сервере DHCP:

Третья запись в DHCP Client Table на предыдущем скриншоте содержит MAC Address адаптера TAP-Win клиента OpenVPN. Это доказывает, что серверный DHCP-сервер назначил адрес клиенту OpenVPN.

Проверка широковещательного и не IP-трафика

Инструменты tcpdump и wireshark полезны для устранения неполадок в “почти работающей” настройке OpenVPN. Wireshark доступен для Linux, Mac OS X и Windows. Его можно использовать как инструмент командной строки, но чаще всего используется версия на основе графического интерфейса. На большинстве Unix/Linux-платформ также доступен инструмент командной строки tcpdump.

Теперь мы будем использовать tcpdump и wireshark для просмотра потока пакетов через установку VPN на основе tap.

Протокол разрешения адресов трафика

Одним из самых основных типов трафика Ethernet, присутствующего во всех сетях, является трафик протокола разрешения адресов (ARP). ARP является ярким примером протокола Ethernet, который не передается по двухточечным каналам связи (например, при настройке OpenVPN на основе туннеля). Физический уровень (уровень 1) обычно представляет собой электрическую или оптическую связь между системами. В случае VPN — туннель занимает место этого физического соединения. Следующим шагом в модели OSI является уровень Ethernet (уровень 2). Протокол ARP часто используется для обнаружения других систем на этом уровне.

Подсказка

Ethernet является сетевым протоколом уровня 2, а точка-точка — сетевым протоколом уровня 3. Различные уровни протокола определяются моделью Open Systems Interconnection (OSI).

Чтобы наблюдать за потоком ARP-трафика мы сначала запускаем сервер OpenVPN, используя ранее созданный файл конфигурации movpn-06-01-server.conf . Затем подключаем двух клиентов Linux к серверу. После того, как все соединения были успешно установлены — мы запускаем tcpdump на одном из клиентов:

Теперь мы отправляем один пакет ping от одного клиента — другому и смотрим на вывод tcpdump :

На снимке экрана показан трафик ARP между client1 (в данном случае 10.200.0.10) и client2 (10.200.0.11).

• Первый пакет в выводе выше от клиента, которым был инициирован ping . Клиент должен знать Ethernet MAC-адрес компьютера, который мы проверяем, и, следовательно, он отправляет запрос ARP.
• Поскольку мы указали client-to-client в файле конфигурации сервера movpn-06-01-server.conf — ARP-запрос пересылается всем подключенным клиентам и второй клиент OpenVPN отвечает своим MAC-адресом.
• Второй пакет — это ответ от второго клиента, указывающий его собственный MAC-адрес.
• Теперь, когда адрес известен, client1 отправляет ping . Он отображается как IPv4 ICMP echo request .
• Ответ получен от второго клиента. Это четвертый пакет ( IPv4 ICMP echo reply ).

Трафик NetBIOS

Common Internet File Sharing (CIFS) начинался как закрытый протокол NetBEUI. Поддержка совместного использования файлов и принтеров осуществлялась через протокол Novell Internetwork Packet eXchange (IPX), а затем был добавлен протокол TCP/IP. В настоящее время протокол обмена файлами Windows развился и поддерживается только через TCP/IP. Поддержка устаревших файловых протоколов все еще присутствует в более старых версиях Windows и именно эту устаревшую поддержку мы будем использовать для запуска трафика не-IP.

Сначала мы устанавливаем и включаем транспортный протокол NWLink IPX/SPX на адаптере TAP-WIN. Затем мы подключаем клиента Windows к установке OpenVPN, которая была запущена с использованием файла конфигурации movpn-06-01-server.conf . В этой конфигурации включен client-to-client ; таким образом, все подключенные клиенты должны видеть весь широковещательный трафик Ethernet, поступающий от этого клиента.

Когда клиент Windows успешно подключится к VPN-серверу — он начнет отправлять трафик для объявления своего имени и другой информации об обмене файлами Windows. Он попытается сделать это через TCP/IP, но также с использованием сообщений IPX.

Мы используем Wireshark на втором VPN-клиенте и отслеживаем трафик на интерфейсе tap. На следующем снимке экрана показано, что Windows-клиент WINDOWSXP действительно отправляет широковещательный трафик NetBIOS через TCP/IP. Это записи с адресом источника 10.222.0.3 и адресом назначения 10.222.0.255. Последний адрес является широковещательным адресом TCP/IP для настроенной нами VPN. Мы также видим, что трафик передается по протоколу IPX. Этот трафик выбран и выделен на скриншоте:

Широковещательные сообщения IPX являются широковещательными сообщениями Ethernet, но они не основаны на IP. Это показывает, что установка OpenVPN в стиле tap с client-to-client разделяет весь трафик Ethernet, включая широковещательный трафик между подключенными клиентами (и самим сервером OpenVPN).

Сравнение режима tun с режимом tap

Как мы уже видели в этой главе — есть много сходств, но также есть и существенные различия между VPN в режиме tun и VPN в режиме tap. В этом разделе мы обсудим эти сходства и различия. Большинство различий проистекает из единственного факта что VPN в режиме tun является не широковещательной, а двухточечной IP-сетью, в то время как сеть в режиме tap обеспечивает полностью виртуальную Ethernet-подобную сеть с поддержкой широковещания. Короче говоря, сеть в режиме tun обеспечивает сетевое подключение уровня 3, тогда как сеть в режиме tap обеспечивает практически все функциональные возможности сети уровня 2.

Особенно с опцией topology subnet настройка на основе TUN напоминает установку без перемычек:

• Опция server 10.200.0.0 255.255.255.0 устанавливает VPN с адресом сервера 10.200.0.1. Каждый клиент получит один адрес из 24 IP-адресной адресации, начиная с 10.200.0.2.
• Способ шифрования VPN-трафика и цифровой подписи (HMAC) идентичен.
• Большинство возможностей сценариев применимы к обоим типам VPN. Однако есть некоторые тонкие различия в параметрах для сценария client-connect .
• При правильной настройке конечный пользователь не будет испытывать различий между настройкой на основе tun и VPN-подключением на основе tap.

Эти различия, конечно, гораздо интереснее обсуждать. Некоторые различия очевидны, но есть и некоторые тонкости, которые могут оказать существенное влияние при настройке VPN.

Слой 2 против слоя 3

В сети уровня 2 (т.е. в стиле tap) соседние клиенты могут связаться друг с другом узнав адрес соседа, используя широковещательные ARP-запросы. Широковещательные ARP-запросы позволяют клиентам обнаруживать MAC-адреса других клиентов. Это позволяет клиентам связываться друг с другом по протоколам IP и не-IP.

В сети уровня 3 (в стиле tun) клиенты могут связываться друг с другом только с помощью IP-адресов. MAC-адрес адаптера tun никогда не раскрывается другим VPN-клиентам и даже самому серверу OpenVPN. Из-за этого сетевой пакет уровня 3 немного короче, чем уровня 2. При нормальных обстоятельствах более длинные сетевые пакеты уровня 2 не оказывают негативного влияния на производительность.

Маршрутные различия и iroute

Когда особенно необходима маршрутизация от подсети к подсети между tun и tap есть некоторые существенные различия. В сети в стиле tun необходим файл конфигурации клиента с соответствующим оператором iroute чтобы позволить VPN-серверу получать доступ к клиентам, находящимся в локальной сети на стороне клиента. В качестве примера мы предполагаем, что подсеть 192.168.3.0/24 может быть достигнута через клиента OpenVPN с сертификатом CN=client1 . На сервере OpenVPN мы добавили бы файл client-config-dir с именем client1 , содержащий инструкцию:

И добавили бы системный маршрут в файл конфигурации сервера:

В настройке в стиле tap оператор iroute недопустим и будет просто игнорироваться сервером. Чтобы достичь подсети за VPN-клиентом необходимо добавить системный маршрут на сервере OpenVPN, а шлюз должен указывать на VPN-IP-адрес клиента. Давайте предположим, что для client1 из предыдущего примера назначен фиксированный IP-адрес. Это может быть достигнуто с помощью файла CCD:

В файле конфигурации сервера необходимо добавить маршрут, чтобы таблицы системной маршрутизации знали, что подсеть 192.168.3.0/24 может быть доступна через клиента 10.200.0.99:

Это гораздо менее динамично, чем опция режима tun route + iroute .

Фильтрация клиент-клиент

При настройке в стиле tun большая часть трафика может регистрироваться и фильтроваться с использованием правил брандмауэра или iptables. Фильтрация трафика между клиентами OpenVPN намного сложнее при настройке в режиме tap, как было показано ранее в этой главе.

Широковещание трафика и “болтливость” сети

Сеть уровня 3 не позволяет передавать широковещательный трафик по ней. Это и преимущество и недостаток. Некоторые клиент-серверные приложения полагаются на использование широковещательного трафика для связи между сервером и клиентами. Для таких приложений требуется сеть в стиле tap.

Однако широковещательный трафик также имеет тенденцию засорять сети. Даже если на клиенте нет действий пользователя — операционная система будет непрерывно отправлять широковещательный трафик для обнаружения сетевых ресурсов, соседей и т.д. Особенно, когда используются такие протоколы как Universal Plug-and-Play или Apple Bonjour существует много скрытого широковещательного трафика. Для клиентов, подключенных к VPN через сеть с низкой пропускной способностью — это может иметь серьезные последствия для производительности.

Ключевой особенностью сети в стиле tap является возможность создания мостов. Мостовое соединение невозможно в сети уровня 3.

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

Резюме

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

Мы также увидели, что расширенные функции управления, такие как фильтрация трафика между клиентами OpenVPN, гораздо сложнее реализовать в режиме tap по сравнению с режимом tun.

В следующей главе мы увидим, как можно использовать скрипты и плагины чтобы влиять на то, как сервер OpenVPN назначает IP-адрес клиенту, а также на многие другие функции. Скрипты и плагины могут использоваться как в режиме tap, так и в режиме tun.

Osvoenie-OpenVPN is maintained by translaster. This page was generated by GitHub Pages.