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

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

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

И сегодня в данный статье напишу, как можно маршрутизировать подсеть IPv4, например на сервер для VDS серверов с другого сервера.

IP донор(сервер, с которого будем прокидывать подсеть): x.x.x.67
Подсеть: z.z.z.2/28
IP сервера(принимающий прокинутую подсеть): y.y.y.80
Оба сервера на Ubuntu 22.04(Можно использовать любой дистрибутив, который вам удобен)

И так, для начала откройте терминал сервера донора и выполните такие команды:
Включаем модуль ipip

1. modprobe ipip
Разрешаем пересылку пакетов
2. echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p

3. apt install net-tools
(RHEL - yum install net-tools)
4. iptunnel add ipip1 mode ipip local x.x.x.67 remote y.y.y.80 ttl 255
5. ip link set ipip1 up
6. ip route add z.z.z.2/28 dev ipip1

Все минимальные настройки воспроизвели на сервере доноре.

Приступаем к настройке на принимающем сервере.

Включаем модуль ipip
1. modprobe ipip
Разрешаем пересылку пакетов
2. echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p
3. apt install net-tools
(RHEL - yum install net-tools)
4. iptunnel add ipip1 mode ipip remote x.x.x.67 local y.y.y.80 ttl 255
5. ip link set ipip1 up
6. ip rule add from z.z.z.2/28 table 888
7. ip route add default dev ipip1 table 888
8. ip route add z.z.z.2/28 dev vmbr0 table 888
9. ip addr add z.z.z.2/28 dev vmbr0
Адрес z.z.z.2 будет использоваться как шлюз для VDS (Например на VMmanager 6)
Туннель построен и подсеть успешно проброшена на сервер.

Проверить можете используя команду mtr z.z.z.2 (Установить можно командой apt install mtr или RHEL yum install mtr)

Иногда возникает проблема на VDS, что терминал может отваливаться или иметь нестабильное соединение, это чаще всего связано с не верным значением MTU.

Для начала вам стоит с сервера(принимающего) подобрать верное значение MTU командой:
ping -M do -s 1500 x.x.x.67

Если видите, что пакеты не проходят, то выполняйте команду с постоянным понижением значения MTU на 2 (ping -M do -s 1498 x.x.x.67 и т.д) пока не увидите, что пакеты стали проходить. Далее установите значение MTU на сетевой интерфейс IPIP, команда:
ip link set mtu 1498 dev ipip1
(У вас будет свое значение MTU)

Так вы стабилизируете сетевое соединение.

Надеюсь данная статья облегчит некоторые задачи для вас.

PS: В данной статье не учитываются ваши настройки правил на файрволлах.

Для написания статьи использовались официальные документации и некоторые статьи на Хабр.

Комментарии (7)


  1. sfinks777
    20.12.2023 12:15

    по такому туннелю можно выполнять только однонаправленную передачу данных (unicast). 

    Меня в начале века учили, что unicast - одноадресная рассылка, multicast - многоадресная рассылка, broadcast - широковещательная. В статье, как и в первых строчках выдачи гугла, unicast вдруг превратился в "однонаправленную передачу", что с позиции сетевика имеет совсем иное значение. Пример перевода терминологии "в лоб", которая только путает.

    В остальном, с почином!


  1. iddqda
    20.12.2023 12:15

    Пара замечаний

    1. ip tunnel help. Закопайте уже net-tools пожалуйста

    2. нет необходимости мучать пинги в поисках правильного MTU. Overhead у IPIP ровно 20 байт (у GRE 24 бйта). Просто вычитайте 20 из MTU физического интерфейса (обычно 1500)


  1. MiraclePtr
    20.12.2023 12:15

    Добавлю ещё пару вещей

    1. Протокол очень примитивный и не предусматривает какого-либо шифрования. Поэтому если у вас по сетям (объединенным туннелям) бегают какие-то нешифрованные протоколам, то передаваемые данные будут доступны любому желающему перехватившему трафик. Если данные с шифрованием, то все равно можно получить определенные знания о структуре ваших сетей (IP-адреса, наличие тех или иных сервисов, SNI, и т.д.)

    2. Существуют также FOU и GUE, которые делают ровно то же самое что и IP, но поверх UDP. В отличие от IPIP, UDP гораздо более привычен для всевозможного сетевого оборудования, и с ним оно может применять разные полезные оптимизации (RSS на сетевых карточках, ECMP на свитчах, и т.д.). По тестам разработчиков ядра Linux, в ряде случаев FOU оказывается почти в два раза лучше по производительности в сравнении с обычным IPIP.


    1. loskiq
      20.12.2023 12:15

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


    1. Sap_ru
      20.12.2023 12:15

      Черт с ним, с шифрованием. Там можно смело инжектить в чужой поток свои пакеты при некотором старании. Такое даже между двумя виртуалками у одного хостера нельзя использовать, так как любая минорная уязвимость или ошибка в роутинге трафика у хостера позволяет соседями не только видеть ваш внутренний трафик, но и инжектиться в него. Ну и в том, что чужие будут видеть ваш трафик тоже ничего хорошего - пароли/логины баз данных, содержимое баз, содержимое очередей и прочее потенциально позволяет узнать какие-то критически важные пароли, токены или соли. И использовать это для атак на публично-доступные сервисы. Например утечёт так токен для доступа к CDN или DNS и приплыли - можно сертификаты своих доменов по всему интернету отлавливать.

      Учитывая, что всякие виртуальные роутеры на несколько VDS/VPS у хостеров встречаются (лично мне) регулярно, то проблема крайне актуальная.


      1. MiraclePtr
        20.12.2023 12:15

        Там можно смело инжектить в чужой поток свои пакеты при некотором старании.

        Кстати да. И тогда атакующий получит полный доступ во внутреннюю сеть с расширенными "правами" (например, действуя от имени IP-адреса в другой половине сети, которому всякое разрешено на фаерволе).


  1. Sap_ru
    20.12.2023 12:15

    Проблема даже не отсутствии шифрования и том, что кто-то увидит ваши данные.

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