WireGuard-håndtrykket virker, tjenesten ikke

Håndtrykket fullføres, klienten viser en nylig overføringsteller, og likevel feiler en forespørsel til en tjeneste på samme server. Den kombinasjonen forvirrer folk, fordi tunnelen beviselig virker. Det som ikke er bevist, er lokal levering: pakken nådde verten, og verten må fortsatt godta den på riktig socket og gi den videre til en prosess med tillatelse til å svare. Gå gjennom de tre kontrollpunktene i rekkefølge.

Stopp ved det første som ikke holder, og ikke legg til regler for de andre.

Håndtrykket beviser bare tunnelen

WireGuards håndtrykk etablerer nøkler mellom peers og autoriserer trafikk for områdene hver peer listet opp. Det sier ingenting om hvilke prosesser som lytter på serveren, og ingenting om vertens brannmur godtar pakker adressert til en av dens egne adresser.

Nettopp den siste forskjellen overses oftest: trafikk til verten selv er lokal inngang, mens trafikk som går gjennom verten til et annet sted er videresending. De håndteres av forskjellige brannmurkjeder og forskjellige innstillinger. Å kontrollere feil kjede koster en ettermiddag og gir tellere som ser uskyldige ut.

Les lytteren og ruten

På klienten, bekreft at serverens tunneladresse rutes inn i tunnelen. På serveren, bekreft at det finnes en socket på adressen klienten bruker, og at prosessen bak den er den du mente.

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/

En lytter på 127.0.0.1 vil aldri svare på en forespørsel adressert til 10.66.0.1, uansett hva brannmuren tillater. En lytter på jokertegnadressen vil det, med mindre en regel blokkerer den. Socketlisten avgjør dermed halvparten av sakene før noen regel undersøkes. Port og adresse avgjør sammen om en forespørsel kan lande.

Sammenlign adressen klienten bruker med adressen serveren faktisk har på tunnelgrensesnittet. En utdatert konfigurasjon på en av sidene gir en forespørsel som rutes korrekt til en peer som ikke har den adressen.

Bruk regler for lokal inngang, ikke videresending

Hvis pakken ankommer og socketen finnes, er den gjenværende grensen inngangspolicyen. En regel som tillater videresending, tillater ikke lokal levering, og en regel begrenset til ett grensesnitt passer kanskje ikke til grensesnittnavnet du forventer.

Test med én tillatt port til den tiltenkte tjenesten i stedet for å åpne verten. Deretter kontroller applikasjonens egen autorisasjon: en tillatelsesliste, et kontokrav eller en binding til et bestemt vertsnavn kan avvise en forespørsel som nettverket leverte med suksess.

Behold sertifikatkontrollene. En uventet sertifikatidentitet er informasjon om hvilken vert som svarte, ikke en hindring som skal omgås. Å klikke gjennom den skjuler det eneste sporet som identifiserer feil tjeneste.

Skill navne-, størrelses- og identitetsfeil

En tjeneste som virker på adresse men feiler på navn, er et DNS-problem, og rettelsen hører i resolverkonfigurasjonen som sendes til klienten, ikke i brannmuren. En tjeneste som svarer på små forespørsler, men stopper på større svar, peker på pakkestørrelse og MTU, som er en helt annen undersøkelse.

En HTTPS-feil som navngir feil vert betyr vanligvis at forespørselen nådde en annen tjeneste, ofte fordi en proxy eller en annen lytter eier den porten. Les sertifikatets subjekt og sammenlign det med verten du ville nå. Den sammenligningen koster ingenting og avslutter ofte undersøkelsen.

Noter hvilket kontrollpunkt som feilet: socket, inngangsregel eller applikasjonspolicy. Den ene linjen skiller en nettverksfeil fra en autorisasjonsbeslutning. Den hindrer også neste person i å åpne porter som aldri var problemet.