A kézfogás lezajlik, a kliens friss átvitelszámlálót mutat, és a kérés mégis meghiúsul ugyanazon a kiszolgálón futó szolgáltatás felé. Ez a kombináció összezavarja az embereket, mert az alagút bizonyíthatóan működik. Ami nem bizonyított, az a helyi kézbesítés: a csomag elérte a gazdagépet, és a gazdagépnek még el kell fogadnia a megfelelő socketen, majd át kell adnia egy válaszolásra jogosult folyamatnak. Járja végig ezt a három ellenőrzési pontot sorrendben.

Az elsőnél álljon meg, amelyik nem teljesül, és a többihez ne adjon hozzá szabályokat.

A kézfogás csak az alagutat bizonyítja

A WireGuard kézfogása kulcsokat hoz létre a partnerek között, és engedélyezi a forgalmat azokra a tartományokra, amelyeket az egyes partnerek felsoroltak. Nem mond semmit arról, mely folyamatok figyelnek a kiszolgálón, és arról sem, hogy a gazdagép tűzfala elfogadja-e a saját címére küldött csomagokat.

Pontosan ez az utolsó különbség marad ki leggyakrabban: a gazdagéphez magához menő forgalom helyi bemenet, míg a gazdagépen át máshová tartó forgalom továbbítás. Ezeket különböző tűzfal-láncok és különböző beállítások kezelik. A rossz lánc vizsgálata egy délutánt visz el, és ártatlannak tűnő számlálókat ad vissza.

Olvassa el a figyelőt és az útvonalat

A kliensen győződjön meg arról, hogy a kiszolgáló alagútcíme az alagútba van irányítva. A kiszolgálón győződjön meg arról, hogy létezik socket a kliens által használt címen, és hogy a mögötte futó folyamat a szándékolt.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

A 127.0.0.1-en figyelő soha nem válaszol a 10.66.0.1-re küldött kérésre, bármit is engedélyez a tűzfal. A gyűjtőcímre figyelő viszont válaszol, hacsak egy szabály nem blokkolja. A socketlista tehát az esetek felét eldönti, mielőtt bármelyik szabályt megnéznénk. A port és a cím együtt dönti el, hogy egy kérés megérkezhet-e.

Hasonlítsa össze a kliens által használt címet azzal a címmel, amely valóban a kiszolgálón van az alagút interfészen. Az elavult konfiguráció bármelyik oldalon olyan kérést hoz létre, amely helyesen egy olyan partnerhez irányul, amelynek nincs ilyen címe.

Helyi bemenetre alkalmazzon szabályokat, ne továbbításra

Ha a csomag megérkezik és a socket létezik, a fennmaradó határ a bemeneti házirend. A továbbítást engedélyező szabály nem engedélyez helyi kézbesítést, és az egy interfészre korlátozott szabály nem feltétlenül illeszkedik a várt alagút-interfész nevére.

Teszteljen egyetlen engedélyezett porttal a kívánt szolgáltatás felé, ahelyett hogy megnyitná a gazdagépet. Ezután ellenőrizze az alkalmazás saját jogosultságkezelését: egy engedélyezett lista, egy fiókkövetelmény vagy egy adott gazdagépnévhez kötés elutasíthat egy olyan kérést, amelyet a hálózat sikeresen kézbesített.

Tartsa meg a tanúsítvány-ellenőrzéseket. A váratlan tanúsítvány-identitás arról ad információt, melyik gazdagép válaszolt, nem pedig leküzdendő akadály. Az átkattintás elrejti az egyetlen nyomot, amely azonosítja a rossz szolgáltatást.

Válassza szét a név-, méret- és identitáshibákat

Egy szolgáltatás, amely cím szerint működik, de név szerint meghiúsul, DNS-probléma, és a javítás a klienshez küldött feloldó konfigurációjába tartozik, nem a tűzfalba. Egy szolgáltatás, amely a kis kérésekre válaszol, de a nagyobb válaszoknál elakad, a csomagméretre és az MTU-ra utal, ami egészen más vizsgálat.

A rossz gazdagépet megnevező HTTPS-hiba általában azt jelenti, hogy a kérés egy másik szolgáltatáshoz ért el, gyakran azért, mert egy proxy vagy egy másik figyelő birtokolja azt a portot. Olvassa el a tanúsítvány tárgyát, és hasonlítsa össze a gazdagéppel, ahová el akart érni. Ez az összehasonlítás semmibe sem kerül, és gyakran lezárja a vizsgálatot.

Jegyezze fel, melyik ellenőrzési pont hibázott: socket, bemeneti szabály vagy alkalmazásházirend. Ez az egy sor különbözteti meg a hálózati hibát a jogosultsági döntéstől. Azt is megakadályozza, hogy a következő ember olyan portokat nyisson meg, amelyek soha nem voltak a probléma.

Kapcsolódó cikkek