VPN-poort stil? Luisteraar, bindadres of gasheer-firewall

Die VPN antwoord niks op sy poort nie, en die twee moontlike oorsake verg teenoorgestelde herstelwerk: óf geen proses het die socket oopgemaak nie, óf die socket bestaan en iets tussen die masjiene stop die pakkette. Een opdrag beslis die eerste helfte van daardie vraag, en daarom hoort dit voor enige firewall-reël aangeraak word. Die volgorde hier onder verwyder een verklaring per stap in plaas daarvan om nog 'n vermoede by te voeg. Om tussen die twee te raai is wat 'n diagnose van tien minute in 'n hele aand omskep.

Aanvaar dat jy by die bediener kan aanmeld en dat die kliënt 'n werklike profiel is, nie 'n skandeerder nie. Albei aannames maak saak, want 'n generiese probe kan nie 'n protokolspesifieke vraag beantwoord nie.

Bestaan die socket hoegenaamd

Begin met die diens se eie weergawe van homself: of dit opgekom het en, nuttiger, wat sy eerste beginfout was. 'n Ontledingsfout, 'n ontbrekende sleutel of 'n bindfout verhinder dat die luisteraar ooit bestaan, en die proses kan so stil wegval dat 'n statusreël dubbelsinnig lees. 'n Eenheid wat aktief rapporteer, is nie op sigself bewys nie, want die hoofproses kan leef terwyl die komponent wat die poort moes bind, al opgegee het.

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

Die socket-lys is die feit waarop die res van die diagnose rus. Lees die plaaslike adreskolom eerder as net die poort, want daardie kolom is waar lus-terug-bindings en verkeerde-koppelvlak-bindings opduik. 'n Luisteraar wat op 127.0.0.1 bestaan, werk heeltemal en is steeds onsigbaar vir jou skootrekenaar.

Op watter adres en adresfamilie die socket antwoord

Twee foute lyk identies van die kliënt se kant en verantwoord die meeste "nie bereikbaar nie"-verslae. 'n Bediener wat aan die lus-terug-adres gebind is, aanvaar nooit verkeer van 'n ander masjien nie, en 'n bediener wat net aan 'n IPv4-adres gebind is, antwoord nooit 'n kliënt wat die IPv6-adres van dieselfde gasheer skakel nie. Vergelyk die adres in die socket-tabel met die adres wat die kliënt werklik skakel, karakter vir karakter, voordat jy enigiets oor beleid aanneem.

Deur die lys tot een poort te beperk, bly dit leesbaar wanneer die gasheer verskeie dienste het. Die sport-filter neem die poort saam met die transport wat jy toets:

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

Die protokol-kolom verander die hele antwoord

Die socket-tabel sleutel op protokol sowel as poort, en die twee is onafhanklike inskrywings. 'n Diens wat TCP op 1194 antwoord, sê niks oor of iets op UDP 1194 luister nie, en die kliënt sal net een van die twee ooit gebruik. Bevestig watter transport die bediener-konfigurasie kies en watter die kliëntprofiel stuur, en soek dan daardie presiese ry.

UDP het 'n tweede kinkel: 'n ongemagtigde probe is nie 'n fout wat die diens hoef te antwoord nie. 'n Skandering wat die poort as stil rapporteer, het die diens se diskresie gemeet, nie sy beskikbaarheid nie, so toets met die werklike kliënt en profiel.

Een poging, drie plekke om te kyk

Maak vanaf 'n goedgekeurde kliënt presies een poging en skryf die tyd tot op die sekonde neer. Lees dan drie bronne vir daardie venster: die verskaffer se netwerk-reël of konsole, die gasheer se firewall-tellers of logboek, en die diens se eie logboek. Om dit een keer te doen, maak die drie weergawes vergelykbaar, en dit kos minder as om 'n poging te herhaal waarvan niemand die tydstempel aangeteken het nie.

Die twee uitkomste wys in teenoorgestelde rigtings. As geen pakket die gasheer bereik het nie, laat val die pad dit en is die luisteraar irrelevant. As die pakket by die socket aangekom het en die diens dit verwerp het, is die pad in orde en lê die antwoord in protokol, kriptografie of geloofsbriewe. Om 'n poort oop te maak vir 'n diens wat al 'n verbinding aanvaar het, maak die volgende diagnose moeiliker, nie makliker nie.

Noem die fase voordat jy 'n reël wysig

Onderhandeling wat begin en magtiging wat misluk, is een fout, en 'n tonnel wat vestig terwyl die deurstuur vasloop, is 'n heeltemal ander een. Om die fase eerste te noem, hou die herstelwerk eng: 'n geloofsbriefprobleem word nie deur 'n firewall-reël reggemaak nie, en 'n datapadprobleem word nie deur 'n herbegin reggemaak nie.

Gebruik die nouste diagnostiek wat die vraag beantwoord. 'n Tydelike pakket-waarneming op een poort, onder 'n administrateur se beheer, is 'n redelike instrument; om die hele firewall af te skakel is nie, want die resultaat word onmoontlik om toe te skryf. Die ss-dokumentasie dek die filters hierbo gebruik, en dit is 'n goedkoper eerste stap as enige opvang. Teken aan watter van die twee takke jy bewys het, en die volgende voorval begin by 'n bekende antwoord.