Op welke poorten luistert OpenVPN Access Server eigenlijk?

Je voert ss -lntup uit op een Access Server-host en krijgt een lijst die twee keer zo lang is als verwacht. De helft van de regels zijn daemonvormige poorten die niemand tijdens de installatie noemde. De reflex is alles te sluiten wat geen 443 of 1194 is, en zo slopen mensen hun eigen klantenportaal.

Access Server is niet één listener. Het is een VPN-dienst, een webdienst en een clusterdeelnemer, en het kan extra daemonspecifieke poorten en firewall-doorstueringen genereren, afhankelijk van hoeveel TCP-daemons je hebt geconfigureerd.

Loop de inventaris in volgorde door: lees de sockets, breng de bekende in kaart, classificeer de rest op eigenaar en binding, en controleer dan wat ze werkelijk publiceert.

Begin met één alleen-lezen commando

sudo ss -lntup geeft je transport, lokaal adres, poort en eigenaarsproces voor elke luisterende socket. De vlaggen zijn belangrijk: -l luisteren, -n numeriek, -t TCP, -u UDP, -p proces. Zonder root krijg je sockets maar geen procesnamen, en dat is precies de kolom die je voor classificatie nodig hebt.

Noteer vier velden per regel voordat je een oordeel vormt: protocol, bindadres, poort en commando. Houd de Access Server-versie en het geconfigureerde aantal daemons naast die lijst, want beide veranderen wat er verwacht wordt.

Twee regels die er identiek uitzien zijn dat niet. TCP en UDP op hetzelfde nummer zijn aparte sockets met aparte blootstelling, en 0.0.0.0 en :: zijn aparte bindingen voor aparte adresfamilies. Een dienst die alleen aan 127.0.0.1 is gebonden, is niet rechtstreeks bereikbaar vanaf een andere host, hoewel een lokale doorsturing hem nog steeds kan publiceren.

De listeners die je zou moeten herkennen

Deze standaardwaarden dekken de meeste implementaties en geven je een basis om mee te vergelijken. Het zijn standaardwaarden, geen volledige toelatingslijst.

Alles daarbuiten vraagt om een verklaring, niet om een aanname. Je zult vaak alleen-lokale listeners zien die toebehoren aan componenten die het product voor zichzelf installeert. Bevestig ze via PID en serviceconfiguratie in plaats van een onthouden poortnummer, en behandel een onbekende poort niet als vijandig alleen omdat hij onbekend is.

Een socket buiten het bekende paar is ook niet automatisch een overblijfsel. Wanneer meerdere TCP-daemons zijn geconfigureerd, maakt Access Server listeners per daemon en leidt verkeer daarnaar door, dus hun aantal en poortwaarden volgen die configuratie.

Classificeer voordat je iets sluit

Beantwoord voor elke onzekere regel drie vragen in deze volgorde.

1. Eigenaar en doel. Koppel de PID aan een unit of proces en lees de configuratie van die dienst. Als je de eigenaar niet kunt benoemen, ben je niet klaar om iets over de socket te beslissen.
2. Bindingsbereik. Loopback is lokaal voor de naamruimte. Een wildcard-binding is alleen bereikbaar als routing, hostfiltering en eventuele regels op cloudniveau het toestaan, dus het bindadres is noodzakelijk maar niet voldoende. Controleer IPv4 en IPv6 als aparte beslissingen.
3. Gepubliceerd pad. Zoek naar doorgifte van diensten, daemonspecifieke doorsturingen, een externe proxy en het effectieve firewallbeleid. Dit is de stap die mensen overslaan, en het is degene die een onschuldig lijkende backend-poort verandert in een bereikbaar administratief pad.

Dezelfde vraag leest anders van buiten de host. Een poort zonder host-firewallregel kan nog steeds door een cloudbeveiligingsgroep worden gesloten, en een poort met een ruime hostregel kan onbereikbaar zijn omdat niets ernaartoe routeert. Kijk naar beide uiteinden voordat je de conclusie van de inventaris opschrijft.

Waar het gepubliceerde pad afwijkt van de socketlijst

De eigen documentatie van Access Server behandelt het geval dat de meeste verwarring veroorzaakt: wanneer meerdere TCP-daemons draaien, stuurt de frontpoort door naar daemonspecifieke poorten, en de zichtbare indeling komt niet meer overeen met de socketlijst. De tutorial over filteren van de webinterface beschrijft die regels en waarom een filter dat alleen voor de voor de hand liggende poort is geschreven, het doorgestuurde pad volledig kan missen.

Clusterbeheer is de tweede plek waar de versie ertoe doet. Vanaf 3.0 deelt het 943; oudere clusterconfiguraties gebruikten 945. Een van beide openen of blokkeren zonder de versie te controleren levert een nette ogende en onjuiste inventaris op.

De van buiten zichtbare oppervlakte is dus de vereniging van drie dingen: luisterende sockets, doorstuurregels die ze opnieuw publiceren en de netwerkcontroles voor de host. Elke inventaris die alleen het eerste vastlegt is onvolledig, en elke wijziging die alleen het eerste bekijkt laat een pad open of snijdt een dienst af.

Verifieer na elke wijziging

Wijzig listenerinstellingen via de ondersteunde configuratie-eigenaar en houd een herstelconsole open terwijl je dat doet. Het verliezen van administratieve toegang tot een webinterface op een externe host is niet te herstellen via de VPN die je zojuist hebt uitgeschakeld.

Valideer daarna de vier dingen die een implementatie meestal nodig heeft: een VPN-client maakt verbinding, het klantenportaal laadt, administratieve toegang werkt, en clustercommunicatie functioneert nog als je meer dan één node draait. Een test met alleen VPN slaagt ruim terwijl het portaal stuk is.

Sluit af door het toegestane pad voor elke dienst op te schrijven: welke socket, welke binding, welke doorstuurregel, welke netwerkcontrole. Dat document is de nuttige beveiligingsuitkomst. Een minimaal socketaantal is dat niet, en een massale reset die listeners sluit die niemand heeft afgemaakt met identificeren evenmin.