Az UDP-vizsgálat szűrve jelzi: valóban leállt a WireGuard-partnered?

A vizsgálók nyitott vagy szűrt állapotot írnak ki egy UDP-porthoz, és a következtetés általában másodperceken belül megjön: a tunnel elromlott. Lehet, hogy így van, de a vizsgálat nem ezt bizonyította. Az UDP nem hordoz semmilyen kapcsolat-kézfogást, és a WireGuard semmire nem válaszol, amit nem tud hitelesíteni, ezért a csend a várt válasz a legtöbb próbára.

Dolgozz inkább a kliensből kifelé, és tekintsd a vizsgálatot egyetlen gyenge adatpontnak több között.

Mit lát és mit nem lát a vizsgáló

Az UDP-vizsgáló elküld egy terhelést, és vár. Ha ICMP port-unreachable jön vissza, jelentheti a portot zártként. Ha semmi nem jön vissza, az eredmény tervezésileg kétértelmű: egy szűrt útvonal, egy hiányzó gazdagép és egy futó szolgáltatás, amely figyelmen kívül hagyta a terhelést, mind ugyanazt a csendet produkálja. Három különböző állapot, egyetlen kimeneti karakterlánc.

A WireGuard szándékosan rontja ezt a kétértelműséget. A protokoll csak akkor fogad el egy csomagot, ha az hitelesíti magát, így a rossz kulcsokkal érkező próbát válasz nélkül eldobják. Nincs banner, nincs verziókarakterlánc és nincs hibaüzenet, amit ujjlenyomatként rögzíthetnél.

Egy TCP-teszt ugyanazon a portszámon semmi kapcsolódót nem tesztel. Egy másik figyelőt gyakoroltat, amely talán nem is létezik, és annak elutasítása semmit nem mond az UDP-ről.

A nyitott szűrt állapotok tehát pontosabban írják le a vizsgáló bizonytalanságát, mint a szerveredet.

Járd végig a valódi klienst a profiltól befelé

Kezdd a kliens saját nézetével. Van-e címe az interfésznek, a megfelelő végpontot nevezi-e meg a konfiguráció, és mozdul-e a kézfogás-számláló, amikor kapcsolatot próbálnak? Az a kliens, amely soha nem küldött csomagot, és az a kliens, amelynek csomagjait eldobták, azonosnak látszik egy állapotablakban. Csak a számlálók különböztetik meg őket, ezért először a számlálókat olvasd.

Ezután figyeld a szerver oldalát egyetlen engedélyezett kísérlet közben, ahelyett hogy külön vizsgálatot futtatnál egy harmadik helyről:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

Az első parancs az utolsó kézfogást jelenti partnereként, ami közvetlen bizonyíték arra, hogy egy hitelesített csere befejeződött. A második megmutatja, hogy egyáltalán megérkeznek-e a csomagok a figyelőhöz, ami egy lépésben elválasztja az útvonalproblémát a konfigurációs problémától.

Ha a rögzítés semmit nem mutat, a csomag soha nem érte el a gazdagépet, és a tunnel konfigurációja nem gyanús. Ha a várt címről érkező csomagokat mutat, miközben a kézfogás nullán marad, a kulcsok vagy a partner engedélyezett címei a következő hely, ahol érdemes nézni.

Korrelálj a szerveren, amikor azt te adminisztrálod

Erősítsd meg, hogy a figyelő létezik, és hogy a szolgáltató tűzfala engedi az UDP-portot. Egy gazdagép-tűzfalszabály és egy felhőbiztonsági csoport két független kapu, és bármelyik eldobhat egy csomagot, amelyet a másik engedett. Mindkettőt a konfiguráció tényleges portjához mérd, ne ahhoz, amelyre emlékszel.

A cím ugyanolyan fontos, mint a port. Az egy adott címen figyelő szerver nem válaszol egy másikra érkező csomagra, és egy több interfésszel rendelkező gazdagép azon az interfészen kaphatja meg a próbát, amelyet nem szándékoztál.

Tarts minden tesztet olyan rendszereken belül, amelyek tesztelésére jogosult vagy. A hasznos összehasonlítás egyetlen valódi klienspróba és a várt szerverútvonal között van, nem azon címek szélesebb pásztázása között, amelyek véletlenül ugyanahhoz a szolgáltatóhoz tartoznak.

Egy vizsgálati eredmény őszinte olvasása

A vizsgálat olcsó módja annak ellenőrzésére, hogy létezik-e egy gazdagép, és hogy egy portot nem blokkol-e nyilvánvalóan egy köztes eszköz. Ez nem egy hitelesített protokoll elérhetőségi bizonyítéka, és biztosan nem konfigurációs teszt.

Az erősebb bizonyíték egy befejezett kézfogás attól a klienstől, amely igazán számít neked, majd egy kérés, amely használja a tunnelt és választ kap. Ez a sorrend egyetlen menetben gyakoroltatja a kulcsokat, az engedélyezett címeket, mindkét tűzfalat és a visszautat.

Ahol a valódi kísérlet meghiúsul, a hibát továbbra is a kliens számlálóival és a szerver rögzítésével kell diagnosztizálni, nem egy újabb próbával. A protokoll leírása elmagyarázza, miért nem kap választ egy nem hitelesített csomag, és pontosan ez az oka annak, hogy a vizsgálati eredmény kétértelmű.