Tunele GRE dla IPv4: kiedy są potrzebne i jak je skonfigurować

Tunel pozwala używać adresów IPv4 na serwerze, który inaczej nie mógłby ich obsługiwać. Blok ogłasza sieć, która może go ogłosić, a tunel przenosi jego ruch do Twojego serwera i z powrotem. To rozwiązanie, gdy Twój dostawca nie oferuje bring your own IP (BYOIP), gdy nie masz numeru AS albo gdy potrzebujesz mniej niż 256 adresów, które internet routuje samodzielnie.

Co właściwie robi tunel

Pakiety dla Twojego bloku docierają do sieci, która go ogłasza. Tam każdy pakiet jest opakowywany w nowy, zaadresowany do Twojego serwera, i wysyłany przez zwykły internet. Twój serwer go rozpakowuje i widzi oryginalny pakiet, tak jakby adresy były skonfigurowane na lokalnym interfejsie.

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

Odpowiedzi idą tą samą drogą w odwrotnym kierunku: serwer je opakowuje, wysyła na drugi koniec tunelu, a tamta sieć je dostarcza. Ta droga powrotna to krok, który w większości konfiguracji jest ustawiony źle, a konfiguracja poniżej pokazuje dlaczego.

Kiedy tunel wygrywa z BYOIP

BYOIP pozwala dostawcy chmury lub hostingu ogłaszać Twój blok z własnej sieci (którzy dostawcy to robią). Tam, gdzie jest dostępne i masz co najmniej /24, to czystsza opcja: bez dodatkowego przeskoku, bez dodatkowego punktu awarii i z pełną przepustowością dostawcy. Tunel jest lepszym wyborem w czterech przypadkach.

• Twój dostawca nie oferuje BYOIP. Scaleway na przykład mówi to wprost w dokumentacji, a kilku innych przyjmuje je tylko na życzenie, dla niektórych produktów, np. Infomaniak, TransIP i UpCloud. Inni, m.in. Contabo, Exoscale, Hostinger i Akamai Cloud, nie publikują żadnej procedury.
• Potrzebujesz mniej niż 256 adresów. /24 to najmniejszy blok, jaki sieci przyjmują do tablic routingu, i BYOIP żadnego dostawcy nie schodzi poniżej niego. Tunel może dostarczyć /29 albo pojedynczy adres.
• Nie masz ASN, a dostawca go wymaga. Niektórzy dostawcy przyjmują Twoją przestrzeń tylko przez sesję BGP z Twoim własnym numerem AS. Tunel nie potrzebuje ani jednego, ani drugiego.
• Chcesz tych samych adresów w kilku miejscach albo swobody przeprowadzki. Ogłoszenie zostaje tam, gdzie jest; tunel idzie tam, gdzie idzie Twój serwer.

Ceną jest objazd. Ruch trafia najpierw na drugi koniec tunelu, a dopiero potem do Ciebie, więc wybierz punkt końcowy blisko serwera i pamiętaj, że górny limit wyznacza przepustowość tunelu, a nie port serwera.

GRE czy WireGuard

Oba przenoszą ten sam ruch; różnią się tym, czego wymaga droga między obydwoma końcami.

Własna lista platform WireGuard i dokumentacja RouterOS MikroTika podają, gdzie działa (sprawdzone 22 października 2026).

Jeśli Twój punkt końcowy jest za NAT, wybór jest przesądzony: WireGuard. To samo dotyczy Azure, który blokuje GRE w swoich sieciach wirtualnych.

MTU i MSS: klasyczna awaria

Enkapsulacja dodaje nagłówki, więc największy pakiet mieszczący się w tunelu jest mniejszy niż 1500 bajtów zwykłego łącza Ethernet: 1476 bajtów dla GRE przez IPv4, a WireGuard zwykle działa z 1420. Ustaw to źle, a zobaczysz klasyczny objaw: małe żądania działają, a duże pobrania i handshake TLS się zawieszają, bo pakiety, które się nie mieszczą, są odrzucane, a komunikaty, które powinny to zgłosić, są często filtrowane po drodze.

Zapobiegają temu dwa ustawienia. Ustaw właściwe MTU interfejsu tunelu i ogranicz (clamp) maksymalny rozmiar segmentu TCP (MSS) dla ruchu routowanego przez tunel, tak aby oba końce zgodziły się wysyłać pakiety, które się mieszczą. Obie wartości przesyłamy z każdym tunelem i zmieniamy je na życzenie.

Minimalna konfiguracja w Linuksie

Poniższy przykład doprowadza blok do jednego serwera z Linuksem przez GRE. Adresy pochodzą z zakresów dokumentacyjnych: 203.0.113.1 to publiczny adres Twojego serwera, 198.51.100.1 drugi koniec tunelu, a 192.0.2.0/24 blok.

# 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

Krok 3 to ten, który się pomija. Bez niego odpowiedzi z 192.0.2.10 wychodzą przez łącze Twojego dostawcy z adresem źródłowym, którego ten dostawca nigdy Ci nie dał, a jego filtry antyspoofingowe je odrzucają. Jeśli Twoja dystrybucja włącza ścisłe filtrowanie ścieżki zwrotnej (reverse-path filtering), ustaw je także dla tunelu na tryb luźny (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Jeśli serwer routuje blok dalej do maszyn wirtualnych lub kontenerów, ogranicz MSS w przekazywanym ruchu:

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

BGP przez tunel

Jeśli masz własny numer AS i chcesz sam kontrolować ogłoszenie, możesz zamiast trasy statycznej uruchomić przez tunel sesję BGP, z BIRD, FRR lub demonem własnego routera. Większość klientów tego nie potrzebuje i wybiera konfigurację statyczną. Jeśli ogłaszasz z własnego ASN, ROA musi wskazywać ten ASN (RPKI i ROA).

Gdzie pasuje RTM Networks

Ogłaszamy blok i dostarczamy go do Twojego serwera przez GRE lub WireGuard, gdziekolwiek serwer się znajduje. Działa to tam, gdzie nie działa BYOIP, również dla mniej niż 256 adresów i u dostawców, którzy w ogóle nie przyjmują Twojej przestrzeni. Napisz, gdzie jest serwer i co na nim działa, a polecimy GRE lub WireGuard i prześlemy konfigurację z właściwymi wartościami MTU i MSS (tunele GRE i WireGuard).