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: класическата грешка

Капсулирането добавя заглавки, така че най-големият пакет, който се побира в тунела, е по-малък от 1500-те байта на обикновена Ethernet връзка: 1476 байта за GRE през IPv4, а WireGuard обикновено работи с 1420. Сгрешите ли, виждате класическия симптом: малките заявки работят, а големите изтегляния и 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 излизат през собствения uplink на доставчика Ви с адрес на източника, който този доставчик никога не Ви е давал, и неговите филтри срещу подправяне ги отхвърлят. Ако дистрибуцията Ви включва строго филтриране по обратния път, задайте го на свободно и за тунела (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 тунели).