Watter poorte luister OpenVPN Access Server werklik op?
Stap deur die sokinglys op ’n Access Server-gasheer: herken die verstekluisteraars, onderskei loopback van gepubliseerde poorte, en kontroleer aanstuur voordat jy ’n poort sluit.
Jy hardloop ss -lntup op ’n Access Server-gasheer en kry ’n lys wat twee keer so lank as verwag is. Die helfte van die inskrywings is daemon-vormige poorte wat niemand tydens die opstelling genoem het nie. Die refleks is om alles toe te maak wat nie 443 of 1194 is nie, en dit is hoe mense hul eie kliëntportaal breek.
Access Server is nie een luisteraar nie. Dit is ’n VPN-diens, ’n webdiens en ’n deelnemer aan ’n cluster, en dit kan ekstra daemonspesifieke poorte en firewall-aansturings skep, afhangend van hoeveel TCP-daemons jy opgestel het.
Stap die inventaris in volgorde deur: lees die sokke, karteer die bekende een, klassifiseer die res volgens eienaar en binding, en kontroleer dan wat hulle werklik publiseer.
Begin met een lees-alleen-opdrag
sudo ss -lntup gee jou vervoer, plaaslike adres, poort en eienaarproses vir elke luisterende sok. Die vlae maak saak: -l luister, -n numeries, -t TCP, -u UDP, -p proses. Sonder root kry jy sokke maar nie prosesname nie, en dit is juis die kolom wat jy vir klassifikasie nodig het.
Teken vier velde per ry aan voordat jy enige mening vorm: protokol, bindadres, poort en opdrag. Hou die Access Server-weergawe en die opgestelde daemon-telling langs daardie lys, want albei verander wat verwag word.
Twee rye wat identies lyk, is nie. TCP en UDP op dieselfde nommer is aparte sokke met aparte blootstelling, en 0.0.0.0 en :: is aparte bindings vir aparte adresfamilies. ’n Diens wat slegs aan 127.0.0.1 gebind is, is nie direk vanaf ’n ander gasheer bereikbaar nie, hoewel ’n plaaslike aansturing dit steeds kan publiseer.
Die luisteraars wat jy behoort te herken
Hierdie verstekke dek die meeste ontplooiings en gee jou ’n basislyn om mee te vergelyk. Dit is verstekke, nie ’n volledige toelaatlys nie.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
Alles daarbuite het ’n verduideliking nodig, nie ’n aanname nie. Jy sal dikwels slegs-plaaslike luisteraars sien wat aan komponente behoort wat die produk self installeer. Bevestig hulle deur PID en dienskonfigurasie eerder as deur ’n onthoude poortnommer, en moenie ’n onbekende poort as vyandig beskou bloot op grond van onbekendheid nie.
’n Sok buite die bekende paar is ook nie outomaties ’n oorblyfsel nie. Wanneer verskeie TCP-daemons opgestel is, skep Access Server luisteraars per daemon en stuur verkeer daarheen, so hul aantal en poortwaardes volg daardie opstelling.
Klassifiseer voordat jy enigiets sluit
Vir elke onsekere ry, beantwoord drie vrae in hierdie volgorde.
- Eienaar en doel. Pas die PID by ’n eenheid of proses en lees daardie diens se konfigurasie. As jy nie die eienaar kan noem nie, is jy nie gereed om enigiets oor die sok te besluit nie.
- Bindingsomvang. Loopback is plaaslik tot die naamruimte. ’n Wildcard-binding is slegs bereikbaar as roetering, gasheerfiltering en enige wolkvlakreëls dit toelaat, so die bindadres is nodig maar nie voldoende nie. Kontroleer IPv4 en IPv6 as aparte besluite.
- Gepubliseerde pad. Soek na diensaansturing, daemonspesifieke aansturings, ’n eksterne proxy en die effektiewe firewallbeleid. Dit is die stap wat mense oorslaan, en dit is die een wat ’n skadeloos-lykende backend-poort in ’n bereikbare administratiewe pad verander.
Dieselfde vraag lees anders van buite die gasheer. ’n Poort sonder ’n gasheer-firewallreël kan steeds deur ’n wolk-sekuriteitsgroep gesluit word, en ’n poort met ’n toelatende gasheerreël kan onbereikbaar wees omdat niks daarheen roete nie. Kyk na beide kante voordat jy die inventarisgevolgtrekking skryf.
Waar die gepubliseerde pad van die soklys verskil
Access Server se eie dokumentasie dek die geval wat die meeste verwarring veroorsaak: wanneer verskeie TCP-daemons loop, stuur die frontport aan na daemonspesifieke poorte, en die sigbare uitleg hou op om by die soklys te pas. Die tutoriaal oor webkoppelvlakfiltering beskryf daardie reëls en waarom ’n filter wat slegs vir die ooglopende poort geskryf is, die aangestuurde pad heeltemal kan mis.
Clusterbeheer is die tweede plek waar die weergawe saak maak. Op 3.0 en nuwer deel dit 943; ouer clusteropstellings het 945 gebruik. Om een van hulle oop te maak of te blokkeer sonder om die weergawe na te gaan, lewer ’n inventaris op wat netjies lyk en verkeerd is.
Die ekstern sigbare oppervlak is dus die vereniging van drie dinge: luisterende sokke, aansturingsreëls wat hulle herpubliseer, en die netwerkbeheermaatreëls voor die gasheer. Enige inventaris wat slegs die eerste aanteken, is onvolledig, en enige verandering wat slegs die eerste oorweeg, sal óf ’n pad oop laat óf ’n diens afsny.
Verifieer ná enige verandering
Verander luisterinstellings deur die ondersteunde konfigurasie-eienaar en hou ’n herstelkonsole oop terwyl jy dit doen. Om administratiewe toegang tot ’n webkoppelvlak op ’n afgeleë gasheer te verloor, is nie deur die VPN wat jy pas afgeskakel het herstelbaar nie.
Valideer dan die vier dinge wat ’n ontplooiing gewoonlik nodig het: ’n VPN-kliënt verbind, die kliëntportaal laai, administratiewe toegang werk, en clusterkommunikasie funksioneer steeds as jy meer as een node hardloop. ’n Slegs-VPN-toets slaag gemaklik terwyl die portaal stukkend is.
Sluit af deur die toegelate pad vir elke diens neer te skryf: watter sok, watter binding, watter aansturingsreël, watter netwerkbeheer. Daardie dokument is die nuttige sekuriteitsuitset. ’n Minimale soktelling is nie, en ’n massa-herstel wat luisteraars sluit wat niemand klaar geïdentifiseer het, is ook nie.