Виртуальные сетевые интерфейсы linux

Создание и настройка виртуальных сетевых интерфейсов в Linux

1. Введение

Знаете ли вы, что можете присвоить более чем один IP-адрес физическому сетевому интерфейсу? Эта техника очень полезна, например при работе с Apache и виртуальными хостами, так как позволяет получить доступ к одному и тому же серверу Apache с двух разных IP-адресов.

2. Временный виртуальный сетевой интерфейс

Процесс создания виртуального сетевого интерфейса в Linux не занимает много времени. Он включает один запуск команды ifconfig.

Приведенная выше команда создает виртуальный сетевой интерфейс, базирующийся на оригинальном физическом сетевом интерфейсе eth0. Самое важное условие для создания виртуального сетевого интерфейса — должен существовать физический сетевой интерфейс, в нашем случае eth0. Ниже приведен полный пример:

Теперь мы можем настроить новый виртуальный интерфейс на базе eth0. После выполнения команды ifconfig новый виртуальный интерфейс готов к немедленному использованию.

2.1. Отключение виртуального сетевого интерфейса

Для отключения нашего, созданного ранее, временного сетевого интерфейса мы можем также использовать команду ifconfig с флагом down.

3. Присвоение виртуальному интерфейсу постоянного адреса

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

3.1. Debian / Ubuntu

3.1.1. Статический адрес

В Debian или Ubuntu вам необходимо отредактировать файл /etc/network/interfaces, добавив в него следующие строки:

3.1.2. Dhcp

Возможно также использовать витруальный сетевой интерфейс с DHCP. В этом случае вам необходимо добавить в /etc/network/interfaces следующую строку:

Для того, чтобы изменения вступили в силу, необходимо перезапустить сеть:

3.2. Redhat / Fedora / CentOS

3.2.1. Статический адрес

В Redhat, Fedora или CentOS Linux директория, отвечающая за присвоение постоянных IP-адресов — это /etc/sysconfig/network-scripts. В этой директории необходимо создать файл, соответствующий вашему новому виртуальному интерфейсу. В нашем случае этот файл будет называться ifcfg-eth0:0. Создайте этот новый файл и вставьте в него приведенные ниже строки. После перезагрузки адрес будет присвоен виртуальному интерфейсу на постоянной основе.

3.2.2. Dhcp

Когда закончите, перезапустите ваши интерфейсы:

4. Заключение

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

Источник

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

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

Создавать сетевые интерфейсы в linux нам позволяют различные модули ядра. Но там, где для реальных железных сетевых карт эти модули ядра, или как их еще называют — драйверы, обеспечивают прием данных от стека TCP/IP и их формирование уже в виде электрического сигнала на сетевой карте, драйверы виртуальных сетевых интерфейсов (loopback) могут лишь, приняв эти данные, отдать их какому-нибудь приложению для дальнейшей обработки. Такая функциональность может быть востребована, если на вашем сервере установлены программы, использующие стек TCP/IP для обмена данными и, понятно, не нуждающиеся в выводе этих данных в реальную сеть. Пример: веб-сайт на drupal связывается с базой данных, установленной на этом же сервере:

Другим распростаренным примером использования виртуальных сетевых интерфейсов (loopback) в linux может быть их использование для целей построения виртуальных частных сетей — VPN. Вы наверняка слышали о таких технологиях как OpenVPN, GRE, WireGuard и т.д. Каждый из этих демонов создает виртуальный сетевой интерфейс который служит для прозрачной маршрутизации данных между узлами, находящимися на удалении друг от друга и не имеющих возможности прямого взаимодействия. Рассмотрим общую сетевую топологию на примере OpenVPN:

От используемого драйвера зависит тип интерфейса, его скорость, допустимый размер MTU и т. д. Совсем даже не обязательно, что загружать драйвер в ядро вам придется самостоятельно. Скорее всего, создавая интерфейс нужного типа, система сама подберет и загрузит требуемый драйвер. Вам лишь останется сконфигурировать уже работающий loopback интерфейс. В данной статье мы рассмотрим 3 возможных на конец 2016 года типа виртуальных интерфейсов в linux: tun, tap и dummy. Отличие интерфейсов tun и tap заключается в том, что tap старается больше походить на реальный сетевой интерфейс, а именно он позволяет себе принимать и отправлять ARP запросы, обладает MAC адресом и может являться одним из интерфейсов сетевого моста, так как он обладает полной поддержкой ethernet — протокола канального уровня (уровень 2). Интерфейс tun этой поддержки лишен, поэтому он может принимать и отправлять только IP пакеты и никак не ethernet кадры. Он не обладает MAC-адресом и не может быть добавлен в бридж. Зато он более легкий и быстрый за счет отсутствия дополнительной инкапсуляции и прекрасно подходит для тестирования сетевого стека или построения виртуальных частных сетей (VPN). Виртуальный интерфейс типа dummy очень похож на tap, разница лишь в том, что он реализуется другим модулем ядра.

Создаем виртуальный интерфейс в 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

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

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

Команда ip логичным образом выдала ошибку — нет никакого смысла добавлять в бридж интерфейс, не обладающий поддержкой ethernet.

Создаем интерфейс типа 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».

Источник

Создание и настройка виртуальных сетевых интерфейсов в Linux

1. Введение

Знаете ли вы, что можете присвоить более чем один IP-адрес физическому сетевому интерфейсу? Эта техника очень полезна, например при работе с Apache и виртуальными хостами, так как позволяет получить доступ к одному и тому же серверу Apache с двух разных IP-адресов.

2. Временный виртуальный сетевой интерфейс

Процесс создания виртуального сетевого интерфейса в Linux не занимает много времени. Он включает один запуск команды ifconfig.

Приведенная выше команда создает виртуальный сетевой интерфейс, базирующийся на оригинальном физическом сетевом интерфейсе eth0. Самое важное условие для создания виртуального сетевого интерфейса — должен существовать физический сетевой интерфейс, в нашем случае eth0. Ниже приведен полный пример:

Теперь мы можем настроить новый виртуальный интерфейс на базе eth0. После выполнения команды ifconfig новый виртуальный интерфейс готов к немедленному использованию.

2.1. Отключение виртуального сетевого интерфейса

Для отключения нашего, созданного ранее, временного сетевого интерфейса мы можем также использовать команду ifconfig с флагом down.

3. Присвоение виртуальному интерфейсу постоянного адреса

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

3.1. Debian / Ubuntu

3.1.1. Статический адрес

В Debian или Ubuntu вам необходимо отредактировать файл /etc/network/interfaces, добавив в него следующие строки:

3.1.2. Dhcp

Возможно также использовать витруальный сетевой интерфейс с DHCP. В этом случае вам необходимо добавить в /etc/network/interfaces следующую строку:

Для того, чтобы изменения вступили в силу, необходимо перезапустить сеть:

3.2. Redhat / Fedora / CentOS

3.2.1. Статический адрес

В Redhat, Fedora или CentOS Linux директория, отвечающая за присвоение постоянных IP-адресов — это /etc/sysconfig/network-scripts. В этой директории необходимо создать файл, соответствующий вашему новому виртуальному интерфейсу. В нашем случае этот файл будет называться ifcfg-eth0:0. Создайте этот новый файл и вставьте в него приведенные ниже строки. После перезагрузки адрес будет присвоен виртуальному интерфейсу на постоянной основе.

3.2.2. Dhcp

Когда закончите, перезапустите ваши интерфейсы:

4. Заключение

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

Источник

Виртуальный сетевой интерфейс

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

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

Идея крайне проста: канализировать трафик уже существующего сетевого интерфейса во вновь создаваемый интерфейс с совершенно другими характеристиками (имя, IP, маска, подсеть, …). Один из способов выполнения таких действий в форме модуля ядра Linux мы и обсудим (он не единственный, но другие способы мы обсудим отдельно в другой раз).

О интерфейсах в пару слов

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

Сетевой интерфейс — это то место, где:

• по каждому принятому из интерфейса пакету создаются экземпляры структуры сокетных буферов (struct sk_buff), далее созданный экземпляр структуры продвигается по стеку протоколов вверх, до его получателя в пространстве пользователя, где он и уничтожается;
• порождённые где-то на верхних уровнях протоколов пользовательского пространства исходящие экземпляры структуры struct sk_buff должны быть отправлены, а сами экземпляры структуры после этого уничтожаются (или утилизируются в пул).

На протяжении, как минимум, 5-6 последних лет, сетевые интерфейсы неизменно создавались макросом:

Здесь (детали будут понятны из примера модуля):
— sizeof_priv — размер приватной области данных интерфейса (struct net_device), которая будет создана ядром без нашего прямого участия;
— name — символьная строка — шаблон имени интерфейса;
— setup — адрес функции инициализации интерфейса;

В таком, практически неизменном, виде процесс создания интерфейса описан везде в публикациях и упоминается в обсуждениях. Но начиная с ядра 3.17 прототип макроса создания интерфейса меняется (
):

Как легко видеть, теперь вместо 3-х параметров 4, 3-й из которых — константа, определяющая порядок нумерации создаваемых интерфейсов (исходя из шаблона имени), описанная в том же файле определений:

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

Но созданный так интерфейс ещё не дееспособен, он не выполняет никаких действий. Для того, чтобы «придать жизнь» созданному сетевому интерфейсу, нужно реализовать для него соответствующий набор операций. Вся связь сетевого интерфейса с выполняемыми на нём операциями осуществляется через таблицу операций сетевого интерфейса:

В ядре 3.09, например, определено 39 операций в struct net_device_ops, и около 50-ти операций в ядре 3.14, но реально разрабатываемые модули реализуют только малую часть из них.

Характерно, что в таблице операций интерфейса присутствует операция передачи сокетного буфера ndo_start_xmit() в физическую среду, но вовсе нет операции приёма пакетов (сокетных буферов). Это совершенно естественно, как мы увидим вскоре: принятые пакеты (например в обработчике аппаратного прерывания IRQ) непосредственно после приёма вызовом netif_rx() (или netif_receive_skb()) тут же помещаются в очередь (ядра) принимаемых пакетов, и далее уже последовательно обрабатываются сетевым стеком. А вот выполнять функцию ndo_start_xmit() — обязательно, хотя бы, как минимум, для вызова API ядра dev_kfree_skb(), который утилизирует (уничтожает) сокетный буфер после успешной (да и безуспешной тоже) операции передачи пакета. Если этого не делать, в системе возникнет слабо выраженная утечка памяти (с каждым пакетом), которая, в конечном итоге, рано или поздно приведёт к краху системы. Это ещё одна тонкость, которую держим в уме.

Последним необходимым нам элементом является структура struct net_device (описана в
) — описание сетевого интерфейса. Это крупная структура, содержащая не только описание аппаратных средств, но и конфигурационные параметры сетевого интерфейса по отношению к выше лежащим протоколам (пример взят из ядра 3.09):

Здесь поле type, например, определяет тип аппаратного адаптера с точки зрения ARP-механизма разрешения MAC адресов (
):

Со структурой сетевого интерфейса обычно создаётся и связывается приватная структура данных (упоминавшаяся ранее), в которой пользователь может размещать произвольные собственные данные любой сложности, ассоциированные с интерфейсом. Это особо актуально, если предполагается, что драйвер может создавать несколько однотипных сетевых интерфейсов. Доступ к приватной структуре данных должен определяться исключительно специально определённой для того функцией netdev_priv(). Ниже показан возможный вид функции — это определение из ядра 3.09, но никто не даст гарантий, что в другом ядре оно радикально не поменяется:

Как легко видеть из определения, приватная структура данных дописывается непосредственно в хвост struct net_device — это обычная практика создания структур переменного размера, принятая в языке C начиная с стандарта C89 (и в C99).

Этого строительного материала нам будет достаточно для построения модуля виртуального сетевого интерфейса.

Модуль виртуального интерфейса

Здесь всё достаточно просто, но некоторых отдельных комментариев заслуживают следующие моменты:

• После создания интерфейса alloc_netdev() мы связываем его операции через таблицу crypto_net_device_ops. Здесь определены операции (поля): .ndo_open и .ndo_stop (которые вызываются при запуске и остановке интерфейса командой ifconfig up/down), .ndo_get_stats (запрос статистики интерфейса) и .ndo_start_xmit (передача пакета).
• Через приватную область данных мы сохраняем связь с родительским интерфейсом в нами определённой структуре struct priv (в файлах примеров показано несколько различных вариантов использования приватной области для связывания).
• В таблице операций нет (да и быть не может по логике) функции приёма сокетных буферов. Но вызовом netdev_rx_handler_register() (который появился только в ядре 2.6.36) мы можем добавить в очередь обработки принимаемых пакетов (для родительского интерфейса) собственную функцию-фильтр handle_frame(), которая будет вызываться для каждого приходящего с этого интерфейса пакета.
• На время добавления фильтра к очереди, нам необходимо кратковременно заблокировать доступ к очереди (иначе нас может ожидать аварийный результат). Это достигается вызовами rtnl_lock() и rtnl_unlock().
• При передаче исходящего сокетного буфера в сеть (функция start_xmit()) мы просто подменяем в структуре сокетного буфера интерфейс, через который физически должна производиться отправка.
• При приёме, наоборот, сокетные буфера, создаваемые в родительском интерфейсе, подменяются на виртуальный.

Как это работает?

Выберем любой существующий и работоспособный сетевой интерфейс (в Fedora 16 один из Ethernet интерфейсов назывался как p7p1 — это хорошая иллюстрация того, что интерфейсы могут иметь очень разнообразные имена):

Установим на него свой новый виртуальный интерфейс и конфигурируем его на IP подсеть (192.168.50.0/24), отличную от исходной подсети интерфейса p7p1:

Самый простой и быстрый способ создать ответный конец коммуникации (нам ведь нужно как-то тестировать свою работу?) для такой новой (192.168.50.2/24) подсети на другом хосте LAN, это создать алиасный IP для сетевого интерфейса этого удалённого хоста, по типу:

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

Теперь из вновь созданного виртуального интерфейса мы можем проверить прозрачность сети посылкой ICMP:

И далее создать (теперь уже наоборот, на удалённом хосте) полноценную сессию SSH к новому виртуальному интерфейсу:

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

Что дальше?

Проницательный читатель, да ещё если он внимательно читал предыдущий текст, вправе в этом месте воскликнуть: «Но ведь ваш виртуальный интерфейс не дополняет, а замещает родительский?». Да, в показанном варианте именно так: загрузка такого модуля запрещает трафик по родительскому интерфейсу, но выгрузка модуля опять восстанавливает его.

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

• В фильтрах (и приёма и передачи) анализировать поле IP-адреса в структуре сокетного буфере и производить подмену интерфейса только для IP, принадлежащего виртуальному интерфейсу.
• На приёме разделить обработку сокетных буферов, соответствующим протоколам IP и ARP, потому как структуры данных этих протоколов, естественно, отличаются (поле struct sk_buff*->protocol).

Это выглядит, возможно, сложновато в словесном описании, но в коде модуля всё достаточно просто, и добавляет не более 25 строк кода. И такой вариант приведен в архиве примеров (подкаталог virt-full, здесь этот код не приводится, чтобы не перегружать текст):

Архив кодов для продолжения экспериментирования можете взять здесь или здесь.

Источник