GRE-tunneler til IPv4: hvornår du har brug for en, og hvordan du sætter den op

En tunnel lader dig bruge IPv4-adresser på en server, der ellers ikke kunne bære dem. Blokken annonceres af et netværk, der kan annoncere den, og tunnelen fører dens trafik til din server og tilbage. Det er svaret, når din udbyder ikke tilbyder bring your own IP (BYOIP), når du ikke har noget AS-nummer, eller når du har brug for færre end de 256 adresser, internettet vil route alene.

Hvad tunnelen faktisk gør

Pakker til din blok ankommer til det netværk, der annoncerer den. Der pakkes hver pakke ind i en ny, adresseret til din server, og sendes over det almindelige internet. Din server pakker den ud og ser den oprindelige pakke, som om adresserne var konfigureret på et lokalt interface.

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

Svar tager samme vej tilbage: din server pakker dem ind, sender dem til tunnelens anden ende, og det netværk leverer dem. Den returvej er det trin, de fleste opsætninger får galt, og konfigurationen nedenfor viser hvorfor.

Hvornår en tunnel slår BYOIP

BYOIP lader en cloud- eller hostingudbyder annoncere din blok fra sit eget netværk (hvilke udbydere der gør). Hvor det findes, og du har mindst en /24, er det den renere løsning: intet ekstra hop, intet ekstra fejlpunkt og udbyderens fulde båndbredde. En tunnel er det bedre valg i fire tilfælde.

• Din udbyder tilbyder ikke BYOIP. Scaleway siger det for eksempel ligeud i sin dokumentation, og flere andre tager det kun på forespørgsel, for nogle af deres produkter, såsom Infomaniak, TransIP og UpCloud. Andre, blandt dem Contabo, Exoscale, Hostinger og Akamai Cloud, offentliggør slet ingen procedure.
• Du har brug for færre end 256 adresser. En /24 er den mindste blok, netværk accepterer i deres routingtabeller, og ingen udbyders BYOIP går under den. En tunnel kan levere en /29 eller en enkelt adresse.
• Du har intet ASN, og udbyderen vil have et. Nogle udbydere accepterer kun dine adresser over en BGP-session med dit eget AS-nummer. En tunnel kræver ingen af delene.
• Du vil have de samme adresser flere steder eller frihed til at flytte. Annonceringen bliver, hvor den er; tunnelen går derhen, hvor din server går.

Prisen er en omvej. Trafikken rejser til tunnelens anden ende, før den når dig, så vælg et endepunkt tæt på din server, og husk, at tunnelens kapacitet, ikke din servers port, sætter loftet.

GRE eller WireGuard

Begge bærer den samme trafik; de adskiller sig i, hvad vejen mellem de to ender kræver.

WireGuards egen liste over platforme og MikroTiks RouterOS-dokumentation siger, hvor det kører (tjekket 22. oktober 2026).

Sidder dit endepunkt bag NAT, er valget truffet for dig: WireGuard. Det samme gælder Azure, som blokerer GRE i sine virtuelle netværk.

MTU og MSS: den klassiske fejl

Indkapsling tilføjer headere, så den største pakke, der passer ind i tunnelen, er mindre end de 1.500 byte på en almindelig Ethernet-forbindelse: 1.476 byte for GRE over IPv4, og WireGuard kører typisk med 1.420. Rammer du forkert, ser du det klassiske symptom: små forespørgsler virker, mens store downloads og TLS-handshakes hænger, fordi de pakker, der ikke passer, bliver smidt væk, og de meddelelser, der skulle melde det, ofte filtreres undervejs.

To indstillinger forhindrer det. Sæt tunnelinterfacets MTU til den rigtige værdi, og begræns TCP's maximum segment size (MSS) på den trafik, du router gennem tunnelen, så begge ender er enige om at sende pakker, der passer. Vi sender begge værdier med hver tunnel og ændrer dem efter ønske.

En minimal Linux-opsætning

Eksemplet nedenfor bringer en blok til en enkelt Linux-server over GRE. Adresserne er dokumentationsområder: 203.0.113.1 er din servers offentlige adresse, 198.51.100.1 tunnelens anden ende og 192.0.2.0/24 blokken.

# 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

Trin 3 er det, folk overser. Uden det forlader svar fra 192.0.2.10 serveren via din udbyders eget uplink med en afsenderadresse, som den udbyder aldrig har givet dig, og dens anti-spoofing-filtre smider dem væk. Slår din distribution streng reverse-path-filtrering til, så sæt den også til løs for tunnelen (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Router serveren blokken videre til virtuelle maskiner eller containere, så begræns MSS på den trafik, den videresender:

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

BGP over tunnelen

Har du dit eget AS-nummer og vil styre annonceringen selv, kan du køre en BGP-session over tunnelen i stedet for en statisk route, med BIRD, FRR eller din routers egen daemon. De fleste kunder har ikke brug for det og tager den statiske opsætning. Annoncerer du fra dit eget ASN, skal ROA'en nævne det ASN (RPKI og ROA'er).

Hvor RTM Networks passer ind

Vi annoncerer blokken og leverer den til din server over GRE eller WireGuard, uanset hvor serveren står. Det virker, hvor BYOIP ikke gør, også for færre end 256 adresser og for udbydere, der slet ikke accepterer dine adresser. Fortæl os, hvor serveren står, og hvad den kører, så anbefaler vi GRE eller WireGuard og sender konfigurationen med de rigtige MTU- og MSS-værdier (GRE- og WireGuard-tunneler).