Vrata VPN molčijo? Poslušalec, naslov vezave ali požarni zid gostitelja
Ustavljena storitev in zavrženje požarnega zidu zahtevata različno popravilo. Najprej preglejte lokalno vtičnico, nato povežite en poskus odobrenega zunanjega dostopa z dnevnikom.
VPN na svojih vratih ne odgovori nič, in dva možna vzroka zahtevata nasprotni popravili: bodisi noben proces ni odprl vtičnice, bodisi vtičnica obstaja in nekaj med stroji ustavlja pakete. En ukaz razreši prvo polovico tega vprašanja, zato je pred vsakim pravilom požarnega zidu. Vrstni red spodaj odstrani po eno razlago na korak, namesto da bi dodal še eno domnevo. Prav ugibanje med obema spremeni desetminutno diagnostiko v cel večer.
Predpostavite, da se lahko prijavite na strežnik in da je odjemalec pravi profil, ne skener. Obe predpostavki štejeta, ker splošna sonda ne more odgovoriti na vprašanje, specifično za protokol.
Ali vtičnica sploh obstaja
Začnite s tem, kar storitev pove o sebi: ali se je zagnala in, bolj uporabno, kakšna je bila njena prva napaka ob zagonu. Napaka pri razčlenjevanju, manjkajoč ključ ali napaka pri vezavi preprečijo, da bi poslušalec sploh nastal, proces pa lahko izstopi tako tiho, da se vrstica stanja bere dvoumno. Enota, ki se prijavi kot aktivna, sama po sebi ni dokaz, ker je glavni proces lahko živ, medtem ko je komponenta, ki bi morala vezati vrata, že obupala.
systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp
Seznam vtičnic je dejstvo, na katerem stoji preostala diagnostika. Berite stolpec lokalnega naslova in ne le vrat, ker se v tem stolpcu pokažejo vezave na loopback in vezave na napačen vmesnik. Poslušalec, ki obstaja na 127.0.0.1, deluje brezhibno in je še vedno neviden za vaš prenosnik.
Na katerem naslovu in družini vtičnica odgovarja
Dve napaki sta z odjemalčeve strani videti enako in pojasnita večino poročil "nedosegljivo". Strežnik, vezan na naslov loopback, nikoli ne sprejme prometa z drugega stroja, in strežnik, vezan samo na naslov IPv4, nikoli ne odgovori odjemalcu, ki kliče naslov IPv6 istega gostitelja. Preden karkoli domnevate o politiki, primerjajte naslov v tabeli vtičnic z naslovom, ki ga odjemalec dejansko kliče, znak za znakom.
Če seznam omejite na ena vrata, ostane berljiv, ko gostitelj izvaja več storitev. Filter sport vzame vrata skupaj s transportom, ki ga preizkušate:
ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'
Stolpec protokola spremeni ves odgovor
Tabela vtičnic se indeksira po protokolu in po vratih, in to sta dva neodvisna vnosa. Storitev, ki odgovarja na TCP na 1194, ne pove ničesar o tem, ali kaj posluša na UDP 1194, odjemalec pa bo vedno uporabil le enega od njiju. Potrdite, kateri transport izbere konfiguracija strežnika in katerega pošlje profil odjemalca, nato poiščite točno tisto vrstico.
UDP ima drug pregib: neoverjena sonda ni napaka, na katero bi morala storitev odgovoriti. Skeniranje, ki vrata prijavi kot tiha, je izmerilo diskretnost storitve, ne njene razpoložljivosti, zato preizkusite s pravim odjemalcem in profilom.
En poskus, trije kraji za pogled
Z odobrenega odjemalca naredite natanko en poskus in zapišite čas do sekunde. Nato preberite tri vire za to okno: omrežno pravilo ali konzolo ponudnika, števce ali dnevnik požarnega zidu gostitelja in lastni dnevnik storitve. Enkratna izvedba naredi tri pričevanja primerljiva in stane manj kot ponavljanje poskusa, katerega časovnega žiga ni nihče zapisal.
Dva izida kažeta v nasprotnih smereh. Če noben paket ni dosegel gostitelja, ga pot zavrže in poslušalec ni pomemben. Če je paket dosegel vtičnico in ga je storitev zavrnila, je pot v redu in odgovor je v protokolu, kriptografiji ali poverilnicah. Odpiranje vrat za storitev, ki je že sprejela povezavo, naredi naslednjo diagnostiko težjo, ne lažjo.
Poimenujte stopnjo, preden spremenite pravilo
Pogajanja, ki se začnejo, in preverjanje pristnosti, ki spodleti, sta ena napaka, tunel, ki se vzpostavi, medtem ko se posredovanje ustavi, pa povsem druga. Če stopnjo poimenujete najprej, popravilo ostane ozko: težave s poverilnicami ne odpravi pravilo požarnega zidu, težave z podatkovno potjo pa ne odpravi ponovni zagon.
Uporabite najožjo diagnostiko, ki odgovori na vprašanje. Začasno opazovanje paketov na enih vratih pod nadzorom skrbnika je razumno orodje; izklop celotnega požarnega zidu ni, ker rezultata ni več mogoče pripisati. Dokumentacija ss pokriva zgoraj uporabljene filtre in je cenejši prvi korak od vsakega zajema. Zapišite, katero od dveh vej ste dokazali, in naslednji primer se začne z znanim odgovorom.