Tuneluri GRE pentru IPv4: când aveți nevoie de unul și cum îl configurați

Un tunel vă permite să folosiți adrese IPv4 pe un server care altfel nu le-ar putea purta. Blocul este anunțat de o rețea care îl poate anunța, iar tunelul îi transportă traficul până la serverul dvs. și înapoi. Este răspunsul atunci când furnizorul nu oferă bring your own IP (BYOIP), când nu aveți un număr AS sau când aveți nevoie de mai puțin decât cele 256 de adrese pe care internetul le rutează singure.

Ce face de fapt tunelul

Pachetele pentru blocul dvs. ajung la rețeaua care îl anunță. Acolo, fiecare pachet este împachetat într-unul nou, adresat serverului dvs., și trimis prin internetul obișnuit. Serverul îl despachetează și vede pachetul original, ca și cum adresele ar fi configurate pe o interfață locală.

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

Răspunsurile parcurg același drum în sens invers: serverul le împachetează, le trimite la celălalt capăt al tunelului, iar acea rețea le livrează. Acest drum de întoarcere este pasul pe care majoritatea configurărilor îl greșesc, iar configurația de mai jos arată de ce.

Când un tunel e mai bun decât BYOIP

BYOIP permite unui furnizor de cloud sau de hosting să vă anunțe blocul din propria rețea (ce furnizori o fac). Acolo unde este disponibil și aveți cel puțin un /24, este opțiunea mai curată: fără un hop în plus, fără un punct suplimentar de defecțiune și cu toată lățimea de bandă a furnizorului. Un tunel este alegerea mai bună în patru cazuri.

• Furnizorul nu oferă BYOIP. Scaleway, de exemplu, o spune clar în documentație, iar mai mulți alții îl acceptă doar la cerere, pentru unele dintre produse, cum ar fi Infomaniak, TransIP și UpCloud. Alții, printre care Contabo, Exoscale, Hostinger și Akamai Cloud, nu publică nicio procedură.
• Aveți nevoie de mai puțin de 256 de adrese. Un /24 este cel mai mic bloc pe care rețelele îl acceptă în tabelele de rutare, iar BYOIP-ul niciunui furnizor nu coboară sub el. Un tunel poate livra un /29 sau o singură adresă.
• Nu aveți ASN, iar furnizorul vrea unul. Unii furnizori vă acceptă spațiul doar printr-o sesiune BGP cu propriul număr AS. Un tunel nu are nevoie de niciunul.
• Vreți aceleași adrese în mai multe locuri sau libertatea de a vă muta. Anunțul rămâne unde este; tunelul merge oriunde merge serverul.

Prețul este un ocol. Traficul ajunge la capătul celălalt al tunelului înainte să ajungă la dvs., așa că alegeți un endpoint aproape de server și nu uitați că plafonul îl stabilește capacitatea tunelului, nu portul serverului.

GRE sau WireGuard

Ambele transportă același trafic; diferă prin ce îi trebuie drumului dintre cele două capete.

Lista de platforme a WireGuard și documentația RouterOS a MikroTik spun unde rulează (verificat pe 22 octombrie 2026).

Dacă endpointul se află în spatele NAT, alegerea e făcută deja: WireGuard. La fel și pentru Azure, care blochează GRE în rețelele sale virtuale.

MTU și MSS: eșecul clasic

Încapsularea adaugă antete, așa că cel mai mare pachet care încape în tunel este mai mic decât cei 1.500 de octeți ai unei legături Ethernet simple: 1.476 de octeți pentru GRE peste IPv4, iar WireGuard rulează de obicei la 1.420. Dacă greșiți, vedeți simptomul clasic: cererile mici funcționează, în timp ce descărcările mari și handshake-urile TLS se blochează, pentru că pachetele care nu încap sunt aruncate, iar mesajele care ar trebui să raporteze asta sunt adesea filtrate pe drum.

Două setări previn problema. Setați MTU-ul interfeței de tunel la valoarea corectă și limitați dimensiunea maximă a segmentului TCP (MSS) pentru traficul pe care îl rutați prin tunel, astfel încât ambele capete să cadă de acord să trimită pachete care încap. Trimitem ambele valori cu fiecare tunel și le schimbăm la cerere.

O configurare Linux minimă

Exemplul de mai jos aduce un bloc pe un singur server Linux prin GRE. Adresele sunt intervale de documentație: 203.0.113.1 este adresa publică a serverului dvs., 198.51.100.1 capătul celălalt al tunelului, iar 192.0.2.0/24 blocul.

# 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

Pasul 3 este cel pe care oamenii îl omit. Fără el, răspunsurile de la 192.0.2.10 pleacă prin legătura proprie a furnizorului dvs., cu o adresă sursă pe care furnizorul nu v-a dat-o niciodată, iar filtrele sale anti-spoofing le aruncă. Dacă distribuția dvs. activează filtrarea strictă reverse-path, setați-o pe loose și pentru tunel (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Dacă serverul rutează blocul mai departe către mașini virtuale sau containere, limitați MSS-ul pentru traficul pe care îl transmite:

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

BGP prin tunel

Dacă aveți propriul număr AS și vreți să controlați singur anunțul, puteți rula o sesiune BGP prin tunel în locul unei rute statice, cu BIRD, FRR sau daemonul propriu al routerului. Majoritatea clienților nu au nevoie de asta și aleg configurarea statică. Dacă anunțați de pe propriul ASN, ROA-ul trebuie să numească acel ASN (RPKI și ROA).

Unde se încadrează RTM Networks

Anunțăm blocul și vi-l livrăm pe server prin GRE sau WireGuard, oriunde s-ar afla serverul. Asta funcționează acolo unde BYOIP nu funcționează, inclusiv pentru mai puțin de 256 de adrese și pentru furnizori care nu vă acceptă deloc spațiul. Spuneți-ne unde este serverul și ce rulează, iar noi vă recomandăm GRE sau WireGuard și vă trimitem configurația cu valorile corecte de MTU și MSS (tuneluri GRE și WireGuard).