Beágyazott WireGuard: a középső ugrás nem tud válaszolni a saját portjára
Amikor a középső ugrás mindent egyetlen alagútba küld, a bejövő szolgáltatására adott válaszok a rossz úton indulnak el. Egy forrásport-szabály az interfészen ezt helyrehozza.
Három WireGuard-ugrás ér el egy nyilvános cím nélküli hálózatot, és akkor a középső gép abbahagyja a válaszadást azon a porton, amelyen hallgatnia kellett volna. A további alagút továbbra is működik, a távoli hoszt továbbra is válaszol, és csak a középső kiszolgáló maga hallgatott el kívülről. Ez a kombináció éppen azért zavaró, mert saját maga okozta: a középső ugrás a saját útválasztási táblájának engedelmeskedik, a tábla pedig rossz irányba küldi a válaszait.
Egy lánc, amely addig működik, amíg nem beszélsz a középső dobozzal
Vegyünk egy szemléltető láncot: az A kliens eléri a B kiszolgálót UDP 500-on, a B pedig továbbhalad a C kiszolgáló felé UDP 500-on. A C csak az egyetlen partnerének címéről fogad forgalmat, ami levéllé teszi, és egyszerűen tartja a viselkedését. A B nem levél, és e hiba minden érdekessége ott történik.
A megkülönböztetés azért számít, mert a levél és a középső szerep ellentétes irányba húz. Egy levél mindent következmények nélkül küldhet egyetlen alagútba, mert semmi más nem függ tőle. A középső ugrás egyszerre végpont a kliensek számára és kliens a távoli oldal felé, és ez a két munka eltérő útválasztást akar.
Miért az alagúton keresztül távozik a válasz
A B-n a C felé néző interfész a megfelelő alapértelmezett útvonallal együtt hordozza a AllowedIPs = 0.0.0.0/0 beállítást. Ezért a B által létrehozott minden csomag ebbe az alagútba kerül, hacsak valami pontosabb nem kap elsőbbséget.
Az A-tól a B-nek címzett csomag megérkezik és elfogadásra kerül, mert a B a cél, és a helyi kézbesítés történik először. A válasz egy teljesen új, helyben létrehozott csomag, amely az A nyilvános címére irányul, és ez a cél megfelel az alagútba vezető alapértelmezett útvonalnak. A C megkapja, nem birtokolja ezt a címet, és eldobja.
A tünet tűzfalgondnak vagy kulcs-eltérésnek tűnik, és itt egyik sem igaz. Az alagúton a C felé készített rögzítés megmutatja, hogy a válaszok rossz irányba tartanak. Ez az egyetlen megfigyelés több időt takarít meg, mint bármennyi konfigurációolvasás, ezért írja le, mielőtt elkezdi cserélni a kulcsokat. Aki nem látta a rögzítést, azt fogja feltételezni, hogy maga az alagút hibás.
A szűk javítás: forrásportra illeszkedő házirend-szabályok
A B hallgató socketjéből a válaszok 500-as forrásporttal lépnek ki. Egy házirend-szabály illeszkedhet erre, és visszairányíthatja azokat a csomagokat a szokásos táblába:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101A házirend-szabályokat prioritási sorrendben vizsgálják, és a fő tábla a 32766-nál van, így a 100-as szabályt az alagút alapértelmezett útvonala előtt kérdezik meg. Adjon hozzá egy bejegyzést minden olyan porthoz, amelynek kívülről elérhetőnek kell maradnia, és semmi többet, hogy a továbbított forgalom továbbra is azt az alagutat használja, amelyhez épült.
Ismerje ennek a trükknek a határát. A sport szelektor a helyben létrehozott csomagokra illeszkedik, ami pontosan a válasz esetét fedi le, és szándékosan nem fedi le azt a forgalmat, amelyet a B csak továbbít valaki más helyett. A B mögött üzemeltetett szolgáltatásnak továbbra is szüksége van a saját válaszára, és az ellenkezőjének színlelése olyan javítást ad, amely az első szolgáltatásnál működik, a másodiknál pedig meghiúsul.
Adjon a szabálynak gazdát
A parancssorba beírt szabály eltűnik, amikor az interfész legközelebb újraépül. WireGuard-beállításnál oda tegye, ahol az interfész létrejön és eltávolításra kerül:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Ha az interfész a NetworkManager, egy disztribúciós hook vagy egy konténer belépési pont tulajdonában van, a pár ahhoz a gazdához tartozik, nem egy kézzel szerkesztett fájlhoz. Ellenőrizze az érvényes szabályokat újracsatlakozás után, ne csak az első indítás után, mert az első indítás az az eset, amely mindig működik.
Hasonlítsa össze őszintén az alternatívákat
A forrásport-szabály a négy kivezető út egyike, és a legszűkebb közülük. Előnye, hogy egyáltalán nem nyúl az alagút házirendjéhez, ezért általában túléli a későbbi változásokat. A szűk javítások is hangosan meghiúsulnak, amikor már nem érvényesek, míg egy széles kivétel csendesen tovább működik jóval azután, hogy az oka eltűnt. Ez a különbség többet számít az eleganciánál, amikor két év múlva valaki másé a doboz.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
A választás után mindkét végéről ellenőrizze. Az A-ból indítson kapcsolatot a B portjára, és tartsa egy ideig foglaltan. A B-n késztesse a kernelt arra, hogy indokolja meg a válasz útját valami hasonlóval: ip route get <address-of-A> sport 500, és erősítse meg, hogy az WAN-interfészt nevez meg, nem az alagutat. Ezután ellenőrizze, hogy valami a C mögött továbbra is válaszol a láncon keresztül, ami bizonyítja, hogy a kivétel szűk maradt, és nem vált megkerüléssé. Végül jegyezze fel a portokat a tervezési feljegyzésekbe, különben a következő üzemeltető újra felfedezi ezt egy másik szolgáltatásnál.