VPN-port stille? Lytter, bind-adresse eller værtens firewall

VPN'en svarer intet på sin port, og de to mulige årsager kræver modsatte reparationer: enten har ingen proces åbnet socket'en, eller også findes socket'en, og noget mellem maskinerne standser pakkerne. Én kommando afgør den første halvdel af det spørgsmål, og derfor hører den før, der røres ved nogen firewall-regel. Rækkefølgen nedenfor fjerner én forklaring ad gangen i stedet for at tilføje endnu et gæt. Det er gætteriet mellem de to, der gør en ti minutters diagnosticering til en hel aften.

Antag, at du kan logge ind på serveren, og at klienten er en rigtig profil og ikke en scanner. Begge antagelser betyder noget, for en generisk sonde kan ikke besvare et protokolspecifikt spørgsmål.

Findes socket'en overhovedet

Begynd med tjenestens egen beretning om sig selv: om den kom op, og mere nyttigt, hvad dens første opstartsfejl var. En parse-fejl, en manglende nøgle eller en bind-fejl forhindrer, at lytteren nogensinde opstår, og processen kan afslutte så stille, at en statuslinje læses tvetydigt. En unit, der rapporterer aktiv, er ikke i sig selv bevis, for hovedprocessen kan være i live, mens den komponent, der skulle binde porten, allerede har givet op.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

Socket-oversigten er det faktum, som resten af diagnosticeringen hviler på. Læs kolonnen med den lokale adresse frem for kun porten, for det er i den kolonne, loopback-bind og bind til det forkerte interface dukker op. En lytter, der findes på 127.0.0.1, kører perfekt og er stadig usynlig for din laptop.

Hvilken adresse og familie socket'en svarer på

To fejl ser ens ud fra klienten og forklarer de fleste "ikke tilgængelig"-rapporter. En server bundet til loopback-adressen accepterer aldrig trafik fra en anden maskine, og en server bundet kun til en IPv4-adresse svarer aldrig en klient, der ringer op til samme værts IPv6-adresse. Sammenlign adressen i socket-tabellen med den adresse, klienten faktisk ringer op til, tegn for tegn, før du antager noget om politik.

At begrænse oversigten til én port holder den læsbar, når værten kører flere tjenester. sport-filteret tager porten sammen med den transport, du tester:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Protokol-kolonnen ændrer hele svaret

Socket-tabellen indekserer både på protokol og port, og de er to uafhængige poster. En tjeneste, der svarer TCP på 1194, siger intet om, hvorvidt noget lytter på UDP 1194, og klienten bruger altid kun én af dem. Bekræft, hvilken transport serverkonfigurationen vælger, og hvilken klientprofilen sender, og led derefter efter netop den række.

UDP har en anden fold: en uautentificeret sonde er ikke en fejl, som tjenesten skal svare på. En scanning, der rapporterer porten som tavs, har målt tjenestens diskretion, ikke dens tilgængelighed, så test med den rigtige klient og profil.

Ét forsøg, tre steder at kigge

Fra en godkendt klient foretag præcis ét forsøg, og skriv tidspunktet ned til sekundet. Læs derefter tre kilder for det vindue: udbyderens netværksregel eller konsol, værtens firewall-tællere eller log og tjenestens egen log. At gøre det én gang er det, der gør de tre beretninger sammenlignelige, og det koster mindre end at gentage et forsøg, hvis tidsstempel ingen skrev ned.

De to udfald peger i modsatte retninger. Hvis ingen pakke nåede værten, dropper stien den, og lytteren er irrelevant. Hvis pakken nåede socket'en, og tjenesten afviste den, er stien fin, og svaret ligger i protokol, kryptografi eller legitimationsoplysninger. At åbne en port for en tjeneste, der allerede har accepteret en forbindelse, gør den næste diagnosticering sværere, ikke lettere.

Navngiv fasen, før du ændrer en regel

Forhandling, der starter, og autentificering, der fejler, er én fejl, og en tunnel, der etableres, mens videresendelsen går i stå, er en helt anden. At navngive fasen først holder reparationen smal: et legitimationsproblem løses ikke af en firewall-regel, og et datastiproblem løses ikke af en genstart.

Brug den smalleste diagnosticering, der besvarer spørgsmålet. En midlertidig pakkeobservation på én port under en administrators kontrol er et rimeligt instrument; at slå hele firewallen fra er det ikke, fordi resultatet bliver umuligt at tilskrive. ss-dokumentationen dækker de filtre, der bruges ovenfor, og det er et billigere første skridt end enhver optagelse. Noter, hvilken af de to grene du beviste, og den næste forekomst starter fra et kendt svar.