Hallgat a VPN-port? Figyelő, kötési cím vagy a gép tűzfala

A VPN semmit sem válaszol a portján, és a két lehetséges ok ellentétes javítást kíván: vagy egyetlen folyamat sem nyitotta meg a socketet, vagy a socket létezik, és valami a gépek között megállítja a csomagokat. Egyetlen parancs eldönti a kérdés első felét, ezért minden tűzfalszabály előtt jön. Az alábbi sorrend lépésenként egy magyarázatot távolít el, nem újabb találgatást tesz hozzá. Éppen a kettő közötti találgatás az, ami a tízperces diagnózist egész estévé változtatja.

Tegyük fel, hogy be tud jelentkezni a kiszolgálóra, és hogy az ügyfél valódi profil, nem szkenner. Mindkét feltevés számít, mert egy általános szonda nem tud protokollspecifikus kérdésre válaszolni.

Létezik-e egyáltalán a socket

Kezdje azzal, amit a szolgáltatás magáról mond: hogy elindult-e, és hasznosabb módon, mi volt az első indítási hibája. Elemzési hiba, hiányzó kulcs vagy kötési hiba miatt a figyelő soha nem jön létre, és a folyamat olyan csendesen léphet ki, hogy az állapotsor kétértelműen olvasható. Az aktívnak jelentkező unit önmagában nem bizonyíték, mert a fő folyamat élhet, miközben a portot kötni hivatott komponens már feladta.

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

A socketlista az a tény, amelyen a diagnózis többi része nyugszik. A helyi cím oszlopát olvassa, ne csak a portot, mert ebben az oszlopban jelennek meg a loopback-kötések és a rossz interfészre történő kötések. A 127.0.0.1-en létező figyelő tökéletesen működik, és mégis láthatatlan a laptopjáról.

Melyik címen és címcsaládon válaszol a socket

Két hiba az ügyfél felől azonosnak látszik, és a legtöbb "nem elérhető" jelentést megmagyarázza. A loopback-címhez kötött kiszolgáló soha nem fogad forgalmat más gépről, és a csak IPv4-címhez kötött kiszolgáló soha nem válaszol az azonos hoszt IPv6-címét tárcsázó ügyfélnek. Hasonlítsa össze a sockettáblában szereplő címet azzal a címmel, amelyet az ügyfél valóban tárcsáz, karakterről karakterre, mielőtt bármit feltételezne a szabályzatról.

A lista egyetlen portra szűkítése olvashatóvá teszi, amikor a hoszt több szolgáltatást futtat. A sport szűrő a portot a vizsgált átvitellel együtt veszi:

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

A protokolloszlop megváltoztatja az egész választ

A sockettábla a port mellett a protokoll szerint is indexel, és ez két független bejegyzés. Az 1194-es TCP-re válaszoló szolgáltatás semmit nem mond arról, hogy figyel-e valami az UDP 1194-en, és az ügyfél mindig csak az egyiket használja. Erősítse meg, melyik átvitelt választja a kiszolgáló konfigurációja és melyiket küldi az ügyfélprofil, majd keresse pontosan azt a sort.

Az UDP-nek van egy második csavarja: a hitelesítetlen szonda nem hiba, amelyre a szolgáltatásnak válaszolnia kell. A portot csendesnek jelentő vizsgálat a szolgáltatás diszkrécióját mérte, nem az elérhetőségét, ezért a valódi ügyféllel és profillal teszteljen.

Egy kísérlet, három hely, ahol megnézni

Egy engedélyezett ügyfélről pontosan egy kísérletet tegyen, és írja fel az időt másodpercig. Utána olvasson be három forrást arra az időablakra: a szolgáltató hálózati szabályát vagy konzolját, a hoszt tűzfal-számlálóit vagy naplóját, és a szolgáltatás saját naplóját. Egyszeri elvégzése teszi a három beszámolót összehasonlíthatóvá, és kevesebbe kerül, mint megismételni egy kísérletet, amelynek időbélyegét senki nem jegyezte fel.

A két kimenet ellentétes irányba mutat. Ha egyetlen csomag sem érkezett a hosztra, az útvonal eldobja, és a figyelő irreleváns. Ha a csomag megérkezett a socketre és a szolgáltatás elutasította, az útvonal rendben van, és a válasz a protokollban, a kriptográfiában vagy a hitelesítő adatokban rejlik. Portot nyitni egy olyan szolgáltatásnak, amely már elfogadott egy kapcsolatot, nehezebbé teszi a következő diagnózist, nem könnyebbé.

Nevezze meg a szakaszt, mielőtt szabályt változtat

A megkezdődő egyeztetés és a meghiúsuló hitelesítés egyetlen hiba, és a létrejövő alagút, miközben a továbbítás elakad, egészen másik. A szakasz előzetes megnevezése szűken tartja a javítást: a hitelesítő adatok problémáját nem oldja meg tűzfalszabály, az adatútvonal problémáját pedig nem oldja meg újraindítás.

A legszűkebb diagnózist használja, amely válaszol a kérdésre. Egy porton végzett ideiglenes csomagmegfigyelés, adminisztrátor felügyelete alatt, észszerű eszköz; a teljes tűzfal kikapcsolása nem az, mert az eredményt lehetetlenné válik bármihez kötni. Az ss dokumentációja lefedi a fent használt szűrőket, és ez olcsóbb első lépés bármilyen rögzítésnél. Jegyezze fel, melyik ágat bizonyította, és a következő eset ismert válaszból indul.