Что такое IP-туннель и технология GRE? {#введение}
Определение IP-туннеля
IP-туннель — это механизм инкапсуляции сетевых пакетов, при котором пакеты одного протокола упаковываются внутрь пакетов другого протокола для передачи через промежуточную сеть. Представьте себе конверт: вы вкладываете письмо (внутренний пакет) в конверт (внешний пакет) и отправляете его через почтовую службу .
Технология GRE (Generic Routing Encapsulation)
GRE (Generic Routing Encapsulation) — протокол туннелирования, разработанный компанией Cisco и стандартизированный в RFC 2784 и RFC 2890. Он предназначен для инкапсуляции любых протоколов сетевого уровня (не только IP) в IP-пакеты .
Как работает GRE:
- Оригинальный пакет (например, IP, IPX, AppleTalk) полностью сохраняется
- К нему добавляется GRE-заголовок (обычно 4 байта)
- Затем добавляется внешний IP-заголовок (20 байт)
- Полученный пакет отправляется через транзитную сеть
Общая структура GRE-пакета:
Для чего применяются GRE-туннели?
Особенности GRE
- Stateless протокол — туннель не хранит состояние соединения, интерфейс всегда присутствует в системе
- Не шифрует данные — требуется дополнительная защита (IPsec) для конфиденциальности
- Проблема с NAT — GRE (протокол 47) не использует порты и не проходит через NAT без дополнительных настроек
- Накладные расходы — минимум 24 байта на пакет
- Необходимость настройки TTL — для работы протоколов маршрутизации требуется явно указывать TTL (обычно 64)
GRE против IP-IP: сравнение технологий {#сравнение}
Принципиальные различия
Достоинства и недостатки
GRE (Generic Routing Encapsulation)
Достоинства:
- ✅ Универсальность — поддерживает любые протоколы L3
- ✅ Multicast — возможность передавать групповой трафик
- ✅ Динамическая маршрутизация — OSPF, EIGRP работают через GRE
- ✅ Широкая поддержка — все сетевые ОС и оборудование
Недостатки:
- ❌ Большие накладные расходы — 24+ байта на пакет
- ❌ Отсутствие шифрования — данные передаются в открытом виде
- ❌ Проблемы с NAT — GRE не проходит через NAT без дополнительных ухищрений
- ❌ Требует настройки TTL — для multicast-протоколов необходимо явно задавать TTL
IP-IP (IP in IP)
Достоинства:
- ✅ Минимальные накладные расходы — только 20 байт
- ✅ Простота — легко настраивается, минимальная конфигурация
- ✅ Высокая производительность — меньше процессорных затрат
Недостатки:
- ❌ Только IPv4 — не поддерживает другие протоколы
- ❌ Только unicast — multicast не работает
- ❌ Ограниченное применение — подходит только для простых сценариев
Что выбрать?
Для нашей задачи — соединение двух удаленных сетей через транзитный узел с возможностью использования динамической маршрутизации в будущем — GRE является оптимальным выбором благодаря поддержке multicast и универсальности .
Топология сети с транзитным узлом {#топология}
Предположим, что у нас уже развернута сеть согласно следующей схеме:
- ISP-роутер (Alt Linux) с тремя интерфейсами:
enp0s3 – WAN, получает адрес по DHCP (зона external).
enp0s8 – 172.16.1.1/24, подключение к сети 1 (зона internal).
enp0s9 – 172.16.2.1/24, подключение к сети 2 (зона internal). - Роутер rtr (Alt Linux) в сети 1:
enp0s3 – 172.16.1.2/24, шлюз по умолчанию 172.16.1.1 (зона external).
enp0s8 – 192.168.0.1/24, локальная сеть офиса 1 (зона internal). - Роутер rtr2 (Alt Linux) в сети 2:
enp0s3 – 172.16.2.2/24, шлюз по умолчанию 172.16.2.1 (зона external).
enp0s8 – 192.168.1.1/24, локальная сеть офиса 2 (зона internal).
На всех узлах:
- Включён IP-форвардинг (net.ipv4.ip_forward = 1).
- Firewalld запущен и настроен: интерфейсы распределены по зонам, как указано выше.
- Локальные сети имеют доступ в Интернет через ISP (на ISP включён маскарадинг).
Наша задача – создать GRE-туннель между роутерами rtr и rtr2, чтобы соединить локальные сети 192.168.0.0/24 и 192.168.1.0/24. Туннельный интерфейс мы добавим в зону trusted, чтобы избежать лишних ограничений.
Схема соединения и распределение зон firewalld
Привязка интерфейсов к зонам firewalld
Такое распределение зон обеспечивает:
- Интерфейсы, смотрящие в сторону потенциально опасных сетей, помещены в зону external, где действуют строгие правила.
- Локальные интерфейсы – в зону internal, где разрешён входящий трафик.
- Туннельный интерфейс – в зону trusted, где по умолчанию разрешены все соединения, что упрощает настройку и исключает случайную блокировку трафика между роутерами.
IP-адресация и роли
Проверка готовности firewalld к работе с GRE {#firewalld-ready}
GRE использует IP-протокол номер 47. Для прохождения GRE-пакетов через интерфейсы в зонах external и internal необходимо, чтобы протокол GRE был разрешён в этих зонах.
На ISP-роутере убедитесь, что протокол GRE разрешён в зонах external и internal:
sudo firewall-cmd --zone=external --list-protocols
sudo firewall-cmd --zone=internal --list-protocols
Если gre отсутствует, добавьте его:
sudo firewall-cmd --permanent --zone=external --add-protocol=gre
sudo firewall-cmd --permanent --zone=internal --add-protocol=gre
sudo firewall-cmd --reload
На роутерах rtr и rtr2 выполните аналогичную проверку и, при необходимости, добавьте протокол GRE в зоны external и internal.
Также проверьте, что форвардинг включён:
sysctl net.ipv4.ip_forward # должно быть 1
Создание GRE-туннеля {#создание-туннеля}
nmtui (NetworkManager) {#nmtui}
Этот способ удобен, если на роутерах запущен NetworkManager.
Настройка на роутере rtr
- Запустите nmtui:
sudo nmtui
2. Выберите "Edit a connection" → "Add".
3. Выберите тип "IP Tunnel" → "Create".
4. Заполните поля:
Profile name: GRE-to-rtr2
Device: tun1
Mode: GRE
Local IP: 172.16.1.2
Remote IP: 172.16.2.2
Parent: enp0s3
MTU: 1476
IPv4 configuration: Manual → Show
Addresses: 10.0.0.1/30
5. Добавьте маршрут к удалённой сети:
Заходим в Routing->Edit->Add
В Destination/Prefix прописываем адрес сети с другой стороны туннеля, а в Next Hop прописываем IP-адрес тоннеля на RTR2.
6. Сохраните и выйдите.
При необходимости перезапускаем сетевую туннеля.
7. Настройте TTL через командную строку (nmtui не имеет поля для TTL):
nmcli connection modify GRE-to-rtr2 ip-tunnel.ttl 64
7. Укажите зону trusted для этого соединения, чтобы интерфейс автоматически попадал в нужную зону:
firewall-cmd --zone=trusted --change-interface=tun1
Настройка на роутере rtr2
Выполните аналогичные действия с зеркальными параметрами:
- Profile name: GRE-to-rtr
- Local IP: 172.16.2.2
- Remote IP: 172.16.1.2
- Addresses: 10.0.0.2/30
- Маршрут: 192.168.0.0/24 10.0.0.1
- TTL: 64
- Зона: trusted
После активации проверьте состояние:
bash
nmcli connection show --active
ip a show tun1
sudo firewall-cmd --get-zone-of-interface=tun1 # trusted
Проверка работоспособности {#проверка}
1. Проверка туннеля (ping)
С роутера rtr выполните:
bash
ping -c 4 10.0.0.2
С роутера rtr2:
bash
ping -c 4 10.0.0.1
Если пинг проходит, туннель установлен.
2. Проверка связности локальных сетей
С любого компьютера в сети 192.168.0.0/24 (например, 192.168.0.2) выполните:
bash
ping 192.168.1.2 # адрес компьютера в сети офиса 2
Если пинг проходит – туннель работает корректно, маршруты настроены.
3. Диагностика при проблемах
- Убедитесь, что на ISP-роутере включён форвардинг и разрешён GRE (см. раздел 3).
- Проверьте логи firewalld:
bash
sudo journalctl -u firewalld -f
- Захватите трафик GRE на ISP:
bash
sudo tcpdump -i any proto gre
- Проверьте, не блокирует ли локальный фаервол на клиентах ICMP.
Заключение {#заключение}
Мы рассмотрели процесс создания GRE-туннеля между двумя роутерами на уже работающей сетевой инфраструктуре Alt Linux с предварительно настроенными IP-адресами и зонами firewalld. Главные моменты:
- Протокол GRE должен быть разрешён в зонах, через которые проходит инкапсулированный трафик (external и internal).
- Сам туннельный интерфейс рекомендуется помещать в зону trusted, чтобы не создавать лишних правил.
Такая конфигурация позволяет объединить удалённые локальные сети поверх транзитной сети провайдера, сохраняя возможность дальнейшего расширения (OSPF, IPsec и т.д.).