GRE-tunnlar för IPv4: när du behöver en och hur du sätter upp den

En tunnel låter dig använda IPv4-adresser på en server som annars inte skulle kunna bära dem. Blocket annonseras av ett nät som kan annonsera det, och tunneln bär trafiken till din server och tillbaka. Det är lösningen när din leverantör inte erbjuder bring your own IP (BYOIP), när du inte har något AS-nummer, eller när du behöver färre än de 256 adresser som internet routar för sig.

Vad tunneln faktiskt gör

Paket till ditt block kommer fram till nätet som annonserar det. Där packas varje paket in i ett nytt, adresserat till din server, och skickas över det vanliga internet. Din server packar upp det och ser originalpaketet, som om adresserna vore konfigurerade på ett lokalt gränssnitt.

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

Svaren tar samma väg tillbaka: din server packar in dem, skickar dem till tunnelns andra ände, och det nätet levererar dem. Den returvägen är det steg som de flesta uppsättningar gör fel, och konfigurationen nedan visar varför.

När en tunnel slår BYOIP

BYOIP låter ett moln eller en hostingleverantör annonsera ditt block från sitt eget nät (vilka leverantörer som gör det). Där det finns och du har minst ett /24 är det det renare alternativet: inget extra hopp, ingen extra felpunkt, och leverantörens fulla bandbredd. En tunnel är det bättre valet i fyra fall.

• Din leverantör erbjuder inte BYOIP. Scaleway, till exempel, säger det rakt ut i sin dokumentation, och flera andra tar bara emot det på begäran, för vissa av sina produkter, som Infomaniak, TransIP och UpCloud. Andra, bland dem Contabo, Exoscale, Hostinger och Akamai Cloud, publicerar ingen procedur alls.
• Du behöver färre än 256 adresser. Ett /24 är det minsta block som nät godtar i sina routingtabeller, och ingen leverantörs BYOIP går under det. En tunnel kan leverera ett /29, eller en enda adress.
• Du har inget ASN, och leverantören vill ha ett. Vissa leverantörer tar bara emot ditt utrymme över en BGP-session med ditt eget AS-nummer. En tunnel behöver ingetdera.
• Du vill ha samma adresser på flera ställen, eller frihet att flytta. Annonseringen stannar där den är; tunneln går dit din server går.

Priset är en omväg. Trafiken går till tunnelns andra ände innan den når dig, så välj en ändpunkt nära din server, och kom ihåg att tunnelns kapacitet, inte serverns port, sätter taket.

GRE eller WireGuard

Båda bär samma trafik; de skiljer sig i vad vägen mellan de två ändarna kräver.

WireGuards egen lista över plattformar och MikroTiks dokumentation för RouterOS anger var det körs (kontrollerat 22 oktober 2026).

Sitter din ändpunkt bakom NAT är valet redan gjort: WireGuard. Detsamma gäller Azure, som blockerar GRE i sina virtuella nät.

MTU och MSS: det klassiska felet

Inkapsling lägger till headers, så det största paket som får plats i tunneln är mindre än de 1 500 byte som en vanlig Ethernet-länk har: 1 476 byte för GRE över IPv4, och WireGuard körs ofta på 1 420. Blir det fel ser du det klassiska symtomet: små förfrågningar fungerar, medan stora nedladdningar och TLS-handskakningar hänger sig, eftersom paketen som inte får plats kastas och meddelandena som borde rapportera det ofta filtreras bort på vägen.

Två inställningar förhindrar det. Sätt tunnelgränssnittets MTU till rätt värde, och begränsa TCP:s maximala segmentstorlek (MSS) på trafik som du routar genom tunneln, så att båda ändarna kommer överens om att skicka paket som får plats. Vi skickar med båda värdena för varje tunnel, och ändrar dem på begäran.

En minimal uppsättning i Linux

Exemplet nedan ger ett block till en enda Linuxserver över GRE. Adresserna är dokumentationsintervall: 203.0.113.1 är din servers publika adress, 198.51.100.1 tunnelns andra ände och 192.0.2.0/24 blocket.

# 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 är det som folk missar. Utan det lämnar svaren från 192.0.2.10 servern via din leverantörs egen upplänk, med en avsändaradress som leverantören aldrig gav dig, och dess filter mot förfalskade adresser kastar dem. Om din distribution slår på strikt filtrering av omvänd väg (reverse-path filtering), sätt den till lös för tunneln också (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Om servern routar blocket vidare till virtuella maskiner eller containrar, begränsa MSS på trafiken den vidarebefordrar:

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

BGP över tunneln

Har du ett eget AS-nummer och vill styra annonseringen själv kan du köra en BGP-session över tunneln i stället för en statisk route, med BIRD, FRR eller din routers egen daemon. De flesta kunder behöver inte det och tar den statiska uppsättningen. Annonserar du från ditt eget ASN måste ROA:n ange det ASN:et (RPKI och ROA).

Var RTM Networks passar in

Vi annonserar blocket och levererar det till din server över GRE eller WireGuard, var servern än står. Det fungerar där BYOIP inte gör det, även för färre än 256 adresser och för leverantörer som inte godtar ditt utrymme alls. Berätta var servern står och vad den kör, så rekommenderar vi GRE eller WireGuard och skickar konfigurationen med rätt värden för MTU och MSS (GRE- och WireGuard-tunnlar).