VPN-port vaikib? Kuulaja, sidumisaadress või hosti tulemüür
Peatatud teenus ja tulemüüri tõrge nõuavad erinevat parandust. Uurige kõigepealt kohalikku soklit ja seejärel seostage üks lubatud väline katse logiga.
VPN ei vasta oma pordil mitte midagi ja kaks võimalikku põhjust nõuavad vastupidiseid parandusi: kas ükski protsess ei avanud soklit või sokkel on olemas ja miski masinate vahel peatab paketid. Üks käsk lahendab selle küsimuse esimese poole, seepärast käib see enne ükskõik millise tulemüürireegli puudutamist. Allpool olev järjekord eemaldab iga sammuga ühe seletuse, selle asemel et lisada veel üks oletus. Just kahe vahel oletamine muudab kümne minuti diagnoosi terveks õhtuks.
Eeldage, et saate serverisse sisse logida ja et klient on päris profiil, mitte skanner. Mõlemad eeldused on olulised, sest üldine sond ei saa vastata protokollipõhisele küsimusele.
Kas sokkel üldse olemas on
Alustage sellest, mida teenus ise enda kohta ütleb: kas see käivitus ja, mis kasulikum, milline oli selle esimene käivitusviga. Parsi tõrge, puuduv võti või sidumistõrge takistavad kuulajal üldse tekkimast ja protsess võib väljuda nii vaikselt, et olekurida loetakse mitmeti. Üksus, mis teatab end aktiivsena, ei ole iseenesest tõestus, sest põhiprotsess võib elus olla, samal ajal kui porti siduma pidanud komponent on juba alla andnud.
systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp
Soklite loend on fakt, millele ülejäänud diagnoos toetub. Lugege kohaliku aadressi veergu, mitte ainult porti, sest just selles veerus ilmuvad loopback-sidumised ja vale liidese sidumised. Kuulaja, mis on olemas aadressil 127.0.0.1, töötab laitmatult ja on ikkagi teie sülearvutile nähtamatu.
Millisel aadressil ja aadressiperes sokkel vastab
Kaks viga näevad kliendi poolt identsed välja ja seletavad enamikku "ei ole kättesaadav" teateid. Loopback-aadressile seotud server ei võta kunagi vastu liiklust teisest masinast ja ainult IPv4-aadressile seotud server ei vasta kunagi kliendile, kes valib sama hosti IPv6-aadressi. Võrrelge soklite tabelis olevat aadressi aadressiga, millele klient tegelikult helistab, märk märgi haaval, enne kui poliitika kohta midagi eeldate.
Loendi piiramine ühe pordiga hoiab selle loetavana, kui hostis töötab mitu teenust. sport-filter võtab pordi koos transportiga, mida te testite:
ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'
Protokolli veerg muudab kogu vastust
Soklite tabel indekseerib nii protokolli kui ka pordi järgi ja need on kaks sõltumatut kirjet. Teenus, mis vastab TCP-le pordil 1194, ei ütle teile midagi selle kohta, kas midagi kuulab UDP pordil 1194, ja klient kasutab alati ainult ühte neist. Kinnitage, millise transpordi serveri konfiguratsioon valib ja millise kliendi profiil saadab, ning otsige siis täpselt seda rida.
UDP-l on teine nüanss: autentimata sond ei ole viga, millele teenus peab vastama. Skaneering, mis teatab pordi vaikseks, on mõõtnud teenuse diskreetsust, mitte selle kättesaadavust, seega testige päris kliendi ja profiiliga.
Üks katse, kolm kohta vaadata
Tehke heakskiidetud kliendist täpselt üks katse ja kirjutage aeg sekundi täpsusega üles. Seejärel lugege selle ajavahemiku kohta kolme allikat: teenusepakkuja võrgureegel või konsool, hosti tulemüüri loendurid või logi ja teenuse enda logi. Ühekordne tegemine teeb kolm tunnistust võrreldavaks ja maksab vähem kui katse kordamine, mille ajatemplit keegi üles ei kirjutanud.
Kaks tulemust osutavad vastassuundades. Kui ükski pakett hostini ei jõudnud, viskab tee selle kõrvale ja kuulaja on ebaoluline. Kui pakett jõudis soklini ja teenus lükkas selle tagasi, on tee korras ja vastus peitub protokollis, krüptograafias või mandaatides. Pordi avamine teenusele, mis on ühenduse juba vastu võtnud, muudab järgmise diagnoosi raskemaks, mitte lihtsamaks.
Nimetage etapp enne, kui reeglit muudate
Läbirääkimised, mis algavad, ja autentimine, mis ebaõnnestub, on üks tõrge, ning tunnel, mis luuakse samal ajal kui edastamine takerdub, on hoopis teine. Etapi esmalt nimetamine hoiab paranduse kitsana: mandaadiprobleemi ei paranda tulemüürireegel ja andmetee probleemi ei paranda taaskäivitus.
Kasutage kitsaimat diagnostikat, mis küsimusele vastab. Ajutine paketivaatlus ühel pordil administraatori kontrolli all on mõistlik vahend; kogu tulemüüri väljalülitamine ei ole, sest tulemust muutub võimatuks omistada. ss-i dokumentatsioon katab ülal kasutatud filtrid ja see on odavam esimene samm kui ükski püüdmine. Kirjutage üles, kumma kahest harust te tõestasite, ja järgmine juhtum algab teadaolevast vastusest.