WireGuard-handtrykket verkar, tenesta ikkje

Handtrykket fullførast, klienten viser ein nyleg overføringsteljar, og likevel feilar ein førespurnad til ei teneste på same tenar. Den kombinasjonen forvirrar folk, fordi tunnelen bevisleg verkar. Det som ikkje er bevist, er lokal levering: pakken nådde verten, og verten må framleis godta han på rett socket og gje han vidare til ein prosess med løyve til å svare. Gå gjennom dei tre kontrollpunkta i rekkjefølgje.

Stopp ved det første som ikkje held, og ikkje legg til reglar for dei andre.

Handtrykket beviser berre tunnelen

Handtrykket til WireGuard etablerer nøklar mellom peers og autoriserer trafikk for områda kvar peer lista opp. Det seier ingenting om kva prosessar som lyttar på tenaren, og ingenting om brannmuren til verten godtar pakkar adresserte til ein av hans eigne adresser.

Nettopp den siste skilnaden blir oftast oversett: trafikk til verten sjølv er lokal inngang, medan trafikk som går gjennom verten til ein annan stad er videresending. Dei blir handterte av ulike brannmur-kjeder og ulike innstillingar. Å kontrollere feil kjede kostar ein ettermiddag og gjev teljarar som ser uskuldige ut.

Les lyttaren og ruta

På klienten, stadfest at tunneladressa til tenaren blir ruta inn i tunnelen. På tenaren, stadfest at det finst ein socket på adressa klienten brukar, og at prosessen bak han er den du meinte.

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/

Ein lyttar på 127.0.0.1 vil aldri svare på ein førespurnad adressert til 10.66.0.1, uansett kva brannmuren tillèt. Ein lyttar på jokerteikn-adressa vil det, med mindre ein regel blokkerer han. Socketlista avgjer dermed helvta av sakene før nokon regel blir undersøkt. Port og adresse avgjer saman om ein førespurnad kan lande.

Samanlikn adressa klienten brukar med adressa tenaren faktisk har på tunnelegrensesnittet. Ein utdatert konfigurasjon på ein av sidene gjev ein førespurnad som blir ruta rett til ein peer som ikkje har den adressa.

Bruk reglar for lokal inngang, ikkje videresending

Viss pakken kjem og socketen finst, er den gjenverande grensa inngangspolicyen. Ein regel som tillèt videresending, tillèt ikkje lokal levering, og ein regel avgrensa til eitt grensesnitt passar kanskje ikkje til grensesnittnamnet du ventar.

Test med éin tillaten port til den tiltenkte tenesta i staden for å opne verten. Kontroller deretter applikasjonen si eiga autorisasjon: ei tillatingsliste, eit kontokrav eller ei binding til eit bestemt vertsnamn kan avvise ein førespurnad som nettverket leverte med suksess.

Hald sertifikatkontrollane på plass. Ein uventa sertifikatidentitet er informasjon om kva vert som svara, ikkje ein hindring som skal omgåast. Å klikke gjennom han skjuler det einaste sporet som identifiserer feil teneste.

Skil namne-, storleiks- og identitetsfeil

Ei teneste som verkar på adresse men feilar på namn, er eit DNS-problem, og rettinga høyrer i resolverkonfigurasjonen som blir sendt til klienten, ikkje i brannmuren. Ei teneste som svarar på små førespurnader, men stoppar på større svar, peikar på pakkestorleik og MTU, som er ei heilt anna undersøking.

Ein HTTPS-feil som namngjev feil vert betyr vanlegvis at førespurnaden nådde ei anna teneste, ofte fordi ein proxy eller ein annan lyttar eig den porten. Les subjektet i sertifikatet og samanlikn det med verten du ville nå. Den samanlikninga kostar ingenting og avsluttar ofte undersøkinga.

Noter kva kontrollpunkt som feila: socket, inngangsregel eller applikasjonspolicy. Den eine linja skil ein nettverksfeil frå ei autorisasjonsavgjerd. Ho hindrar òg neste person i å opne portar som aldri var problemet.