VPN-porten er stille? Lytter, bind-adresse eller vertens brannmur

VPN-en svarer ingenting på porten sin, og de to mulige årsakene krever motsatte reparasjoner: enten åpnet ingen prosess socketen, eller så finnes socketen og noe mellom maskinene stopper pakkene. Én kommando avgjør den første halvdelen av det spørsmålet, derfor hører den hjemme før noen brannmurregel røres. Rekkefølgen nedenfor fjerner én forklaring per steg i stedet for å legge til nok en gjetning. Det er gjettingen mellom de to som gjør en timinutters diagnose til en hel kveld.

Anta at du kan logge på serveren og at klienten er en ekte profil og ikke en skanner. Begge antakelsene betyr noe, for en generisk sonde kan ikke svare på et protokollspesifikt spørsmål.

Finnes socketen i det hele tatt

Begynn med tjenestens egen beretning om seg selv: om den kom opp og, mer nyttig, hva den første oppstartsfeilen var. En parsefeil, en manglende nøkkel eller en bindfeil hindrer lytteren i å oppstå, og prosessen kan avslutte så stille at en statuslinje leses tvetydig. En enhet som rapporterer aktiv er ikke bevis i seg selv, for hovedprosessen kan leve mens komponenten som skulle binde porten allerede har gitt opp.

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

Socket-listen er det faktumet som resten av diagnosen hviler på. Les kolonnen for den lokale adressen og ikke bare porten, for det er i den kolonnen loopback-bindinger og bindinger til feil grensesnitt dukker opp. En lytter som finnes på 127.0.0.1 kjører perfekt og er fortsatt usynlig for laptopen din.

Hvilken adresse og familie socketen svarer på

To feil ser like ut fra klienten og forklarer de fleste "ikke tilgjengelig"-rapportene. En server bundet til loopback-adressen godtar aldri trafikk fra en annen maskin, og en server bundet bare til en IPv4-adresse svarer aldri en klient som ringer opp IPv6-adressen til samme vert. Sammenlign adressen i socket-tabellen med adressen klienten faktisk ringer opp, tegn for tegn, før du antar noe om policy.

Å begrense listen til én port holder den lesbar når verten kjører flere tjenester. sport-filteret tar porten sammen med transporten du tester:

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

Protokollkolonnen endrer hele svaret

Socket-tabellen indekserer både på protokoll og port, og de er to uavhengige oppføringer. En tjeneste som svarer TCP på 1194 sier ingenting om hvorvidt noe lytter på UDP 1194, og klienten bruker alltid bare én av dem. Bekreft hvilken transport serverkonfigurasjonen velger og hvilken klientprofilen sender, og se deretter etter nøyaktig den raden.

UDP har en andre brett: en uautentisert sonde er ikke en feil tjenesten må svare på. En skanning som rapporterer porten som stille, har målt tjenestens diskresjon, ikke tilgjengeligheten, så test med den ekte klienten og profilen.

Ett forsøk, tre steder å se

Fra en godkjent klient gjør nøyaktig ett forsøk og skriv ned tiden til sekundet. Les deretter tre kilder for det vinduet: leverandørens nettverksregel eller konsoll, vertens brannmurtellere eller logg, og tjenestens egen logg. Å gjøre dette én gang er det som gjør de tre beretningene sammenlignbare, og det koster mindre enn å gjenta et forsøk der ingen skrev ned tidsstempelet.

De to utfallene peker i motsatte retninger. Hvis ingen pakke nådde verten, dropper banen den, og lytteren er irrelevant. Hvis pakken nådde socketen og tjenesten avviste den, er banen i orden og svaret ligger i protokoll, kryptografi eller legitimasjon. Å åpne en port for en tjeneste som allerede har godtatt en tilkobling gjør neste diagnose vanskeligere, ikke lettere.

Navngi fasen før du endrer en regel

Forhandling som starter og autentisering som feiler er én feil, og en tunnel som etableres mens videresendingen stopper, er en helt annen. Å navngi fasen først holder reparasjonen smal: et legitimasjonsproblem løses ikke av en brannmurregel, og et databaneproblem løses ikke av en omstart.

Bruk den smaleste diagnosen som svarer på spørsmålet. En midlertidig pakkeobservasjon på én port, under en administrators kontroll, er et rimelig instrument; å slå av hele brannmuren er det ikke, fordi resultatet blir umulig å tilskrive. ss-dokumentasjonen dekker filtrene som er brukt ovenfor, og det er et billigere første steg enn enhver innfanging. Noter hvilken av de to grenene du beviste, og neste forekomst starter fra et kjent svar.