Rukování WireGuardu funguje, služba ne

Rukování se dokončí, klient ukazuje nedávný čítač přenosu, a přesto požadavek na službu na stejném serveru selže. Tahle kombinace lidi mate, protože tunel prokazatelně funguje. Co prokázáno není, je místní doručení: paket dorazil na hostitele a hostitel ho ještě musí přijmout na správném socketu a předat procesu, který má oprávnění odpovědět. Projděte ty tři kontrolní body popořadě.

Zastavte se u prvního, který neplatí, a pro ostatní pravidla nepřidávejte.

Rukování dokazuje jen tunel

Rukování WireGuardu ustavuje klíče mezi protějšky a povoluje provoz pro rozsahy, které každý protějšek uvedl. Nic neříká o tom, které procesy na serveru naslouchají, ani o tom, zda firewall hostitele přijímá pakety adresované na některou z jeho vlastních adres.

Právě ten poslední rozdíl se nejčastěji přehlédne: provoz na samotného hostitele je místní vstup, zatímco provoz procházející hostitelem jinam je forwarding. Zpracovávají je jiné řetězce firewallu a jiná nastavení. Kontrola špatného řetězce zabere odpoledne a vrátí čítače, které vypadají nevinně.

Přečtěte naslouchač a trasu

Na klientovi ověřte, že se adresa tunelu serveru směruje do tunelu. Na serveru ověřte, že na adrese, kterou klient používá, existuje socket, a že proces za ním je ten, který jste zamýšleli.

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/

Naslouchač na 127.0.0.1 nikdy neodpoví na požadavek adresovaný na 10.66.0.1, ať firewall povolí cokoli. Naslouchač na zástupné adrese odpoví, pokud ho pravidlo nezablokuje. Výpis socketů tedy rozhodne polovinu případů dřív, než se zkoumá jakékoli pravidlo. Port a adresa dohromady rozhodují, zda požadavek může dorazit.

Porovnejte adresu, kterou klient používá, s adresou, kterou server skutečně má na rozhraní tunelu. Zastaralá konfigurace na kterékoli straně vytvoří požadavek správně směrovaný k protějšku, který takovou adresu nemá.

Aplikujte pravidla pro místní vstup, ne pro forwarding

Pokud paket dorazí a socket existuje, zbývající hranicí je vstupní politika. Pravidlo, které povoluje forwarding, nepovoluje místní doručení, a pravidlo omezené na jedno rozhraní nemusí odpovídat názvu rozhraní tunelu, který očekáváte.

Testujte jediným povoleným portem k zamýšlené službě, místo abyste otevřeli hostitele. Pak zkontrolujte vlastní autorizaci aplikace: seznam povolených, požadavek na účet nebo vazba na konkrétní název hostitele mohou odmítnout požadavek, který síť úspěšně doručila.

Kontroly certifikátů nechte zapnuté. Nečekaná identita certifikátu je informace o tom, který hostitel odpověděl, ne překážka k obejití. Prokliknutí skryje jedinou stopu, která určuje špatnou službu.

Odlište selhání jména, velikosti a identity

Služba, která funguje podle adresy, ale selhává podle jména, je problém DNS a oprava patří do konfigurace resolveru předávané klientovi, ne do firewallu. Služba, která odpovídá na malé požadavky, ale u větších odpovědí se zasekne, ukazuje na velikost paketů a MTU, což je úplně jiné vyšetřování.

Chyba HTTPS s nesprávným hostitelem obvykle znamená, že požadavek dorazil k jiné službě, často proto, že ten port vlastní proxy nebo jiný naslouchač. Přečtěte subjekt certifikátu a porovnejte ho s hostitelem, na který jste chtěli dosáhnout. To srovnání nic nestojí a často vyšetřování ukončí.

Zapište, který kontrolní bod selhal: socket, vstupní pravidlo nebo politika aplikace. Ten jediný řádek odliší síťovou závadu od rozhodnutí o autorizaci. Také zabrání tomu, aby další člověk otevíral porty, které nikdy nebyly problémem.