WireGuard-håndtryk virker, tjenesten gør ikke

Håndtrykket fuldføres, klienten viser en nylig overførselsstæller, og alligevel fejler en anmodning til en tjeneste på samme server. Den kombination forvirrer folk, fordi tunnelen beviseligt virker. Det, der ikke er bevist, er lokal levering: pakken nåede værten, og værten skal stadig acceptere den på den rigtige socket og give den videre til en proces med tilladelse til at svare. Gå gennem de tre kontrolpunkter i rækkefølge.

Stop ved det første, der ikke holder, og tilføj ikke regler for de andre.

Håndtrykket beviser kun tunnelen

WireGuards håndtryk etablerer nøgler mellem peers og autoriserer trafik for de områder, hver peer har angivet. Det siger intet om, hvilke processer der lytter på serveren, og intet om, hvorvidt værtens firewall accepterer pakker adresseret til en af dens egne adresser.

Netop den sidste forskel overses oftest: trafik til værten selv er lokalt input, mens trafik, der passerer gennem værten til et andet sted, er videresendelse. De håndteres af forskellige firewallkæder og forskellige indstillinger. At kontrollere den forkerte kæde koster en eftermiddag og giver tællere, der ser uskyldige ud.

Læs lytteren og ruten

På klienten skal du bekræfte, at serverens tunneladresse routes ind i tunnelen. På serveren skal du bekræfte, at der findes en socket på den adresse, klienten bruger, og at processen bag den er den, du havde tænkt på.

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 aldrig svare på en anmodning adresseret til 10.66.0.1, uanset hvad firewallen tillader. En lytter på jokertegnadressen vil, medmindre en regel blokerer den. Socketlisten afgør derfor halvdelen af tilfældene, før nogen regel undersøges. Port og adresse afgør sammen, om en anmodning kan lande.

Sammenlign den adresse, klienten bruger, med den adresse, serveren faktisk har på tunnelinterfacet. En forældet konfiguration på en af siderne giver en anmodning, der routes korrekt til en peer, som ikke har den adresse.

Anvend regler for lokalt input, ikke videresendelse

Hvis pakken ankommer, og socketen findes, er den resterende grænse inputpolitikken. En regel, der tillader videresendelse, tillader ikke lokal levering, og en regel begrænset til ét interface matcher måske ikke det tunnelinterfacenavn, du forventer.

Test med én tilladt port til den tilsigtede tjeneste i stedet for at åbne værten. Kontrollér derefter applikationens egen autorisation: en tilladelsesliste, et kontokrav eller en binding til et bestemt værtsnavn kan afvise en anmodning, som netværket leverede med succes.

Behold certifikatkontroller. En uventet certifikatidentitet er information om, hvilken vært der svarede, ikke en forhindring, der skal omgås. At klikke igennem den skjuler det eneste spor, der identificerer den forkerte tjeneste.

Adskil navne-, størrelses- og identitetsfejl

En tjeneste, der virker på adresse men fejler på navn, er et DNS-problem, og rettelsen hører i resolverkonfigurationen, der sendes til klienten, ikke i firewallen. En tjeneste, der svarer på små anmodninger, men går i stå på større svar, peger på pakkestørrelse og MTU, hvilket er en helt anden undersøgelse.

En HTTPS-fejl, der navngiver den forkerte vært, betyder normalt, at anmodningen nåede en anden tjeneste, ofte fordi en proxy eller en anden lytter ejer den port. Læs certifikatets subjekt og sammenlign det med den vært, du ville nå. Den sammenligning koster intet og afslutter ofte undersøgelsen.

Notér, hvilket kontrolpunkt der fejlede: socket, inputregel eller applikationspolitik. Den ene linje adskiller en netværksfejl fra en autorisationsbeslutning. Den forhindrer også den næste person i at åbne porte, der aldrig var problemet.