GRE-tunneler for IPv4: når du trenger en, og hvordan du setter den opp

En tunnel lar deg bruke IPv4-adresser på en server som ellers ikke kunne bære dem. Blokken kunngjøres av et nettverk som kan kunngjøre den, og tunnelen frakter trafikken til serveren din og tilbake. Det er svaret når leverandøren din ikke tilbyr bring your own IP (BYOIP), når du ikke har et AS-nummer, eller når du trenger færre enn de 256 adressene internett ruter alene.

Hva tunnelen faktisk gjør

Pakker til blokken din kommer frem til nettverket som kunngjør den. Der pakkes hver pakke inn i en ny, adressert til serveren din, og sendes over det vanlige internettet. Serveren din pakker den ut og ser den opprinnelige pakken, som om adressene var konfigurert på et lokalt grensesnitt.

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

Svarene tar samme vei tilbake: serveren din pakker dem inn, sender dem til tunnelens andre ende, og det nettverket leverer dem. Den returveien er steget de fleste oppsett gjør feil, og konfigurasjonen nedenfor viser hvorfor.

Når en tunnel slår BYOIP

BYOIP lar en sky- eller hostingleverandør kunngjøre blokken din fra sitt eget nettverk (hvilke leverandører som gjør det). Der det er tilgjengelig og du har minst en /24, er det det ryddigste alternativet: ingen ekstra hopp, ikke noe ekstra feilpunkt, og leverandørens fulle båndbredde. En tunnel er det bedre valget i fire tilfeller.

• Leverandøren din tilbyr ikke BYOIP. Scaleway sier det for eksempel rett ut i dokumentasjonen, og flere andre tar det bare på forespørsel, for noen av produktene sine, som Infomaniak, TransIP og UpCloud. Andre, blant dem Contabo, Exoscale, Hostinger og Akamai Cloud, publiserer ingen prosedyre i det hele tatt.
• Du trenger færre enn 256 adresser. En /24 er den minste blokken nettverk godtar i rutingtabellene sine, og ingen leverandørs BYOIP går under den. En tunnel kan levere en /29, eller én enkelt adresse.
• Du har ikke noe ASN, og leverandøren vil ha et. Noen leverandører godtar bare adresserommet ditt over en BGP-sesjon med ditt eget AS-nummer. En tunnel trenger ingen av delene.
• Du vil ha de samme adressene flere steder, eller frihet til å flytte. Kunngjøringen blir der den er; tunnelen går dit serveren din går.

Prisen er en omvei. Trafikken går til tunnelens andre ende før den når deg, så velg et endepunkt nær serveren din, og husk at det er tunnelens kapasitet, ikke serverens port, som setter taket.

GRE eller WireGuard

Begge frakter den samme trafikken; de skiller seg i hva veien mellom de to endene krever.

WireGuards egen liste over plattformer og MikroTiks RouterOS-dokumentasjon sier hvor det kjører (sjekket 22. oktober 2026).

Står endepunktet ditt bak NAT, er valget tatt for deg: WireGuard. Det samme gjelder Azure, som blokkerer GRE i de virtuelle nettverkene sine.

MTU og MSS: den klassiske feilen

Innkapsling legger til headere, så den største pakken som får plass i tunnelen, er mindre enn de 1 500 bytene på en vanlig Ethernet-forbindelse: 1 476 byte for GRE over IPv4, og WireGuard kjører ofte på 1 420. Blir det feil, ser du det klassiske symptomet: små forespørsler fungerer, mens store nedlastinger og TLS-håndtrykk henger, fordi pakkene som ikke får plass, forkastes, og meldingene som skulle rapportere det, ofte filtreres underveis.

To innstillinger hindrer det. Sett MTU-en på tunnelgrensesnittet til riktig verdi, og begrens TCP maximum segment size (MSS) på trafikk du ruter gjennom tunnelen, så begge ender blir enige om å sende pakker som får plass. Vi sender begge verdiene med hver tunnel, og endrer dem på forespørsel.

Et minimalt Linux-oppsett

Eksemplet nedenfor gir en blokk til én enkelt Linux-server over GRE. Adressene er dokumentasjonsområder: 203.0.113.1 er serverens offentlige adresse, 198.51.100.1 tunnelens andre 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

Steg 3 er det folk glemmer. Uten det går svar fra 192.0.2.10 ut gjennom leverandørens egen uplink, med en avsenderadresse den leverandøren aldri ga deg, og anti-spoofing-filtrene dens forkaster dem. Slår distribusjonen din på streng reverse-path-filtrering, sett den til løs for tunnelen også (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Ruter serveren blokken videre til virtuelle maskiner eller containere, begrens MSS-en på trafikken 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 ditt eget AS-nummer og vil styre kunngjøringen selv, kan du kjøre en BGP-sesjon over tunnelen i stedet for en statisk rute, med BIRD, FRR eller ruterens egen daemon. De fleste kunder trenger ikke dette og velger det statiske oppsettet. Kunngjør du fra ditt eget ASN, må ROA-en nevne det ASN-et (RPKI og ROA-er).

Hvor RTM Networks passer inn

Vi kunngjør blokken og leverer den til serveren din over GRE eller WireGuard, uansett hvor serveren står. Det fungerer der BYOIP ikke gjør det, også for færre enn 256 adresser og for leverandører som ikke godtar adresserommet ditt i det hele tatt. Fortell oss hvor serveren står og hva den kjører, så anbefaler vi GRE eller WireGuard og sender konfigurasjonen med riktige verdier for MTU og MSS (GRE- og WireGuard-tunneler).