Тунелі GRE для IPv4: коли вони потрібні і як їх налаштувати

Тунель дає змогу використовувати IPv4-адреси на сервері, який інакше не міг би їх нести. Блок анонсує мережа, яка може його анонсувати, а тунель переносить його трафік до вашого сервера і назад. Це рішення, коли ваш провайдер не пропонує bring your own IP (BYOIP), коли у вас немає номера AS або коли вам потрібно менше за 256 адрес, які інтернет маршрутизує окремо.

Що насправді робить тунель

Пакети для вашого блоку надходять до мережі, що його анонсує. Там кожен пакет загортається в новий, адресований вашому серверу, і надсилається звичайним інтернетом. Ваш сервер розгортає його і бачить початковий пакет, ніби адреси налаштовано на локальному інтерфейсі.

Original packet:  [IP header | data]
GRE packet:       [outer IP | GRE header | IP header | data]

Відповіді йдуть тим самим шляхом у зворотному напрямку: ваш сервер загортає їх, надсилає на дальній кінець тунелю, і та мережа їх доставляє. Саме цей зворотний шлях найчастіше налаштовують неправильно, і конфігурація нижче показує чому.

Коли тунель кращий за BYOIP

BYOIP дає змогу хмарному або хостинг-провайдеру анонсувати ваш блок зі своєї мережі (які провайдери це роблять). Якщо він доступний і у вас є щонайменше /24, це чистіший варіант: жодного зайвого переходу, жодної зайвої точки відмови і вся пропускна здатність провайдера. Тунель кращий у чотирьох випадках.

• Ваш провайдер не пропонує BYOIP. Scaleway, наприклад, прямо пише про це у своїй документації, а кілька інших приймають його лише на запит, для деяких своїх продуктів, як-от Infomaniak, TransIP і UpCloud. Інші, серед них Contabo, Exoscale, Hostinger і Akamai Cloud, узагалі не публікують процедури.
• Вам потрібно менше за 256 адрес. /24 є найменшим блоком, який мережі приймають у свої таблиці маршрутизації, і BYOIP жодного провайдера не йде нижче. Тунель може доставити /29 або одну адресу.
• У вас немає ASN, а провайдер його вимагає. Деякі провайдери приймають ваш простір лише через сесію BGP з вашим власним номером AS. Тунелю не потрібно ні того, ні іншого.
• Ви хочете ті самі адреси в кількох місцях або свободу переїзду. Анонс залишається там, де є; тунель іде туди, куди йде ваш сервер.

Ціна полягає в обхідному шляху. Трафік спершу йде до дальнього кінця тунелю, а потім до вас, тож вибирайте кінцеву точку поблизу вашого сервера і пам’ятайте, що стелю задає пропускна здатність тунелю, а не порт вашого сервера.

GRE чи WireGuard

Обидва несуть той самий трафік; вони різняться тим, що потрібно шляху між двома кінцями.

Власний список платформ WireGuard і документація MikroTik RouterOS показують, де він працює (перевірено 22 жовтня 2026 р.).

Якщо ваша кінцева точка за NAT, вибір зроблено за вас: WireGuard. Те саме стосується Azure, яка блокує GRE у своїх віртуальних мережах.

MTU і MSS: класична помилка

Інкапсуляція додає заголовки, тож найбільший пакет, що вміщується в тунель, менший за 1 500 байтів звичайного каналу Ethernet: 1 476 байтів для GRE через IPv4, а WireGuard зазвичай працює з 1 420. Помиліться, і побачите класичний симптом: малі запити працюють, а великі завантаження і рукостискання TLS зависають, бо пакети, що не вміщуються, відкидаються, а повідомлення, які мали б про це сповістити, часто фільтруються дорогою.

Цьому запобігають два налаштування. Задайте правильне значення MTU для інтерфейсу тунелю і обмежте максимальний розмір сегмента TCP (MSS) для трафіку, який ви маршрутизуєте через тунель, щоб обидва кінці погоджувалися надсилати пакети, що вміщуються. Ми надсилаємо обидва значення з кожним тунелем і змінюємо їх на запит.

Мінімальне налаштування в Linux

Приклад нижче доставляє блок на один сервер Linux через GRE. Адреси взято з документаційних діапазонів: 203.0.113.1 є публічною адресою вашого сервера, 198.51.100.1 дальнім кінцем тунелю, а 192.0.2.0/24 блоком.

# 1. The tunnel, from your server to the far end
ip tunnel add gre1 mode gre local 203.0.113.1 remote 198.51.100.1 ttl 255
ip link set gre1 mtu 1476 up
ip addr add 10.0.0.2/30 dev gre1

# 2. An address from the block on the server itself
ip addr add 192.0.2.10/32 dev lo

# 3. Replies from the block go back through the tunnel
ip rule add from 192.0.2.0/24 lookup 100
ip route add default via 10.0.0.1 dev gre1 table 100

Крок 3 найчастіше пропускають. Без нього відповіді з 192.0.2.10 виходять через власний аплінк вашого провайдера з адресою джерела, якої цей провайдер вам ніколи не видавав, і його фільтри проти підробки адрес їх відкидають. Якщо ваш дистрибутив вмикає сувору перевірку зворотного шляху, задайте для тунелю також м’який режим (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Якщо сервер маршрутизує блок далі до віртуальних машин або контейнерів, обмежте MSS для трафіку, який він пересилає:

iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

BGP через тунель

Якщо у вас є власний номер AS і ви хочете самі контролювати анонс, ви можете запустити через тунель сесію BGP замість статичного маршруту, з BIRD, FRR або власним демоном вашого маршрутизатора. Більшості клієнтів це не потрібно, і вони беруть статичне налаштування. Якщо ви анонсуєте з власного ASN, ROA має вказувати цей ASN (RPKI і ROA).

Де тут RTM Networks

Ми анонсуємо блок і доставляємо його на ваш сервер через GRE або WireGuard, де б не був сервер. Це працює там, де BYOIP не працює, зокрема для менш ніж 256 адрес і для провайдерів, які взагалі не приймають ваш простір. Скажіть нам, де сервер і що на ньому працює, і ми порадимо GRE чи WireGuard і надішлемо конфігурацію з правильними значеннями MTU і MSS (GRE-тунелі та WireGuard).