VPN-porten er stille? Lyttar, bind-adresse eller brannmur på verten

VPN-en svarar ingenting på porten sin, og dei to moglege årsakene krev motsette reparasjonar: anten opna ingen prosess socketen, eller så finst socketen og noko mellom maskinene stoppar pakkane. Éin kommando avgjer den første halvdelen av det spørsmålet, derfor høyrer han heime før noka brannmurregel vert rørt. Rekkjefølgja nedanfor fjernar éi forklaring per steg i staden for å leggje til endå ei gissing. Det er gissinga mellom dei to som gjer ein timinutts diagnose til ein heil kveld.

Gå ut frå at du kan logge på serveren og at klienten er ein ekte profil og ikkje ein skannar. Begge føresetnadene tel, for ei generisk sonda kan ikkje svare på eit protokollspesifikt spørsmål.

Finst socketen i det heile

Byrj med det tenesta sjølv fortel om seg: om ho kom opp og, meir nyttig, kva den første oppstartsfeilen var. Ein parsefeil, ein manglande nøkkel eller ein bindfeil hindrar lyttaren i å oppstå, og prosessen kan avslutte så stille at ei statuslinje vert lesen tvitydig. Ei eining som rapporterer aktiv er ikkje prov i seg sjølv, for hovudprosessen kan leve medan komponenten som skulle binde porten alt har gjeve opp.

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

Socket-lista er det faktumet som resten av diagnosen kviler på. Les kolonnen for den lokale adressa og ikkje berre porten, for det er i den kolonnen loopback-bindingar og bindingar til feil grensesnitt dukkar opp. Ein lyttar som finst på 127.0.0.1 køyrer perfekt og er framleis usynleg for laptoppen din.

Kva adresse og familie socketen svarar på

To feil ser like ut frå klienten og forklarer dei fleste "ikkje tilgjengeleg"-rapportane. Ein server bunden til loopback-adressa godtek aldri trafikk frå ein annan maskin, og ein server bunden berre til ei IPv4-adresse svarar aldri ein klient som ringjer opp IPv6-adressa til same vert. Samanlikn adressa i socket-tabellen med adressa klienten faktisk ringjer opp, teikn for teikn, før du går ut frå noko om policy.

Å avgrense lista til éin port held ho lesbar når verten køyrer fleire tenester. sport-filteret tek porten saman med transporten du testar:

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

Protokollkolonnen endrar heile svaret

Socket-tabellen indekserer både på protokoll og port, og dei er to uavhengige oppføringar. Ei teneste som svarar TCP på 1194 seier ingenting om noko lyttar på UDP 1194, og klienten brukar alltid berre éin av dei. Stadfest kva transport serverkonfigurasjonen vel og kva klientprofilen sender, og leit deretter etter nøyaktig den rada.

UDP har ein andre brett: ei uautentisert sonda er ikkje ein feil tenesta må svare på. Ein skann som rapporterer porten som stille, har målt diskresjonen til tenesta, ikkje tilgjengelegheita, så test med den ekte klienten og profilen.

Eitt forsøk, tre stader å sjå

Frå ein godkjend klient gjer nøyaktig eitt forsøk og skriv ned tida til sekundet. Les deretter tre kjelder for det vindauget: nettverksregelen eller konsollen til leverandøren, brannmurteljarane eller loggen til verten, og eigen logg for tenesta. Å gjere dette éin gong er det som gjer dei tre fråsegna samanliknbare, og det kostar mindre enn å gjenta eit forsøk der ingen skreiv ned tidsstempelet.

Dei to utfalla peikar i motsette retningar. Om ingen pakke nådde verten, droppar banen han, og lyttaren er irrelevant. Om pakken nådde socketen og tenesta avviste han, er banen i orden og svaret ligg i protokoll, kryptografi eller legitimasjon. Å opne ein port for ei teneste som alt har godteke ei tilkopling gjer neste diagnose vanskelegare, ikkje lettare.

Namngje fasen før du endrar ein regel

Forhandling som startar og autentisering som feilar er éin feil, og ein tunnel som vert etablert medan vidaresendinga stoppar, er ein heilt annan. Å namngje fasen først held reparasjonen smal: eit legitimasjonsproblem vert ikkje løyst av ein brannmurregel, og eit databaneproblem vert ikkje løyst av ein omstart.

Bruk den smalaste diagnosen som svarar på spørsmålet. Ein mellombels pakkeobservasjon på éin port, under kontroll av ein administrator, er eit rimeleg instrument; å slå av heile brannmuren er det ikkje, fordi resultatet vert umogleg å tilskrive. ss-dokumentasjonen dekkjer filtera som er brukte ovanfor, og det er eit billegare første steg enn kva innfanging som helst. Noter kva av dei to greinene du prova, og neste førekomst startar frå eit kjent svar.