Egy WireGuard-peer elérhetetlen, miközben egy másik működik: ellenőrzőlista

Egy WireGuard-peer átviszi a forgalmat, a második pedig végrehajtja a kézfogást, de soha nem ér el semmit a tunel mögött. A működő peer azt mondja, hogy a csatoló, az UDP-port és a szerver kulcsa valószínűleg rendben van. Semmit nem mond a második peer AllowedIPs-bejegyzéséről, belső forrásoldali címéről vagy a köztük lévő továbbítási szabályokról. Járja végig a listát sorrendben, és álljon meg az első lépésnél, amelynek feltétele nem teljesül.

Lépés 1: Írja le az útvonalat, amelyen a csomagnak haladnia kell

Két ügyfél ugyanazon a hubon nem éri el automatikusan egymást. Hub és küllő elrendezésben a szerver a wg0-n fogadja a csomagot, és vissza kell továbbítania a wg0-ból a másik peerhez, amihez IP-továbbítás és egy továbbítási szabály szükséges. Közvetlen peer–peer elrendezésben mindkét félnek szüksége van a másik végpontjára és a másik tunelcímére az AllowedIPs-en belül. Döntse el, melyik elrendezést hibakeresi, mielőtt bármilyen konfigurációt elolvas.

A várt útvonal megmondja azt is, hol keressen. Ha a csomagnak át kell haladnia a hubon, akkor a hibás ugrás vagy a küldő AllowedIPs-e, vagy a hub továbbítása, vagy a fogadó AllowedIPs-e. Ha közvetlenül kell mennie, a hub lényegtelen, és a két peer végpontmezői számítanak.

Lépés 2: Hasonlítsa össze az AllowedIPs-t mindkét oldalon, ne csak az egyiken

A WireGuard az AllowedIPs-t egyszerre használja útválasztási táblaként és hozzáférési listaként. Küldéskor a célcím az AllowedIPs-ben keresendő a tunel kiválasztásához; fogadáskor a belső forráscímnek a küldő peer AllowedIPs-én belülre kell esnie, különben a csomag eldobódik. Egy hiányzó tartomány bármelyik oldalon ugyanazt a tünetet okozza: a szállítás működik, a hasznos tartalom eltűnik.

Az élő állapotot olvassa a fájl helyett, mert az újratöltés csendben meghiúsulhatott: sudo wg show wg0 allowed-ips. A szerveren a hibás peer bejegyzésének tartalmaznia kell a tunelcímét, például 10.90.0.3/32. Az ügyfélen a szerver peer bejegyzésének tartalmaznia kell a tesztelt célt, legyen az a hub tunelcíme vagy a távoli alhálózat. Az átfedő tartományok kétértelművé teszik a keresést, és olyan peert választhatnak, amelyet nem szándékozott, ezért tartsa őket külön.

Lépés 3: Ellenőrizze a belső forráscímet

Az az ügyfél, amely a 10.90.0.3-at a wg0-n keresztül irányítja, de a csomagokat a Wi-Fi-címéről küldi, a fogadó elutasítja, mert a forrás nem egyezik a peer AllowedIPs-ével. Erősítse meg, mit választ valójában a kernel, a ip route get 10.90.0.3 from 10.90.0.2 paranccsal, és erősítse meg a tunelcsatolóhoz rendelt címet a ip -brief addr show wg0 paranccsal.

A fogadó Linux-gazdagépen a fordított útvonal szűrése egy második kapu. A visszaútvonalat birtokló csatolón egy szigorú rp_filter eldobhatja azt a tunelforgalmat, amelynek visszaútja nem egyezik azzal a csatolóval, amelyen érkezett. A letiltás előtt ellenőrizze a tényleges értéket; sok topológiában a helyes javítás egy útvonal, nem egy lazított szűrő.

Lépés 4: Vizsgálja felül a hub továbbítását és a visszautat

Ha a hubnak peerek között kell továbbítania, a kernelnek net.ipv4.ip_forward=1 kell, és a tűzfalnak el kell fogadnia a továbbított folyamot: be a wg0-n, ki a wg0-n, a küldő tunelcímétől a fogadó címéig. Gyakori hiba, hogy egy bemeneti szabály elfogadja az UDP 51820-at, de nincs továbbítási szabály], így a kézfogás sikerül, és a hasznos tartalom meghal. Listázza az érvényes szabályokat a sudo nft list ruleset paranccsal vagy a tűzfalkezelője megfelelőjével.

Ezután ellenőrizze a választ. A célgazdagépnek visszaúttal kell rendelkeznie a küldőhöz, akár a hubon, akár a saját átjáróján keresztül. Ha a hub a tunel alhálózatát is NAT-olja, erősítse meg, hogy a fordítás a továbbított folyamra vonatkozik, és hogy a válasz eljut a hubhoz, mielőtt az állapot lejár. Az egyirányú hiba, amely kulcsproblémának tűnik, gyakran éppen ez a visszaút.

Végül válassza szét a kézfogást az adatoktól. Az a peer, amely befejezi a kézfogást, de nagy átviteleknél elakad, általában MTU- vagy MSS-problémával küzd ezen az útvonalon, nem AllowedIPs-problémával. Először kis pinggel teszteljen, majd teljes méretűvel, és hasonlítsa össze a két peert.

Lépés 5: Változtasson egy dolgot, és tartsa érintetlenül a működő peert

Egyetlen változtatást hajtson végre a hibás útvonalon, és tesztelje újra mindkét peert. Ha minden peer AllowedIPs-ét 0.0.0.0/0-ra cseréli, az a leggyorsabb módja annak, hogy eltörje a már működő peert, mert ez megváltoztatja az útválasztási döntést a csatoló teljes forgalmára. Szerkessze az egyetlen bejegyzést, töltse újra, és olvassa vissza az élő állapotot.

Jegyezze fel, melyik útvonal sikerült, melyik hiúsult meg, és az egyes parancsok pontos kimenetét. Ez az összehasonlítás többet ér, mint egy általános jelentés arról, hogy a VPN elromlott, és a következő ember elsőként ezt fogja kérdezni.