Tunnel GRE per IPv4: quando ne serve uno e come configurarlo

Un tunnel ti permette di usare indirizzi IPv4 su un server che altrimenti non potrebbe gestirli. Il blocco viene annunciato da una rete che può annunciarlo, e il tunnel porta il suo traffico in entrambe le direzioni tra la rete e il tuo server. È la risposta quando il tuo provider non offre il bring your own IP (BYOIP), quando non hai un numero AS, o quando ti servono meno dei 256 indirizzi che internet instrada da soli.

Cosa fa davvero il tunnel

I pacchetti per il tuo blocco arrivano alla rete che lo annuncia. Lì ogni pacchetto viene incapsulato in uno nuovo, indirizzato al tuo server, e inviato attraverso la normale internet. Il tuo server lo decapsula e vede il pacchetto originale, come se gli indirizzi fossero configurati su un’interfaccia locale.

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

Le risposte fanno lo stesso percorso al contrario: il tuo server le incapsula, le invia all’altro capo del tunnel, e quella rete le consegna. Quel percorso di ritorno è il passo che la maggior parte delle configurazioni sbaglia, e la configurazione qui sotto mostra perché.

Quando un tunnel batte il BYOIP

Il BYOIP permette a un cloud o hosting provider di annunciare il tuo blocco dalla propria rete (quali provider lo fanno). Dove è disponibile e hai almeno un /24, è l’opzione più pulita: nessun salto in più, nessun punto di guasto in più, e tutta la banda del provider. Un tunnel è la scelta migliore in quattro casi.

• Il tuo provider non offre il BYOIP. Scaleway, per esempio, lo dice chiaramente nella sua documentazione, e diversi altri lo accettano solo su richiesta, per alcuni prodotti, come Infomaniak, TransIP e UpCloud. Altri, tra cui Contabo, Exoscale, Hostinger e Akamai Cloud, non pubblicano alcuna procedura.
• Ti servono meno di 256 indirizzi. Un /24 è il blocco più piccolo che le reti accettano nelle loro tabelle di routing, e il BYOIP di nessun provider scende sotto. Un tunnel può consegnare un /29, o un singolo indirizzo.
• Non hai un ASN, e il provider ne vuole uno. Alcuni provider accettano il tuo spazio solo su una sessione BGP con un tuo numero AS. Un tunnel non richiede né l’una né l’altro.
• Vuoi gli stessi indirizzi in più posti, o la libertà di spostarti. L’annuncio resta dov’è; il tunnel va dove va il tuo server.

Il prezzo è una deviazione. Il traffico viaggia fino all’altro capo del tunnel prima di raggiungerti, quindi scegli un endpoint vicino al tuo server, e ricorda che il limite lo pone la capacità del tunnel, non la porta del tuo server.

GRE o WireGuard

Entrambi trasportano lo stesso traffico; differiscono per ciò che richiede il percorso tra i due capi.

La lista delle piattaforme di WireGuard e la documentazione di RouterOS di MikroTik dicono dove funziona (verificato il 22 ottobre 2026).

Se il tuo endpoint è dietro NAT, la scelta è fatta: WireGuard. Lo stesso vale per Azure, che blocca il GRE nelle sue reti virtuali.

MTU e MSS: il guasto classico

L’incapsulamento aggiunge header, quindi il pacchetto più grande che entra nel tunnel è più piccolo dei 1500 byte di un normale collegamento Ethernet: 1476 byte per GRE su IPv4, e WireGuard gira comunemente a 1420. Se lo sbagli vedi il sintomo classico: le richieste piccole funzionano, mentre i download grandi e gli handshake TLS si bloccano, perché i pacchetti che non entrano vengono scartati e i messaggi che dovrebbero segnalarlo vengono spesso filtrati lungo il percorso.

Due impostazioni lo evitano. Imposta l’MTU dell’interfaccia del tunnel al valore giusto, e limita (clamp) il maximum segment size (MSS) TCP sul traffico che instradi nel tunnel, così entrambi i capi concordano di inviare pacchetti che entrano. Con ogni tunnel inviamo entrambi i valori, e li cambiamo su richiesta.

Una configurazione Linux minima

L’esempio qui sotto porta un blocco a un singolo server Linux su GRE. Gli indirizzi sono intervalli di documentazione: 203.0.113.1 è l’indirizzo pubblico del tuo server, 198.51.100.1 l’altro capo del tunnel, e 192.0.2.0/24 il blocco.

# 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

Il passo 3 è quello che si dimentica. Senza, le risposte da 192.0.2.10 escono dall’uplink del tuo provider, con un indirizzo sorgente che quel provider non ti ha mai dato, e i suoi filtri anti-spoofing le scartano. Se la tua distribuzione attiva il reverse-path filtering rigoroso, impostalo su loose anche per il tunnel (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Se il server instrada il blocco verso macchine virtuali o container, limita l’MSS sul traffico che inoltra:

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

BGP sul tunnel

Se hai un tuo numero AS e vuoi controllare tu l’annuncio, puoi far girare una sessione BGP sul tunnel invece di una route statica, con BIRD, FRR o il daemon del tuo router. La maggior parte dei clienti non ne ha bisogno e sceglie la configurazione statica. Se annunci dal tuo ASN, la ROA deve indicare quell’ASN (RPKI e ROA).

Dove entra RTM Networks

Annunciamo il blocco e lo consegniamo al tuo server su GRE o WireGuard, ovunque sia il server. Funziona dove il BYOIP non funziona, anche per meno di 256 indirizzi e per provider che non accettano affatto il tuo spazio. Dicci dov’è il server e cosa ci gira, e ti consigliamo GRE o WireGuard e inviamo la configurazione con i valori giusti di MTU e MSS (tunnel GRE e WireGuard).