WireGuard rukovanje radi, usluga ne

Rukovanje se završi, klijent pokazuje nedavni brojač prijenosa, a zahtjev prema usluzi na istom poslužitelju 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 još mora prihvatiti na pravom socketu i predati procesu koji ima dopuštenje odgovoriti. Prođite 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 partnera i odobrava promet za raspone koje je svaki partner naveo. Ne govori ništa o tome koji procesi slušaju na poslužitelju, niti o tome prihvaća li host vatrozid pakete upućene na jednu od njegovih vlastitih adresa.

Upravo se ta posljednja razlika najčešće propušta: promet prema samom hostu lokalni je ulaz, dok je promet koji prolazi kroz host prema drugom odredištu prosljeđivanje. Njima upravljaju različiti lanci vatrozida 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 poslužitelja usmjerava u tunel. Na poslužitelju 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 vatrozid dopuštao. Slušatelj na zamjenskoj 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.

Usporedite adresu koju klijent koristi s adresom koju poslužitelj zaista ima na sučelju tunela. Zastarjela konfiguracija na bilo kojoj strani stvara zahtjev koji je ispravno usmjeren na partnera koji tu adresu nema.

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 dopuštenih, 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 razrješivača koja se šalje klijentu, a ne vatrozidu. 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 pogreš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 usporedite 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.