nlwt tun что это

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».

Параметры Диффи-Хеллмана

Здесь ничего дополнительно делать не придётся, но придётся подождать.

Этот файл нужен только на сервере.

Ключи клиентов

Каждому клиенту необходимо выдать свой ключ. Для клиента с именем client ключ создаётся командой

На вопрос о «Common Name» отвечаем именем клиента (в данном случае, client). На два вопроса в конце отвечаем согласием.

Настройка и запуск сервиса OpenVPN

Для запуска следует использовать следующую конфигурацию сервера (файл /etc/openvpn/openvpn.conf):

Ключ office.key должен иметь режим 600 (доступ только владельцу). Файлы office.crt и dh1024.pem имеют режим 644.

Настройка фильтрования

Поскольку мы используем мост, есть несколько особенностей организации фильтрования пакетов. Например, не все проходящие пакеты могут вообще оказаться IPv4. Для настройки работы моста в ядре существует несколько параметров:

Для фильтрования пакетов, проходящих через мост, используется соответствие 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/. В конфиге прописываем полный путь к ключу и сертификатам. Следите, чтобы имена файлов в конфиге не пересекались, во избежание неприятных эффектов!

Запуск и останов сети производятся через управление сервисом /etc/openvpn.network-name.

Windows

Конфигурационный файл помещается в директорию «C:\Program Files\OpenVPN\config\» с именем вроде «office.ovpn», туда же помещаются остальные файлы — ключи и сертификаты. Если мы их помещаем в поддиректорию (например, хотим использовать несколько виртуальных сетей и все они предоставили файлы с одинаковым именем ca.crt), указываем полные пути к файлам.

Возможные проблемы

Проверить доступность сервера, если он запущен на TCP, можно обычным telnetом.

Windows

Нет свободного виртуального адаптера TAP

По логу OpenVPN видно, что клиент успешно присоединился к серверу, авторизовался, но не смог привязать виртуальную сеть к виртуальному адаптеру. Скорее всего, какие-то другие процессы уже задествовали все имеющиеся в системе адаптеры TAP-Win32. Это мог быть и сам OpenVPN, повисший и не отдавший адаптер.

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

Источник

Виртуальный сетевой интерфейс в linux. TAP vs TUN

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

Создаем виртуальный интерфейс в linux вручную

Создавать и удалять интерфейсы, назначать IP и MAC адреса, изменять MTU и многое другое нам помогает утилита ip. Пользоваться ip удобно и легко, но помните, что произведенные изменения будут потеряны после перезагрузки компьютера. Используйте ip в целях тестирования.

Создаем интерфейс типа tun

ip tuntap add dev tun0 mode tun
ip address add 192.168.99.1/30 dev tun0
ip address show tun0
2: tun0:

mtu 1500 qdisc noop state DOWN group default qlen 500
link/none
inet 192.168.99.1/30 scope global tun0
valid_lft forever preferred_lft forever

ip link set dev tun0 master br0
RTNETLINK answers: Invalid argument

Создаем интерфейс типа tap

ip tuntap add dev tap0 mode tap
ip address add 192.168.99.5/30 dev tap0
ip address show tap0
3: tap0:
mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether d6:1c:67:cd:6f:80 brd ff:ff:ff:ff:ff:ff
inet 192.168.99.5/30 scope global tap0
valid_lft forever preferred_lft forever

У нас теперь появился новый виртуальный интерфейс с именем «tap0», у него есть как IP-адрес, так и MAC-адреса. Его также можно пинговать, и на нем также можно запускать слушающие сервисы. Команда, добавляющая интерфейс в бридж уже не выдаст ошибку, потому что это интерфейс, обладающий поддержкой ethernet:

ip link set dev tap0 master br0

Создаем интерфейс типа dummy

ip link add dev dum0 type dummy
ip address add 192.168.99.9/30 dev dum0
ip address show dum0
4: dum0:
mtu 1500 qdisc noop master br0 state DOWN group default qlen 1000
link/ether 1a:37:3b:0f:da:be brd ff:ff:ff:ff:ff:ff
inet 192.168.99.9/30 scope global dum0
valid_lft forever preferred_lft forever

Вы наверняка заметили, что команда для добавления интерфейса изменилась. Ничего необычного. Так написана утилита «ip». Ну и конечно, виртуальный интерфейс типа dummy можно легко добавить в бридж:

ip link set dev dum0 master br0

Создаем виртуальный интерфейс в linux с помощью systemd-networkd

В systemd-networkd за создание интерфейсов отвечают одни конфигурационные файлы, имеющие суффикс «.netdev», а за их настройку другие, имеющие суффикс «.network». Соответственно нам понадобиться в /etc/systemd/network создать по паре конфигурационных файлов для каждого из исследуемых типов интерфейсов

Создаем интерфейс типа tun

Создадим соответственно файлы tun0.netdev с содержимым:

[NetDev]
Name=tun0
Kind=tun

Создаем интерфейс типа tap

Создадим соответственно файлы tap0.netdev с содержимым:

[NetDev]
Name=tap0
Kind=tap

Создаем интерфейс типа dummy

Создадим соответственно файлы dum0.netdev с содержимым:

[NetDev]
Name=dum0
Kind=dummy

Стоит отметить, что если вы планируете маршрутизировать траффик через виртуальные интерфейсы ( а, используя их для цели создания виртуальных частных сетей (VPN), вы точно этого хотите), то в конфигурационный файл в секии «Network» следует добавить диррективу «IPForward=yes».

Источник

OpenVPN. Помогите сделать выбор между tun и tap и настроить шифрование.

1. L2 против L3
2. Это вообще какой-то бред

И вы, конечно, считаете, что дали полный, развернутый ответ, по которому я сразу закрою тему и пойду что-то делать?

поиск по форуму для кого сделан? в гугле чо не написал «tun vs tap»?

попробуй модный нынче SoftEtherVPN

и посмотри по tls-шифрование (кажись, так). Там доп. сертификат нужно сгенерить и прописать.

Херню написал. tun это туннель L3, tap это туннель L2, читай тоже поиск

Я считаю, что если ты не знаешь разницы между вторым и третьим уровнем в сети, то тебе уже ничем не поможешь.

Ты конечно это по запаху узнал?

1. Я обычно делаю tun по udp. С udp потерь пакетов не будет, т.к. проверка целостности производится на уровне шифрования.

Ох уж эти вэ-пэ-энщики. По-хорошему нужно спалить офис Циски за их тупые ПИХы, АСы и SSL VPN. Разработчиков же OpenVPN нужно при большом стечении народа сжечь током низкого напряжения. За то что свой тупорылый «хакирский» проект распиарили до помутнения сознания хомячковых масс во всем мире.

OpenVPN состоит из 3-х компонентов.

1. TUN/TAP подсистемы в ядре целевой ОС. Она позволяет подключить фронт-енд сетевой подсистемы не к бэк-енд драйверу (который осуществляет непосредственное общение с аппаратурой), а к юзерспейсной программе на уровне 2 (TAP) или уровне 3 (TUN). Т.е. создается «виртуальный сетевой интерфейс» с привязкой к управляющей утилите.

2. TLS. Феерическое творение широко известной корпорации Нетскейп (да-да, той самой). Представляет собой юзерспейсную надстройку над socket API, для обеспечения безопасной передачи на транспортном уровне. Именно поэтому раньше называлось SSL, а после стандартизации в IETF — TLS. Раньше работало исключительно через TCP, с недавних пор — может работать через UDP.

3. Раздутого ЧСВ и феерического идиотизма.

Ясен пень, феерическая идея соединить через сеть две юзерспейсные tun/tap программы витала в воздухе. И конечно же, прийти могла исключительно в тупую бошку школьника-хакира. Не, чисто с хакерской точки зрения идея классная: хошь трафик снифь, хошь свой мегафайрвол делай, хошь шифруй. Но только конченому ублюдку могла в голову прийти идея использовать подобную конфигурацию в условиях реальных сетей.

И даже целый базис под это подвели: мол нехватка адресов, мол NAT, мол простая конфигурация.

Первые версии OpenVPN работали через TCP. Т.е. в TCP пихался еще один IP+TCP. Режим работы называется «тупняк на канале». Особые извращенцы пихали еще и Ethernet+IP+TCP. Этот режим работы называется «и еще прощай MTU».

Когда в OpenSSL таки запилили поддержку DTLS, появилась возможность работы через UDP.

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

Решение, было моментально найдено: пышным цветом расцвели Цитриксы и прочие Терминал серверы. А какой базис под это дело подвели маркетоиды. У-у-у-у. Опенвпнщикам и не снилось.

Короче говоря, слушай сюда. Звонишь своему провайдеру: «Я хочу Ethernet порт от точки А до точки Б». По полученному порту пускаешь IPSec в транспортном режиме. Если хочется чего-то попроще, то stunnel, но учти что он имеет тенденцию тупить на хреновых каналах. Профит.

В последних версиях можно вытащить веб-морду 1С по TLS с аутентификацией по клиентским сертификатам.

И делай мне и себе одолжение: не терпи и не нищебродствуй. 90% российского ИТ состоит из терпил и нищебродов, из-за чего находится в полной ж.

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

Источник

Знакомство с виртуальными интерфейсами Linux: туннели

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

Здесь будут рассмотрены следующие часто используемые интерфейсы: IPIP, SIT, ip6tnl, VTI и VTI6, GRE и GRETAP, GRE6 и GRE6TAP, FOU, GUE, GENEVE, ERSPAN и IP6ERSPAN.

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

Туннель IPIP, как можно понять из его названия — это туннель, работающий в режиме «IP over IP» (RFC 2003). Заголовок пакета туннеля IPIP выглядит так, как показано ниже.

Заголовок пакета туннеля IPIP

Такие туннели обычно используются для соединения двух внутренних IPv4-подсетей через общедоступную IPv4-сеть (интернет). Применение IPIP создаёт минимальную дополнительную нагрузку на систему, но по такому туннелю можно выполнять только однонаправленную передачу данных (unicast). То есть, построив подобный туннель, нельзя будет использовать его для групповой передачи данных (multicast).

IPIP-туннели поддерживают режимы «IP over IP» и «MPLS over IP».

Вот как создать IPIP-туннель:

SIT (Simple Internet Transition) — это технология создания туннелей, главной целью существования которой является соединение изолированных IPv6-сетей через интернет с использованием протокола IPv4.

Режим any используется для работы с IP- и IPv6-трафиком, что может оказаться полезным в некоторых ситуациях. SIT-туннели также поддерживают ISATAP. Вот пример использования этой технологии.

Заголовок SIT-пакета выглядит так, как показано ниже.

Заголовок пакета туннеля SIT

Вот как создать SIT-туннель (эти действия надо выполнить на серверах A и B):

Ip6tnl

Интерфейс ip6tnl работает в режиме «IPv4/IPv6 over IPv6». Он похож на IPv6-версию туннеля SIT. Вот как выглядит заголовок пакета ip6tnl.

Заголовок пакета туннеля ip6tnl

Вот как создать туннель ip6tnl:

VTI и VTI6

Интерфейс VTI (Virtual Tunnel Interface) в Linux похож на интерфейс VTI Cisco и на Juniper-реализацию защищённого туннеля (st.xx).

Этот драйвер туннелирования реализует IP-инкапсуляцию, что может быть использовано с xfrm для создания защищённых туннелей и для последующего использования поверх таких туннелей маршрутизации уровня ядра.

В целом, VTI-туннели работают почти так же как туннели IPIP или SIT. Исключением является то, что они задействуют fwmark и инкапсуляцию/декапсуляцию IPsec.

VTI6 — это IPv6-эквивалент VTI.

Вот как создать VTI-туннель:

Кроме того, конфигурировать IPsec можно с помощью libreswan или strongSwan.

GRE и GRETAP

Технология GRE (Generic Routing Encapsulation) описана в RFC 2784. При GRE-туннелировании между заголовками внутреннего и внешнего IP-пакета добавляется дополнительный заголовок GRE.

Теоретически, GRE может инкапсулировать пакеты любого протокола 3 уровня с допустимым Ethernet-типом. Это отличает технологию GRE от технологии IPIP, которая поддерживает лишь инкапсуляцию IP-пакетов. Вот как выглядит заголовок пакета при использовании технологии GRE.

Заголовок пакета туннеля GRE

Обратите внимание на то, что туннели GRE позволяют выполнять групповую передачу данных и поддерживают IPv6.

Вот как создать туннель GRE:

В то время как туннели GRE работают на 3 уровне модели OSI, туннели GRETAP работают на 2 уровне OSI. Это означает, что одними из внутренних заголовков соответствующих пакетов являются Ethernet-заголовки.

Заголовок пакета туннеля GRETAP

Вот как создать туннель GRETAP:

GRE6 и GRE6TAP

GRE6 — это IPv6-эквивалент GRE. Туннели GRE6 позволяют инкапсулировать любые протоколы 3 уровня в IPv6. Вот как выглядит заголовок пакета GRE6.

Заголовок пакета туннеля GRE6

В туннелях GRE6TAP, как и в туннелях GRETAP, среди внутренних заголовков пакета есть и Ethernet-заголовки.

Заголовок пакета туннеля GRE6TAP

Вот как создать туннель GRE:

Туннелирование может выполняться на разных уровнях сетевого стека. Туннели IPIP, SIT и GRE существуют на уровне IP. А туннели FOU (они устроены по схеме «foo over UDP») работают на уровне UDP.

В применении UDP-туннелирования есть некоторые преимущества перед IP-туннелированием. Дело в том, что протокол UDP работает с существующей аппаратной инфраструктурой.

Например, это RSS в сетевых картах, ECMP в коммутаторах, это технологии расчёта контрольных сумм без участия центрального процессора. Применение соответствующего FOU-патча для разработчиков показывает значительное увеличение производительности для протоколов SIT и IPIP.

В настоящее время FOU-туннели поддерживают инкапсуляцию протоколов на основе IPIP, SIT и GRE. Вот как может выглядеть заголовок FOU-пакета.

Заголовок пакета туннеля FOU

Вот как создать туннель FOU:

Обратите внимание на то, что FOU-туннели не поддерживаются в Red Hat Enterprise Linux.

Ещё одна разновидность UDP-туннелирования представлена технологией GUE (Generic UDP Encapsulation). Разница между FOU и GUE заключается в том, что у GUE имеется собственный заголовок, который содержит сведения о протоколе и другие данные.

В настоящее время туннели GUE поддерживают внутреннюю инкапсуляцию IPIP, SIT и GRE. Вот как может выглядеть заголовок GUE-пакета.

Заголовок пакета туннеля GUE

Вот как создать GUE-туннель:

Благодаря этим командам будет создан принимающий GUE-порт для IPIP, привязанный к номеру 5555, и IPIP-туннель, настроенный на GUE-инкапсуляцию.

GUE-туннели не поддерживаются в Red Hat Enterprise Linux.

GENEVE

Туннели GENEVE (Generic Network Virtualization Encapsulation) поддерживают все возможности XLAN, NVGRE и STT. Технология GENEVE спроектирована с учётом обхода выявленных ограничений этих трёх технологий. Многие считают, что данная технология способна, в перспективе, полностью заменить эти три более старых формата. Вот как выглядит заголовок пакета туннеля GENEVE.

Заголовок пакета туннеля GENEVE

Этот заголовок похож на заголовок VXLAN-пакета. Основное различие между ними заключается в том, что заголовок GENEVE является более гибким. Он позволяет очень легко реализовывать новые возможности путём расширения заголовков с помощью полей Type-Length-Value (TLV).

Подробности о GENEVE можно узнать здесь и здесь.

GENEVE используется в SDN-решении Open Virtual Network (OVN) как стандартное средство инкапсуляции. Вот как создать туннель GENEVE:

ERSPAN и IP6ERSPAN

Технология ERSPAN (Encapsulated Remote Switched Port Analyzer) использует GRE-инкапсуляцию для расширения базовых возможностей по зеркалированию портов со 2 уровня до 3 уровня. Это позволяет пересылать зеркалируемый трафик по маршрутизируемой IP-сети. Вот как выглядит заголовок пакета ERSPAN.

Заголовок пакета туннеля ERSPAN

Туннели ERSPAN позволяют Linux-хостам действовать в роли источника трафика ERSPAN и отправлять отзеркалированный ERSPAN-трафик либо на удалённый хост, либо в некий пункт назначения ERSPAN, который принимает и обрабатывает ERSPAN-пакеты, сгенерированные коммутаторами Cisco или другими устройствами, поддерживающими ERSPAN. Подобную систему можно использовать для анализа и диагностики сети, для выявления вредоносного трафика.

Linux в настоящее время поддерживает большинство возможностей двух версий ERSPAN — v1 (type II) и v2 (type III).

Вот как создавать ERSPAN-туннели:

Ещё можно поступить так:

Добавим tc-фильтр для мониторинга трафика:

Итоги

Мы рассмотрели здесь довольно много технологий создания туннелей в Linux. Вот сводная таблица по ним.

Обратите внимание на то, что все туннели, примеры создания которых здесь показаны, существуют только до перезагрузки сервера. Если вы хотите создать туннель, восстанавливающийся и после перезагрузки, рассмотрите возможность использования демона для настройки сети, наподобие NetworkManager, или примените подходящий механизм из используемого вами дистрибутива Linux.

Уважаемые читатели! Какими Linux-туннелями вы пользуетесь?

Источник