WireGuard rukovanje radi, usluga ne

Rukovanje se završi, klijent pokazuje nedavni brojač prijenosa, a zahtjev prema usluzi na istom serveru i dalje ne uspijeva. Ta kombinacija zbunjuje ljude jer tunel očito radi. Ono što nije dokazano jest lokalna dostava: paket je stigao do hosta, a host ga i dalje mora prihvatiti na pravom socketu i predati ga procesu koji ima dozvolu da odgovori. Prođite kroz te tri kontrolne točke redom.

Zaustavite se na prvoj koja ne vrijedi i ne dodajte pravila za ostale.

Rukovanje dokazuje samo tunel

WireGuard rukovanje uspostavlja ključeve između peerova i odobrava promet za raspone koje je svaki peer naveo. Ne govori ništa o tome koji procesi slušaju na serveru, niti o tome prihvata li host firewall pakete upućene na jednu od njegovih vlastitih adresa.

Upravo se ta posljednja razlika najčešće propušta: promet prema samom hostu je lokalni ulaz, dok je promet koji prolazi kroz host prema nekom drugom odredištu prosljeđivanje. Njima upravljaju različiti lanci firewalla i različite postavke. Provjera pogrešnog lanca troši poslijepodne i vraća brojače koji izgledaju nedužno.

Pročitajte slušatelja i rutu

Na klijentu potvrdite da se adresa tunela servera usmjerava u tunel. Na serveru potvrdite da socket postoji na adresi koju klijent koristi i da je proces iza njega onaj koji ste namjeravali.

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/

Slušatelj na 127.0.0.1 nikada neće odgovoriti na zahtjev upućen na 10.66.0.1, što god firewall dopuštao. Slušatelj na wildcard adresi hoće, osim ako ga pravilo blokira. Popis socketa tako rješava pola slučajeva prije nego što se pregleda ijedno pravilo. Port i adresa zajedno odlučuju može li zahtjev stići.

Uporedite adresu koju klijent koristi s adresom koju server zaista posjeduje na sučelju tunela. Zastarjela konfiguracija na bilo kojoj strani stvara zahtjev koji je ispravno usmjeren na peera koji tu adresu ne posjeduje.

Primijenite pravila za lokalni ulaz, ne za prosljeđivanje

Ako paket stigne i socket postoji, preostala granica je ulazna politika. Pravilo koje dopušta prosljeđivanje ne dopušta lokalnu dostavu, a pravilo ograničeno na jedno sučelje možda neće odgovarati nazivu sučelja tunela koji očekujete.

Testirajte s jednim dopuštenim portom prema namjeravanoj usluzi umjesto da otvorite host. Zatim provjerite vlastitu autorizaciju aplikacije: popis dozvoljenih, zahtjev za računom ili vezanje na određeno ime hosta mogu odbiti zahtjev koji je mreža uspješno dostavila.

Ostavite provjere certifikata na mjestu. Neočekivani identitet certifikata informacija je o tome koji je host odgovorio, a ne prepreka koju treba zaobići. Klikom kroz nju skrivate jedini trag koji identificira pogrešnu uslugu.

Odvojite kvarove imena, veličine i identiteta

Usluga koja radi po adresi, ali ne uspijeva po imenu, problem je DNS-a, a ispravak pripada konfiguraciji resolvera koja se šalje klijentu, a ne firewalu. Usluga koja odgovara na male zahtjeve, ali zapinje na većim odgovorima, upućuje na veličinu paketa i MTU, što je posve druga istraga.

HTTPS greška koja imenuje pogrešan host obično znači da je zahtjev stigao do druge usluge, često zato što proxy ili drugi slušatelj posjeduje taj port. Pročitajte subject certifikata i uporedite ga s hostom do kojeg ste htjeli stići. Ta usporedba ne košta ništa i često završava istragu.

Zabilježite koja je kontrolna točka zakazala: socket, ulazno pravilo ili politika aplikacije. Taj jedan redak razlikuje mrežni kvar od odluke o autorizaciji. Također sprječava sljedeću osobu da otvara portove koji nikada nisu bili problem.