Kva portar lyttar OpenVPN Access Server eigentleg på?
Gå gjennom socket-lista på ein Access Server-vert: kjenna att standardlyttarane, skil loopback frå publiserte portar, og kontroller videresendinga før du lukkar ein port.
Du køyrer ss -lntup på ein Access Server-vert og får ei liste som er dobbelt så lang som venta. Halvparten av oppføringane er daemon-forma portar som ingen nemnde under oppsettet. Refleksen er å lukke alt som ikkje er 443 eller 1194, og det er slik folk øydelegg sin eigen klientportal.
Access Server er ikkje éin lyttar. Det er ein VPN-teneste, ein webbeneste og ein klyppedeltakar, og det kan generere ekstra daemonspesifikke portar og brannmurvideresendingar avhengig av kor mange TCP-daemonar du har konfigurert.
Gå gjennom oversynet i rekkjefølgje: les socketane, kartlegg dei kjende, klassifiser resten etter eigar og binding, og kontroller deretter kva som faktisk publiserer dei.
Byrj med éin skriveverna kommando
sudo ss -lntup gir deg transport, lokal adresse, port og eigarprosess for kvar lyttande socket. Flagga betyr noko: -l lyttande, -n numerisk, -t TCP, -u UDP, -p prosess. Utan root får du socketar, men ikkje prosessnamn, og det er nøyaktig kolonnen du treng for klassifisering.
Noter fire felt per rad før du dannar deg noka meining: protokoll, bindingsadresse, port og kommando. Hald Access Server-versjonen og det konfigurerte talet på daemonar ved sida av lista, fordi begge endrar kva som er venta.
To rader som ser identiske ut er ikkje det. TCP og UDP på same nummer er separate socketar med separat eksponering, og 0.0.0.0 og :: er separate bindingar for separate adressefamiliar. Ei teneste som berre er bunde til 127.0.0.1 er ikkje direkte tilgjengeleg frå ein annan vert, sjølv om ei lokal videresending framleis kan publisere ho.
Lyttarane du bør kjenne att
Desse standardverdiane dekkjer dei fleste installasjonar og gir deg ein basis å samanlikne med. Dei er standardverdiar, ikkje ei fullstendig tillatingsliste.
| 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 krev ei forklaring, ikkje ei anteke. Du vil ofte sjå lokale lyttarar som høyrer til komponentar som produktet installer for seg sjølv. Stadfest dei via PID og tenestekonfigurasjon i staden for eit hugsa portnummer, og handsam ikkje ein ukjend port som fiendtleg berre fordi han er ukjend.
Ein socket utanfor det kjende paret er heller ikkje automatisk ein rest. Når fleire TCP-daemonar er konfigurerte, opprettar Access Server lyttarar per daemon og omdirigerer trafikk til dei, slik at talet og portverdiane følgjer den konfigurasjonen.
Klassifiser før du lukkar noko
For kvar usikker rad, svar på tre spørsmål i denne rekkjefølgja.
- Eigar og føremål. Match PID-en til ein eining eller prosess og les konfigurasjonen til den tenesta. Viss du ikkje kan namngje eigaren, er du ikkje klar til å avgjere noko om socketen.
- Bindingsomfang. Loopback er lokalt for namnerommet. Ei wildcard-binding er berre tilgjengeleg viss ruting, vertsfiltrering og eventuelle reglar på skynivå tillèt det, så bindingsadressa er nødvendig, men ikkje tilstrekkeleg. Kontroller IPv4 og IPv6 som separate avgjerder.
- Publisert sti. Sjå etter tenestevideresending, daemonspesifikke omdirigeringar, ein ekstern proxy og den effektive brannmurpolitikken. Dette er trinnet folk hoppar over, og det er det som gjer ein uskuldig utsjåande backend-port til ein tilgjengeleg administrativ sti.
Det same spørsmålet blir lese annleis utanfrå verten. Ein port utan vertsbrannmurregel kan framleis lukkast av ei skysikkerheitsgruppe, og ein port med ein ettergjevande vertsregel kan vere utilgjengeleg fordi ingenting ruter til han. Sjå på begge endane før du skriv konklusjonen i oversynet.
Der den publiserte stien avvik frå socket-lista
Access Server si eiga dokumentasjon dekkjer tilfellet som skaper mest forvirring: når fleire TCP-daemonar køyrer, videresender frontporten til daemonspesifikke portar, og det synlege oppsettet sluttar å samsvare med socket-lista. rettleiinga om filtrering av webgrensesnittet skildrar desse reglane og kvifor eit filter som berre er skrive for den openberre porten, kan oversjå den omdirigerte stien heilt.
Klyngestyring er det andre staden der versjonen betyr noko. Frå 3.0 deler ho 943; eldre klyngekonfigurasjonar brukte 945. Å opne eller blokkere ein av dei utan å kontrollere versjonen gir eit oversyn som ser ryddig ut og er feil.
Så den utanfrå synlege flata er sameininga av tre ting: lyttande socketar, videresendingsreglar som republiserer dei, og nettverkskontrollane framfor verten. Kvart oversyn som berre registrerer det første, er ufullstendig, og kvar endring som berre vurderer det første, vil anten la ein sti stå open eller kutte av ei teneste.
Verifiser etter kvar endring
Endre lyttarinnstillingar gjennom den støtta konfigurasjonseigaren og hald ein gjenopprettingskonsoll open medan du gjer det. Tap av administrativ tilgang til eit webgrensesnitt på ein ekstern vert kan ikkje gjenopprettast via VPN-en du nettopp deaktiverte.
Valider deretter dei fire tinga ein installasjon vanlegvis treng: ein VPN-klient koplar til, klientportalen lastar, administrativ tilgang fungerer, og klyngekommunikasjon fungerer framleis viss du køyrer meir enn éin node. Ein test berre med VPN går komfortabelt gjennom medan portalen er øydelagd.
Avslutt med å skrive ned den tillatne stien for kvar teneste: kva socket, kva binding, kva videresendingsregel, kva nettverkskontroll. Det dokumentet er det nyttige tryggleiksresultatet. Eit minimalt socket-tal er det ikkje, og heller ikkje ein massetilbakestilling som lukkar lyttarar som ingen har rukke å identifisere.