A quins ports escolta realment OpenVPN Access Server?

Executeu ss -lntup en un amfitrió d’Access Server i obteniu una llista el doble de llarga del que s’esperava. La meitat de les entrades són ports amb forma de dimoni que ningú no va esmentar durant la configuració. El reflex és tancar tot el que no sigui 443 o 1194, i així és com la gent trenca el seu propi portal de clients.

Access Server no és un sol oient. És un servei VPN, un servei web i un participant de clúster, i pot generar ports addicionals específics de dimoni i redireccions de tallafoc segons quants dimonis TCP hàgiu configurat.

Recorreu l’inventari en ordre: llegiu els sockets, mapau els coneguts, classifiqueu la resta per propietari i vinculació, i després comproveu què els publica realment.

Comenceu amb una ordre només de lectura

sudo ss -lntup us dona transport, adreça local, port i procés propietari per a cada socket que escolta. Els indicadors importen: -l escolta, -n numèric, -t TCP, -u UDP, -p procés. Sense root obteniu els sockets però no els noms dels processos, i aquesta és precisament la columna que necessiteu per classificar.

Anoteu quatre camps per fil abans de formar-vos cap opinió: protocol, adreça de vinculació, port i ordre. Manteniu la versió d’Access Server i el nombre de dimonis configurat al costat d’aquesta llista, perquè tots dos canvien el que s’espera.

Dues files que semblen idèntiques no ho són. TCP i UDP al mateix número són sockets separats amb exposició separada, i 0.0.0.0 i :: són vinculacions separades per a famílies d’adreces separades. Un servei vinculat només a 127.0.0.1 no és directament abastable des d’un altre amfitrió, tot i que una redirecció local encara el pot publicar.

Els oients que hauríeu de reconèixer

Aquests valors per defecte cobreixen la majoria de desplegaments i us donen una base per comparar. Són valors per defecte, no pas una llista d’autoritzacions completa.

Tot el que hi ha més enllà necessita una explicació, no una suposició. Sovint veureu oients només locals que pertanyen a components que el producte instal·la per a si mateix. Confirmeu-los per PID i configuració del servei en lloc d’un número de port recordat, i no tracteu un port desconegut com a hostil només perquè és desconegut.

Un socket fora de la parella coneguda tampoc no és automàticament una resta. Quan es configuren diversos dimonis TCP, Access Server crea oients per dimoni i hi redirigeix el trànsit, de manera que el seu nombre i valors de port segueixen aquesta configuració.

Classifiqueu abans de tancar res

Per a cada fil incert, responeu tres preguntes en aquest ordre.

1. Propietari i propòsit. Feu coincidir el PID amb una unitat o procés i llegiu la configuració d’aquest servei. Si no podeu anomenar el propietari, no esteu a punt per decidir res sobre el socket.
2. Abast de la vinculació. Loopback és local a l’espai de noms. Una vinculació comodí només és abastable si l’encaminament, el filtratge d’amfitrió i qualsevol regla de nivell de núvol ho permeten, així que l’adreça de vinculació és necessària però no suficient. Comproveu IPv4 i IPv6 com a decisions separades.
3. Camí publicat. Cerqueu el reenviament de servei, les redireccions específiques de dimoni, un proxy extern i la política efectiva de tallafoc. Aquest és el pas que la gent s’estalvia, i és el que converteix un port de backend aparentment inofensiu en un camí administratiu abastable.

La mateixa pregunta es llegeix diferent des de fora de l’amfitrió. Un port sense regla de tallafoc d’amfitrió encara pot ser tancat per un grup de seguretat del núvol, i un port amb una regla permissiva d’amfitrió pot ser inabastable perquè res no hi encamina. Mireu els dos extrems abans d’escriure la conclusió de l’inventari.

On el camí publicat difereix de la llista de sockets

La documentació pròpia d’Access Server cobreix el cas que causa més confusió: quan s’executen diversos dimonis TCP, el port frontal reenvia a ports específics de dimoni, i la disposició visible deixa de coincidir amb la llista de sockets. El tutorial de filtratge de la interfície web descriu aquestes regles i per què un filtre escrit només per al port obvi pot passar per alt del tot el camí redirigit.

El control de clúster és el segon lloc on la versió importa. A 3.0 i versions posteriors comparteix 943; les configuracions de clúster antigues utilitzaven 945. Obrir o bloquejar un d’ells sense comprovar la versió produeix un inventari que sembla ordenat i és incorrecte.

Així, la superfície visible des de fora és la unió de tres coses: sockets que escolten, regles de reenviament que els tornen a publicar i controls de xarxa davant de l’amfitrió. Qualsevol inventari que només registri la primera és incomplet, i qualsevol canvi que només consideri la primera o bé deixarà un camí obert o bé tallarà un servei.

Verifiqueu després de qualsevol canvi

Canvieu la configuració dels oients a través del propietari de configuració admès i manteniu una consola de recuperació oberta mentre ho feu. Perdre l’accés administratiu a una interfície web en un amfitrió remot no es recupera a través de la VPN que acabeu de desactivar.

A continuació, valideu les quatre coses que un desplegament normalment necessita: un client VPN es connecta, el portal de clients carrega, l’accés administratiu funciona i la comunicació de clúster continua funcionant si executeu més d’un node. Una prova només de VPN passa còmodament mentre el portal està trencat.

Acabeu anotant el camí permès per a cada servei: quin socket, quina vinculació, quina regla de reenviament, quin control de xarxa. Aquest document és el resultat de seguretat útil. Un recompte mínim de sockets no ho és, i tampoc no ho és un reinici massiu que tanca oients que ningú no ha acabat d’identificar.