Hvilke porter lytter OpenVPN Access Server egentlig på?
Gå gjennom socket-listen på en Access Server-vert: gjenkjenn standardlytterne, skill loopback fra publiserte porter, og kontroller videresendingen før du lukker en port.
Du kjører ss -lntup på en Access Server-vert og får en liste som er dobbelt så lang som forventet. Halvparten av oppføringene er daemon-formede porter som ingen nevnte under oppsettet. Refleksen er å lukke alt som ikke er 443 eller 1194, og det er slik folk ødelegger sin egen klientportal.
Access Server er ikke én lytter. Det er en VPN-tjeneste, en webtjeneste og en klyppedeltaker, og den kan generere ekstra daemonspesifikke porter og brannmurvideresendinger avhengig av hvor mange TCP-daemoner du har konfigurert.
Gå gjennom oversikten i rekkefølge: les socketene, kartlegg de kjente, klassifiser resten etter eier og binding, og kontroller deretter hva som faktisk publiserer dem.
Begynn med én skrivebeskyttet kommando
sudo ss -lntup gir deg transport, lokal adresse, port og eierprosess for hver lyttende socket. Flaggene betyr noe: -l lyttende, -n numerisk, -t TCP, -u UDP, -p prosess. Uten root får du sockets, men ikke prosessnavn, og det er nøyaktig kolonnen du trenger for klassifisering.
Noter fire felt per rad før du danner deg noen mening: protokoll, bindingsadresse, port og kommando. Hold Access Server-versjonen og det konfigurerte antallet daemoner ved siden av listen, fordi begge endrer hva som forventes.
To rader som ser identiske ut er ikke det. TCP og UDP på samme nummer er separate sockets med separat eksponering, og 0.0.0.0 og :: er separate bindinger for separate adressefamilier. En tjeneste som bare er bundet til 127.0.0.1 er ikke direkte tilgjengelig fra en annen vert, selv om en lokal videresending fortsatt kan publisere den.
Lytterne du bør kjenne igjen
Disse standardverdiene dekker de fleste installasjoner og gir deg en baseline å sammenligne med. De er standardverdier, ikke en fullstendig tillatelsesliste.
| 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 |
Alt utover det krever en forklaring, ikke en antakelse. Du vil ofte se lokale lyttere som tilhører komponenter som produktet installerer for seg selv. Bekreft dem via PID og tjenestekonfigurasjon i stedet for et husket portnummer, og ikke behandle en ukjent port som fiendtlig bare fordi den er ukjent.
En socket utenfor det kjente paret er heller ikke automatisk en rest. Når flere TCP-daemoner er konfigurert, oppretter Access Server lyttere per daemon og omdirigerer trafikk til dem, slik at antallet og portverdiene følger den konfigurasjonen.
Klassifiser før du lukker noe
For hver usikre rad, svar på tre spørsmål i denne rekkefølgen.
- Eier og formål. Match PID-en til en enhet eller prosess og les konfigurasjonen til den tjenesten. Hvis du ikke kan navngi eieren, er du ikke klar til å avgjøre noe om socketen.
- Bindingsomfang. Loopback er lokalt for navnerommet. En wildcard-binding er bare tilgjengelig hvis ruting, vertsfiltrering og eventuelle regler på skynivå tillater det, så bindingsadressen er nødvendig, men ikke tilstrekkelig. Kontroller IPv4 og IPv6 som separate beslutninger.
- Publisert sti. Se etter tjenestevideresending, daemonspesifikke omdirigeringer, en ekstern proxy og den effektive brannmurpolitikken. Dette er trinnet folk hopper over, og det er det som gjør en uskyldig utseende backend-port til en tilgjengelig administrativ sti.
Det samme spørsmålet leses annerledes utenfra verten. En port uten vertsbrannmurregel kan fortsatt lukkes av en skysikkerhetsgruppe, og en port med en ettergivende vertsregel kan være utilgjengelig fordi ingenting ruter til den. Se på begge ender før du skriver konklusjonen i oversikten.
Der den publiserte stien avviker fra socket-listen
Access Servers egen dokumentasjon dekker tilfellet som skaper mest forvirring: når flere TCP-daemoner kjører, videresender frontporten til daemonspesifikke porter, og det synlige oppsettet slutter å samsvare med socket-listen. veiledningen om filtrering av webgrensesnittet beskriver disse reglene og hvorfor et filter som bare er skrevet for den åpenbare porten, kan overse den omdirigerte stien helt.
Klyngekontroll er det andre stedet der versjonen betyr noe. Fra 3.0 deler den 943; eldre klyngekonfigurasjoner brukte 945. Å åpne eller blokkere en av dem uten å kontrollere versjonen gir en oversikt som ser ryddig ut og er feil.
Så den utenfra synlige flaten er foreningen av tre ting: lyttende sockets, videresendingsregler som republiserer dem, og nettverkskontrollene foran verten. Enhver oversikt som bare registrerer det første, er ufullstendig, og enhver endring som bare vurderer det første, vil enten la en sti stå åpen eller kutte av en tjeneste.
Verifiser etter enhver endring
Endre lytterinnstillinger gjennom den støttede konfigurasjonseieren og hold en gjenopprettingskonsoll åpen mens du gjør det. Tap av administrativ tilgang til et webgrensesnitt på en ekstern vert kan ikke gjenopprettes via VPN-en du nettopp deaktiverte.
Valider deretter de fire tingene en installasjon vanligvis trenger: en VPN-klient kobler til, klientportalen lastes, administrativ tilgang fungerer, og klyngekommunikasjon fungerer fortsatt hvis du kjører mer enn én node. En test kun med VPN består komfortabelt mens portalen er ødelagt.
Avslutt med å skrive ned den tillatte stien for hver tjeneste: hvilken socket, hvilken binding, hvilken videresendingsregel, hvilken nettverkskontroll. Det dokumentet er det nyttige sikkerhetsresultatet. Et minimalt socketantall er det ikke, og heller ikke en massetilbakestilling som lukker lyttere som ingen har rukket å identifisere.