GRE-alagutak IPv4-hez: mikor van rá szükség, és hogyan állítsa be

Egy alagút lehetővé teszi, hogy IPv4-címeket használjon egy olyan szerveren, amely másképp nem tudná fogadni őket. A blokkot egy olyan hálózat jelenti be, amely be tudja jelenteni, az alagút pedig a forgalmát a szerveréhez és vissza szállítja. Ez a megoldás, ha a szolgáltatója nem kínál bring your own IP-t (BYOIP), ha nincs AS-száma, vagy ha kevesebbre van szüksége annál a 256 címnél, amelyet az internet önállóan routol.

Mit csinál valójában az alagút

Az Ön blokkjára szóló csomagok ahhoz a hálózathoz érkeznek, amely bejelenti. Ott minden csomagot egy új csomagba csomagolnak, amelyet a szerverének címeznek, és a hagyományos interneten küldenek tovább. A szervere kicsomagolja, és az eredeti csomagot látja, mintha a címek egy helyi interfészen lennének beállítva.

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

A válaszok ugyanazt az utat járják be visszafelé: a szervere becsomagolja őket, elküldi az alagút túlsó végére, és az a hálózat kézbesíti őket. Ez a visszaút az a lépés, amelyet a legtöbb beállítás elront, és az alábbi konfiguráció megmutatja, miért.

Mikor jobb az alagút a BYOIP-nál

A BYOIP lehetővé teszi, hogy egy felhő- vagy tárhelyszolgáltató a saját hálózatáról jelentse be az Ön blokkját (mely szolgáltatók teszik ezt). Ahol elérhető, és legalább egy /24-gyel rendelkezik, ez a tisztább megoldás: nincs extra ugrás, nincs extra hibapont, és a szolgáltató teljes sávszélessége rendelkezésre áll. Négy esetben az alagút a jobb választás.

• A szolgáltatója nem kínál BYOIP-t. A Scaleway például egyértelműen közli ezt a dokumentációjában, és több más csak kérésre, egyes termékeihez vállalja, például az Infomaniak, a TransIP és az UpCloud. Mások, köztük a Contabo, az Exoscale, a Hostinger és az Akamai Cloud, semmilyen eljárást nem tesznek közzé.
• 256-nál kevesebb címre van szüksége. A /24 a legkisebb blokk, amelyet a hálózatok elfogadnak az útvonaltáblájukban, és egyetlen szolgáltató BYOIP-je sem megy alá. Egy alagút szállíthat egy /29-et vagy egyetlen címet is.
• Nincs ASN-je, és a szolgáltató kér egyet. Egyes szolgáltatók csak az Ön saját AS-számával létesített BGP-sessionön fogadják a címterét. Egy alagúthoz egyik sem kell.
• Ugyanazokat a címeket több helyen szeretné, vagy szabadon költözne. A bejelentés ott marad, ahol van; az alagút oda megy, ahová a szervere.

Az ár egy kerülőút. A forgalom az alagút túlsó végéig jut, mielőtt Önhöz érne, ezért válasszon a szerveréhez közeli végpontot, és ne feledje, hogy a felső határt az alagút kapacitása szabja meg, nem a szervere portja.

GRE vagy WireGuard

Mindkettő ugyanazt a forgalmat viszi; abban különböznek, mit igényel a két vég közötti útvonal.

A WireGuard saját platformlistája és a MikroTik RouterOS-dokumentációja megmondja, hol fut (ellenőrizve: 2026. október 22.).

Ha a végpontja NAT mögött van, a választás eldőlt: WireGuard. Ugyanez érvényes az Azure esetében, amely a virtuális hálózataiban blokkolja a GRE-t.

MTU és MSS: a klasszikus hiba

A becsomagolás fejléceket ad hozzá, így az alagútba férő legnagyobb csomag kisebb, mint egy egyszerű Ethernet-kapcsolat 1500 bájtja: IPv4 feletti GRE-nél 1476 bájt, a WireGuard pedig általában 1420-on fut. Ha rosszul állítja be, a klasszikus tünetet látja: a kis kérések működnek, a nagy letöltések és a TLS-kézfogások viszont elakadnak, mert a nem férő csomagokat eldobják, a hibát jelentő üzeneteket pedig útközben gyakran kiszűrik.

Két beállítás megelőzi ezt. Állítsa az alagútinterfész MTU-ját a helyes értékre, és korlátozza a TCP maximális szegmensméretét (MSS) az alagúton át irányított forgalmon, hogy mindkét vég olyan csomagokat küldjön, amelyek beleférnek. Minden alagúthoz megküldjük mindkét értéket, és kérésre módosítjuk őket.

Egy minimális Linux-beállítás

Az alábbi példa GRE-n juttat el egy blokkot egyetlen Linux-szerverhez. A címek dokumentációs tartományok: a 203.0.113.1 a szervere nyilvános címe, a 198.51.100.1 az alagút túlsó vége, a 192.0.2.0/24 pedig a blokk.

# 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

A 3. lépést szokták kihagyni. Nélküle a 192.0.2.10-ről érkező válaszok a szolgáltatója saját uplinkjén távoznak, olyan forráscímmel, amelyet az a szolgáltató soha nem adott Önnek, és a hamisítás elleni szűrői eldobják őket. Ha a disztribúciója szigorú reverse-path szűrést kapcsol be, az alagútra állítsa lazára is (sysctl -w net.ipv4.conf.gre1.rp_filter=2).

Ha a szerver a blokkot virtuális gépekhez vagy konténerekhez irányítja tovább, korlátozza az MSS-t a továbbított forgalmon:

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

BGP az alagúton át

Ha saját AS-száma van, és maga szeretne rendelkezni a bejelentés felett, statikus útvonal helyett BGP-sessiont is futtathat az alagúton, BIRD-del, FRR-rel vagy a routere saját démonjával. A legtöbb ügyfélnek erre nincs szüksége, és a statikus beállítást választja. Ha a saját ASN-jéről jelent be, a ROA-nak ezt az ASN-t kell megneveznie (RPKI és ROA).

Hol segít az RTM Networks

Bejelentjük a blokkot, és GRE-n vagy WireGuardon juttatjuk el a szerveréhez, bárhol is legyen a szerver. Ez ott is működik, ahol a BYOIP nem, 256-nál kevesebb cím esetén is, és olyan szolgáltatóknál is, amelyek egyáltalán nem fogadják el a címterét. Írja meg, hol van a szerver és mi fut rajta, és javaslatot teszünk a GRE-re vagy a WireGuardra, majd elküldjük a konfigurációt a megfelelő MTU- és MSS-értékekkel (GRE- és WireGuard-alagutak).