Portul VPN tăcut? Ascultător, adresă de legare sau firewall al gazdei

VPN-ul nu răspunde nimic pe portul său, iar cele două cauze posibile cer reparații opuse: fie niciun proces nu a deschis socketul, fie socketul există și ceva între mașini oprește pachetele. O singură comandă decide prima jumătate a acestei întrebări, de aceea vine înaintea oricărei reguli de firewall. Ordinea de mai jos elimină o explicație pe pas în loc să adauge încă o presupunere. Tocmai ghicitul între cele două transformă un diagnostic de zece minute într-o seară întreagă.

Presupuneți că vă puteți autentifica pe server și că clientul este un profil real, nu un scaner. Ambele presupuneri contează, pentru că o sondă generică nu poate răspunde la o întrebare specifică protocolului.

Există socketul măcar

Începeți cu ce spune serviciul despre sine: dacă a pornit și, mai util, care a fost prima eroare la pornire. O eroare de analiză, o cheie lipsă sau o eroare de legare împiedică ascultătorul să existe, iar procesul poate ieși atât de silențios încât linia de stare se citește ambiguu. O unitate care se declară activă nu e dovadă de la sine, pentru că procesul principal poate fi viu în timp ce componenta care trebuia să lege portul a renunțat deja.

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

Lista socketurilor este faptul pe care se sprijină restul diagnosticului. Citiți coloana adresei locale, nu doar portul, pentru că în acea coloană apar legările pe loopback și legările pe interfața greșită. Un ascultător care există pe 127.0.0.1 funcționează perfect și rămâne invizibil pentru laptopul dumneavoastră.

Pe ce adresă și ce familie răspunde socketul

Două greșeli arată identic din partea clientului și explică majoritatea rapoartelor "inaccesibil". Un server legat de adresa de loopback nu acceptă niciodată trafic de pe altă mașină, iar un server legat doar de o adresă IPv4 nu răspunde niciodată unui client care formează adresa IPv6 a aceleiași gazde. Comparați adresa din tabelul de socketuri cu adresa pe care clientul o formează efectiv, caracter cu caracter, înainte de a presupune ceva despre politică.

Limitarea listei la un singur port o menține lizibilă când gazda rulează mai multe servicii. Filtrul sport ia portul împreună cu transportul pe care îl testați:

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

Coloana protocolului schimbă întregul răspuns

Tabelul de socketuri indexează atât după protocol, cât și după port, iar acestea sunt două intrări independente. Un serviciu care răspunde pe TCP la 1194 nu spune nimic despre dacă ceva ascultă pe UDP 1194, iar clientul va folosi mereu doar unul dintre ele. Confirmați ce transport alege configurația serverului și care este trimis de profilul clientului, apoi căutați exact acel rând.

UDP are o a doua cută: o sondă neautentificată nu este o eroare la care serviciul să fie obligat să răspundă. O scanare care raportează portul ca fiind mut a măsurat discreția serviciului, nu disponibilitatea lui, așa că testați cu clientul și profilul reale.

O încercare, trei locuri de privit

Dintr-un client aprobat faceți exact o încercare și notați timpul până la secundă. Apoi citiți trei surse pentru acea fereastră: regula de rețea sau consola furnizorului, contoarele sau jurnalul firewall-ului gazdei și jurnalul propriu al serviciului. A face asta o dată este ce face cele trei relatări comparabile și costă mai puțin decât repetarea unei încercări a cărei marcă de timp nu a notat-o nimeni.

Cele două rezultate indică direcții opuse. Dacă niciun pachet nu a ajuns la gazdă, calea îl aruncă și ascultătorul este irelevant. Dacă pachetul a ajuns la socket și serviciul l-a respins, calea este în regulă și răspunsul stă în protocol, criptografie sau acreditări. Deschiderea unui port pentru un serviciu care a acceptat deja o conexiune face următorul diagnostic mai greu, nu mai ușor.

Numiți etapa înainte de a schimba o regulă

O negociere care începe și o autentificare care eșuează sunt o singură defecțiune, iar un tunel care se stabilește în timp ce redirecționarea se blochează este cu totul alta. A numi etapa mai întâi păstrează reparația îngustă: o problemă de acreditări nu se rezolvă printr-o regulă de firewall, iar o problemă de cale a datelor nu se rezolvă printr-o repornire.

Folosiți diagnosticul cel mai îngust care răspunde la întrebare. O observare temporară de pachete pe un port, sub controlul unui administrator, este un instrument rezonabil; dezactivarea întregului firewall nu este, pentru că rezultatul devine imposibil de atribuit. Documentația ss acoperă filtrele folosite mai sus și este un prim pas mai ieftin decât orice captură. Notați care dintre cele două ramuri a fost dovedită, iar următoarea apariție începe de la un răspuns cunoscut.