VPN prievadas tyli? Klausytojas, susiejimo adresas ar serverio užkarda

VPN nieko neatsako savo prievade, o dvi galimos priežastys reikalauja priešingo remonto: arba joks procesas neatidarė lizdo, arba lizdas egzistuoja ir kažkas tarp mašinų stabdo paketus. Viena komanda išsprendžia pirmąją šio klausimo pusę, todėl ji eina prieš bet kurią užkardos taisyklę. Toliau pateikta tvarka kiekviename žingsnyje pašalina vieną paaiškinimą, o ne prideda dar vieną spėjimą. Būtent spėliojimas tarp šių dviejų dešimties minučių diagnostiką paverčia visu vakarą.

Tarkime, kad galite prisijungti prie serverio ir kad klientas yra tikras profilis, o ne skaitytuvas. Abi prielaidos svarbios, nes bendras zondas negali atsakyti į protokolui būdingą klausimą.

Ar lizdas iš viso egzistuoja

Pradėkite nuo to, ką paslauga sako apie save: ar ji startavo ir, naudingiau, kokia buvo pirmoji jos paleidimo klaida. Analizės klaida, trūkstamas raktas ar susiejimo klaida neleidžia klausytojui atsirasti, o procesas gali išeiti taip tyliai, kad būsenos eilutė skaitoma dviprasmiškai. Vienetas, kuris praneša esąs aktyvus, pats savaime nėra įrodymas, nes pagrindinis procesas gali būti gyvas, kol komponentas, kuris turėjo susieti prievadą, jau pasidavė.

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

Lizdų sąrašas yra faktas, kuriuo remiasi likusi diagnostika. Skaitykite vietinio adreso stulpelį, o ne vien prievadą, nes būtent tame stulpelyje matosi susiejimai su loopback ir su netinkama sąsaja. Klausytojas, kuris egzistuoja 127.0.0.1 adresu, veikia nepriekaištingai ir vis tiek lieka nematomas jūsų nešiojamajam kompiuteriui.

Kokiu adresu ir kokioje šeimoje lizdas atsako

Dvi klaidos iš kliento pusės atrodo vienodai ir paaiškina daugumą "nepasiekiama" pranešimų. Serveris, susietas su loopback adresu, niekada nepriima srauto iš kitos mašinos, o serveris, susietas tik su IPv4 adresu, niekada neatsako klientui, kuris renka to paties serverio IPv6 adresą. Prieš ką nors manydami apie politiką, palyginkite lizdų lentelės adresą su adresu, kurį klientas iš tikrųjų renka, po ženklą.

Sąrašo apribojimas vienu prievadu išlaiko jį įskaitomą, kai serveris paleidžia kelias paslaugas. sport filtras ima prievadą kartu su transportu, kurį tikrinate:

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

Protokolo stulpelis pakeičia visą atsakymą

Lizdų lentelė indeksuojama pagal protokolą ir pagal prievadą, ir tai yra du nepriklausomi įrašai. Paslauga, kuri atsako TCP 1194 prievade, nieko nesako apie tai, ar kas nors klausosi UDP 1194, o klientas visada naudos tik vieną iš jų. Patvirtinkite, kokį transportą pasirenka serverio konfigūracija ir kokį siunčia kliento profilis, tada ieškokite būtent tos eilutės.

UDP turi antrą vingį: neautentifikuotas zondas nėra klaida, į kurią paslauga privalo atsakyti. Nuskaitymas, kuris praneša prievadą kaip tylų, išmatavo paslaugos santūrumą, o ne jos prieinamumą, todėl tikrinkite su tikru klientu ir profiliu.

Vienas bandymas, trys vietos pažiūrėti

Iš patvirtinto kliento atlikite tiksliai vieną bandymą ir užrašykite laiką iki sekundės. Tada perskaitykite tris šaltinius tam laikotarpiui: teikėjo tinklo taisyklę ar konsolę, serverio užkardos skaitiklius ar žurnalą ir pačios paslaugos žurnalą. Vienkartinis atlikimas padaro tris liudijimus palyginamus ir kainuoja mažiau nei kartoti bandymą, kurio laiko žymos niekas neužrašė.

Du rezultatai rodo priešingomis kryptimis. Jei nė vienas paketas nepasiekė serverio, kelias jį meta ir klausytojas nesvarbus. Jei paketas pasiekė lizdą ir paslauga jį atmetė, kelias tvarkingas ir atsakymas yra protokole, kriptografijoje ar kredencialuose. Prievado atidarymas paslaugai, kuri jau priėmė ryšį, padaro kitą diagnostiką sunkesnę, o ne lengvesnę.

Pavadinkite etapą prieš keisdami taisyklę

Prasidedančios derybos ir nepavykstanti autentifikacija yra vienas gedimas, o tunelis, kuris užsimezga, kai persiuntimas stringa, yra visai kitas. Etapo pavadinimas pirmiausia išlaiko remontą siaurą: kredencialų problema neišsprendžiama užkardos taisykle, o duomenų kelio problema neišsprendžiama perkrovimu.

Naudokite siauriausią diagnostiką, kuri atsako į klausimą. Laikinas paketų stebėjimas viename prievade, administratoriaus kontroliuojamas, yra pagrįstas įrankis; visos užkardos išjungimas nėra, nes rezultatą tampa neįmanoma kam nors priskirti. ss dokumentacija apima aukščiau naudotus filtrus, ir tai pigesnis pirmas žingsnis nei bet koks užfiksavimas. Užsirašykite, kurią iš dviejų šakų įrodėte, ir kitas atvejis prasideda nuo žinomo atsakymo.