Rukovanie WireGuardu funguje, služba nie

Rukovanie sa dokončí, klient ukazuje nedávny počítač prenosu, a napriek tomu požiadavka na službu na tom istom serveri zlyhá. Táto kombinácia ľudí mätie, pretože tunel preukázateľne funguje. Čo nie je preukázané, je lokálne doručenie: paket dorazil na hostiteľa a hostiteľ ho ešte musí prijať na správnom sockete a odovzdať procesu s oprávnením odpovedať. Prejdite tie tri kontrolné body po poriadku.

Zastavte sa pri prvom, ktorý neplatí, a pre ostatné pravidlá nepridávajte.

Rukovanie dokazuje len tunel

Rukovanie WireGuardu ustanovuje kľúče medzi partnermi a autorizuje prevádzku pre rozsahy, ktoré každý partner uviedol. Nič nehovorí o tom, ktoré procesy na serveri počúvajú, ani o tom, či firewall hostiteľa prijíma pakety adresované na jednu z jeho vlastných adries.

Práve ten posledný rozdiel sa najčastejšie prehliada: prevádzka na samotného hostiteľa je lokálny vstup, kým prevádzka prechádzajúca hostiteľom inam je preposielanie. Spracúvajú ich iné reťazce firewallu a iné nastavenia. Kontrola nesprávneho reťazca stojí popoludnie a vracia počítadlá, ktoré vyzerajú nevinne.

Prečítajte počúvajúceho a trasu

Na klientovi overte, že adresa tunela servera sa smeruje do tunela. Na serveri overte, že na adrese, ktorú klient používa, existuje socket a že proces za ním je ten zamýšľaný.

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/

Počúvajúci na 127.0.0.1 nikdy neodpovie na požiadavku adresovanú na 10.66.0.1, čokoľvek firewall povolí. Počúvajúci na všeobecnej adrese odpovie, ak ho pravidlo nezablokuje. Výpis socketov teda rozhodne polovicu prípadov skôr, než sa preskúma akékoľvek pravidlo. Port a adresa spolu rozhodujú, či požiadavka môže doraziť.

Porovnajte adresu, ktorú klient používa, s adresou, ktorú server naozaj má na rozhraní tunela. Zastaraná konfigurácia na ktorejkoľvek strane vytvorí požiadavku správne smerovanú k partnerovi, ktorý takú adresu nemá.

Uplatnite pravidlá pre lokálny vstup, nie pre preposielanie

Ak paket dorazí a socket existuje, zostávajúcou hranicou je vstupná politika. Pravidlo, ktoré povoľuje preposielanie, nepovoľuje lokálne doručenie, a pravidlo obmedzené na jedno rozhranie nemusí zodpovedať očakávanému názvu rozhrania tunela.

Testujte jediným povoleným portom k zamýšľanej službe namiesto otvorenia hostiteľa. Potom skontrolujte vlastnú autorizáciu aplikácie: zoznam povolených, požiadavka na účet alebo väzba na konkrétny názov hostiteľa môžu odmietnuť požiadavku, ktorú sieť úspešne doručila.

Nechajte kontroly certifikátov zapnuté. Neočakávaná identita certifikátu je informácia o tom, ktorý hostiteľ odpovedal, nie prekážka na obídenie. Preklikanie cez ňu skryje jedinú stopu, ktorá určuje nesprávnu službu.

Oddeľte zlyhania názvu, veľkosti a identity

Služba, ktorá funguje podľa adresy, ale zlyháva podľa názvu, je problém DNS a oprava patrí do konfigurácie resolvera odosielanej klientovi, nie do firewallu. Služba, ktorá odpovedá na malé požiadavky, ale zasekne sa pri väčších odpovediach, ukazuje na veľkosť paketu a MTU, čo je úplne iné vyšetrovanie.

Chyba HTTPS s nesprávnym hostiteľom zvyčajne znamená, že požiadavka dorazila k inej službe, často preto, že ten port vlastní proxy alebo iný počúvajúci. Prečítajte subjekt certifikátu a porovnajte ho s hostiteľom, na ktorý ste chceli dosiahnuť. To porovnanie nič nestojí a často vyšetrovanie ukončí.

Zapíšte, ktorý kontrolný bod zlyhal: socket, vstupné pravidlo alebo politika aplikácie. Ten jediný riadok odlíši sieťovú poruchu od rozhodnutia o autorizácii. Tiež zabráni tomu, aby ďalší človek otváral porty, ktoré nikdy neboli problémom.