VPN ports klusē? Klausītājs, saistīšanas adrese vai resursdatora ugunsmūris

VPN savā portā neko neatbild, un divi iespējamie cēloņi prasa pretēju labošanu: vai nu neviens process neatvēra ligzdu, vai ligzda pastāv un kaut kas starp mašīnām aptur paketes. Viena komanda izšķir pirmo šī jautājuma pusi, tāpēc tā nāk pirms jebkura ugunsmūra noteikuma. Zemāk dotā kārtība katrā solī noņem vienu skaidrojumu, nevis pievieno vēl vienu minējumu. Tieši minēšana starp abiem desmit minūšu diagnostiku pārvērš visā vakarā.

Pieņemiet, ka varat pieslēgties serverim un ka klients ir īsts profils, nevis skeneris. Abi pieņēmumi ir svarīgi, jo vispārīgs zondētājs nevar atbildēt uz protokolam raksturīgu jautājumu.

Vai ligzda vispār pastāv

Sāciet ar to, ko pakalpojums stāsta par sevi: vai tas startēja un, lietderīgāk, kāda bija tā pirmā startēšanas kļūda. Parsēšanas kļūda, trūkstoša atslēga vai saistīšanas kļūda neļauj klausītājam rasties, un process var iziet tik klusi, ka statusa rinda tiek lasīta neviennozīmīgi. Vienība, kas ziņo par sevi kā aktīvu, pati par sevi nav pierādījums, jo galvenais process var būt dzīvs, kamēr komponente, kurai vajadzēja saistīt portu, jau ir padevusies.

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

Ligzdu saraksts ir fakts, uz kura balstās pārējā diagnostika. Lasiet vietējās adreses kolonnu, nevis tikai portu, jo tieši šajā kolonnā parādās saistīšana ar loopback un saistīšana ar nepareizo interfeisu. Klausītājs, kas pastāv uz 127.0.0.1, darbojas nevainojami un tomēr paliek neredzams jūsu portatīvajam datoram.

Uz kādas adreses un ģimenes ligzda atbild

Divas kļūdas no klienta puses izskatās vienādi un izskaidro lielāko daļu "nav sasniedzams" ziņojumu. Serveris, kas saistīts ar loopback adresi, nekad nepieņem trafiku no citas mašīnas, un serveris, kas saistīts tikai ar IPv4 adresi, nekad neatbild klientam, kurš sastāda tā paša resursdatora IPv6 adresi. Pirms kaut ko pieņemt par politiku, salīdziniet ligzdu tabulā esošo adresi ar adresi, kuru klients faktiski sastāda, burtu pa burtam.

Saraksta ierobežošana ar vienu portu saglabā to lasāmu, kad resursdators darbina vairākus pakalpojumus. sport filtrs ņem portu kopā ar transportu, kuru jūs testējat:

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

Protokola kolonna maina visu atbildi

Ligzdu tabula indeksē gan pēc protokola, gan pēc porta, un tie ir divi neatkarīgi ieraksti. Pakalpojums, kas atbild uz TCP 1194. portā, neko nepasaka par to, vai kaut kas klausās UDP 1194, un klients vienmēr izmantos tikai vienu no tiem. Apstipriniet, kuru transportu izvēlas servera konfigurācija un kuru sūta klienta profils, tad meklējiet tieši to rindu.

UDP ir otrs līkums: neautentificēts zondētājs nav kļūda, uz kuru pakalpojumam jāatbild. Skeneris, kas ziņo portu kā klusu, ir izmērījis pakalpojuma atturību, nevis tā pieejamību, tāpēc testējiet ar īstu klientu un profilu.

Viens mēģinājums, trīs vietas, kur paskatīties

No apstiprināta klienta veiciet tieši vienu mēģinājumu un pierakstiet laiku līdz sekundei. Pēc tam izlasiet trīs avotus šim logam: pakalpojumu sniedzēja tīkla noteikumu vai konsoli, resursdatora ugunsmūra skaitītājus vai žurnālu un paša pakalpojuma žurnālu. Vienreizēja izdarīšana padara trīs liecības salīdzināmas, un tas izmaksā mazāk nekā mēģinājuma atkārtošana, kura laika zīmogu neviens nav pierakstījis.

Divi iznākumi rāda pretējos virzienos. Ja neviens pakets nav sasniedzis resursdatoru, ceļš to nomet un klausītājs nav nozīmīgs. Ja pakets ir nonācis līdz ligzdai un pakalpojums to noraidīja, ceļš ir kārtībā un atbilde ir protokolā, kriptogrāfijā vai akreditācijas datos. Porta atvēršana pakalpojumam, kas jau ir pieņēmis savienojumu, padara nākamo diagnostiku grūtāku, nevis vieglāku.

Nosauciet posmu pirms noteikuma maiņas

Sākas pārrunas un neizdodas autentifikācija — tas ir viens bojājums, un tunelis, kas izveidojas, kamēr pārsūtīšana iestrēgst, ir pavisam cits. Posma nosaukšana vispirms notur labošanu šauru: akreditācijas datu problēmu neatrisina ugunsmūra noteikums, un datu ceļa problēmu neatrisina restartēšana.

Izmantojiet šaurāko diagnostiku, kas atbild uz jautājumu. Īslaicīga pakešu novērošana vienā portā administratora kontrolē ir saprātīgs instruments; visas ugunsmūra izslēgšana nav, jo rezultātu kļūst neiespējami kam piedēvēt. ss dokumentācija aptver iepriekš izmantotos filtrus, un tas ir lētāks pirmais solis nekā jebkura uztveršana. Pierakstiet, kuru no diviem zariem esat pierādījis, un nākamā reize sāksies ar zināmu atbildi.