A WireGuard kézfogás működik, de nincs internet: kövess egy csomagot

Az alagút él, a wg show friss kézfogást jelent, pingelheted a kiszolgáló alagútcímét, és azon túl semmi nem válaszol. Az első ösztön a kulcsok újragenerálása vagy a konfiguráció újraosztása. Ez pontosan azt az útszakaszt változtatja meg, amelyről már bizonyított, hogy működik.

Egy befejezett kézfogás azt mondja, hogy a két fél egyetért a kulcsokban, hogy az UDP eléri a végpontot, és hogy a kripto-útválasztás elfogadja a csomagot. Azt nem mondja meg, hogy a csomag utána elhagyhatja-e a kiszolgálót.

Tehát kövess egyetlen csomagot a találgatás helyett. Négy hely van, ahol meghalhat, és mindegyik más nyomot hagy.

Mit bizonyít valójában a kézfogás

A WireGuard egy UDP-protokoll, amely Noise-kézfogással hoz létre munkamenetet, majd titkosítja a csomagokat egy peer számára. Amikor a wg show néhány másodperces kézfogást és növekvő átvitelszámlálót mutat, a végpont, a kulcsok és a peer nyilvános kulcsa mind helyes.

Amit nem bizonyít: hogy az ügyfeled egyáltalán internet felé irányuló forgalmat küld a felületre, hogy a kiszolgáló hajlandó továbbítani, vagy hogy egy válasz megtalálja a visszautat. Ezek kernel-útválasztási és tűzfal-döntések, és az alagúton kívül születnek.

Ezért olyan félrevezető teszt a kiszolgáló alagútcímére pingelni. Az a csomag a kiszolgálónak magának címezve, ezért helyben végződik. Soha nem kell neki továbbítás, soha nem kell fordítás, és soha nem kell visszaút az internetről.

Az AllowedIPs útválasztási döntés

Az ügyfélen a AllowedIPs két feladatot lát el. Ez a kriptokulcs-útválasztási tábla, amely eldönti, mely célcímek kerülnek ennek a peernek az alagútjába, és ez azon forráscímek listája, amelyeket a peer elfogad tőled. Ha az ügyfél konfigurációja csak a 10.8.0.0/24 címet sorolja fel, a nyilvános célok soha nem kerülnek be a felületre, és a szokásos alapértelmezett útvonalad kiviszi őket az alagúton kívülre. Akkor az alagút tökéletesen működik, és semmit nem tesz abból, amit szerettél volna.

Azt nézd, mit telepített az ügyfél valójában, ne azt, amit a konfigurációs fájl mond:

wg show wg0 allowed-ips
ip route get 1.1.1.1

A második parancs a döntő. Ha a válasz a fizikai felületedet és a szokásos átjárót nevezi meg, a csomag nem az alagúton megy, és semmilyen kiszolgálóoldali változtatás nem javítja meg. Add hozzá a 0.0.0.0/0 címet IPv4-hez és a ::/0 címet IPv6-hoz külön; az egy családra mindent elkapó szabály a másikat az eredeti útvonalán hagyja, és ez gyakori oka a működő IPv4-alagútnak és az elakadt IPv6-keresésnek.

Hol hal meg a csomag az átjárón

Ha az útvonal helyes, és a csomag mégis sehová nem megy, megérkezik a kiszolgálóra, és ott megáll. Négy ellenőrzés lefedi a legtöbb átjárót.

Továbbítás. A sysctl net.ipv4.ip_forward 0-t visszaadó válasza a klasszikus eset, és sok disztribúció alapértelmezésben még mindig 0. 1-nek kell lennie, és tartósan egy sysctl-fájlban kell beállítani, nem olyan paranccsal, amely újraindításkor eltűnik. Az IPv6 továbbítása külön kapcsoló.

A szűrési házirend. A FORWARD lánc alapértelmezett drop-házirenddel eldobja az alagút forgalmát, miközben engedi a hoszthoz magához menő forgalmat, ami pontosan egyezik a tünettel. Az élő szabálykészletet olvasd, ne egy mentett fájlt: nft list ruleset vagy iptables -S.

Fordítás vagy útválasztás. A privát alagútcímeket használó ügyfeleknek vagy forrás-NAT kell a kiszolgáló kimenő felületén, vagy olyan irányított prefix, amelyet a felettes hálózat tud visszairányítani. A kettő közötti választás a címtervet követi. MASQUERADE hozzáadása egy olyan hálózathoz, amely már visszairányítja a prefixet, ártalmatlan, de felesleges, a kihagyása pedig ott, ahol nincs útvonal, irányíthatatlan privát tartományra címzett válaszokat hagy.

A visszaút. Az irányított kialakításokban a felettes routernek a kiszolgálódra mutató útvonal kell. A szolgáltató hálózata ezt is blokkolhatja: több felhő bekapcsolja a forrás- és célellenőrzést a példányon, ami csendben eldobja azokat a csomagokat, amelyek forrása nem a példány saját címe, amíg azt az ellenőrzést ki nem kapcsolják.

A DNS másként hibázik, mint az útválasztás

Egy ismert címre menő csomag és egy névkeresés két külön hiba, és a hibaüzenetek ellentétes irányba vezetnek félre. Ha a ping 1.1.1.1 működik, és a böngésző semmit nem tud betölteni, az útvonal rendben van, a névfeloldás nem. Ha maga a ping hibázik, a DNS lényegtelen, és visszatértél az előző szakaszhoz.

A wg-quick beállíthat egy feloldót a konfiguráció DNS = sorából, és a systemd-resolvednek kapcsolatonként saját viselkedése van. Egy VPN, amely a feloldót csak az alagúton belülről elérhető címre írja át, minden keresést elront abban a pillanatban, amikor az alagút leesik, ami úgy néz ki, mintha az alagút törné el az internetet.

Egy sorrend, amely bizonyítékot ad

Először az ügyféloldali ellenőrzést futtasd, mert az egyetlen parancs, és a lehetőségek felét kizárja. Utána erősítsd meg, hogy a kiszolgálót egyáltalán internetes kijáratnak szánták-e; a privát hozzáférésre épített átjáró nem romlik el attól, hogy a nyilvános célok nem működnek.

A kiszolgálón figyeld a felületet, miközben pinget küldesz az ügyfélről: a tcpdump -ni wg0 icmp mutassa a kérést, a tcpdump -ni eth0 icmp pedig mutassa, hogy kilép, fordítva vagy sem. Ha az elsőn megjelenik, a másodikon soha, akkor a megállás a kiszolgálón helyi. Ha kilép, és nem jön vissza válasz, a probléma feljebb van, és az már más beszélgetés.

Végül tedd úgy, hogy a javítás túléljen egy újraindítást. A továbbítás a sysctl-fájlba tartozik, a tűzfalszabályok abba a szolgáltatásba, amely betölti őket, az ügyfél útvonalai pedig abba a konfigurációba, amely felhozza a felületet, nem egy shellbe, amelyet el fogsz felejteni. Kapcsolódj újra, ismételd meg ugyanazt a két tesztet, és igazold, hogy a számlálók mozognak.