Hvilke porte lytter OpenVPN Access Server egentlig på?

Du kører ss -lntup på en Access Server-vært og får en liste, der er dobbelt så lang som forventet. Halvdelen af posterne er daemon-formede porte, som ingen nævnte under opsætningen. Refleksen er at lukke alt, der ikke er 443 eller 1194, og det er sådan, folk ødelægger deres egen klientportal.

Access Server er ikke én lytter. Det er en VPN-tjeneste, en webtjeneste og en klyppedeltager, og den kan generere ekstra daemonspecifikke porte og firewall-omdirigeringer afhængigt af, hvor mange TCP-daemoner du har konfigureret.

Gå gennem oversigten i rækkefølge: læs soketterne, kortlæg de velkendte, klassificér resten efter ejer og binding, og kontroller derefter, hvad der faktisk publicerer dem.

Begynd med én skrivebeskyttet kommando

sudo ss -lntup giver dig transport, lokal adresse, port og ejerprocess for hvert lyttende soket. Flagene betyder noget: -l lyttende, -n numerisk, -t TCP, -u UDP, -p proces. Uden root får du soketter, men ikke procesnavne, og det er præcis den kolonne, du har brug for til klassificering.

Registrér fire felter pr. række, før du danner dig nogen mening: protokol, bindingsadresse, port og kommando. Hold Access Server-versionen og det konfigurerede antal daemoner ved siden af listen, fordi begge ændrer, hvad der forventes.

To rækker, der ser identiske ud, er ikke ens. TCP og UDP på samme nummer er separate soketter med separat eksponering, og 0.0.0.0 og :: er separate bindinger til separate adressefamilier. En tjeneste, der kun er bundet til 127.0.0.1 , er ikke direkte tilgængelig fra en anden vært, selvom en lokal omdirigering stadig kan publicere den.

De lyttere, du bør genkende

Disse standarder dækker de fleste installationer og giver dig en baseline at sammenligne med. De er standarder, ikke en komplet tilladelsesliste.

Alt derudover kræver en forklaring, ikke en antagelse. Du vil ofte se lokale lyttere, der tilhører komponenter, som produktet installerer for sig selv. Bekræft dem via PID og tjenestekonfiguration i stedet for et husket portnummer, og behandl ikke en ukendt port som fjendtlig alene på grund af ukendskab.

Et soket uden for det velkendte par er heller ikke automatisk en rest. Når flere TCP-daemoner er konfigureret, opretter Access Server lyttere pr. daemon og omdirigerer trafik til dem, så deres antal og portværdier følger den konfiguration.

Klassificér, før du lukker noget

For hver usikker række skal du svare på tre spørgsmål i denne rækkefølge.

1. Ejer og formål. Match PID'en til en unit eller proces, og læs den tjenestes konfiguration. Hvis du ikke kan navngive ejeren, er du ikke klar til at beslutte noget om sokettet.
2. Bindingsomfang. Loopback er lokalt for navnerummet. En wildcard-binding er kun tilgængelig, hvis routing, værtsfiltrering og eventuelle regler på cloudniveau tillader det, så bindingsadressen er nødvendig, men ikke tilstrækkelig. Kontroller IPv4 og IPv6 som separate beslutninger.
3. Publiceret sti. Se efter tjenestevideresendelse, daemonspecifikke omdirigeringer, en ekstern proxy og den effektive firewallpolitik. Dette er det trin, folk springer over, og det er det, der gør en uskyldigt udseende backend-port til en tilgængelig administrativ sti.

Det samme spørgsmål læses anderledes udefra værten. En port uden værtsfirewallregel kan stadig lukkes af en cloud-sikkerhedsgruppe, og en port med en eftergivende værtsregel kan være utilgængelig, fordi intet ruter til den. Se på begge ender, før du skriver konklusionen i oversigten.

Hvor den publicerede sti adskiller sig fra soketlisten

Access Servers egen dokumentation dækker det tilfælde, der skaber mest forvirring: når flere TCP-daemoner kører, videresender frontporten til daemonspecifikke porte, og det synlige layout holder op med at matche soketlisten. tutorial om filtrering af webgrænsefladen beskriver disse regler, og hvorfor et filter, der kun er skrevet til den oplagte port, kan overse den omdirigerede sti helt.

Klyngekontrol er det andet sted, hvor versionen betyder noget. På 3.0 og nyere deler den 943; ældre klyngekonfigurationer brugte 945. Åbning eller blokering af en af dem uden at kontrollere versionen giver en oversigt, der ser pæn ud og er forkert.

Så den udefra synlige overflade er foreningen af tre ting: lyttende soketter, videresendelsesregler, der genpublicerer dem, og netværkskontrollen foran værten. Enhver oversigt, der kun registrerer det første, er ufuldstændig, og enhver ændring, der kun overvejer det første, vil enten efterlade en sti åben eller afskære en tjeneste.

Bekræft efter enhver ændring

Ændr lytterindstillinger gennem den understøttede konfigurationsejer, og hold en gendannelseskonsol åben, mens du gør det. Tab af administrativ adgang til en webgrænseflade på en fjern vært kan ikke gendannes via den VPN, du netop har deaktiveret.

Validér derefter de fire ting, en installation normalt har brug for: en VPN-klient opretter forbindelse, klientportalen indlæses, administrativ adgang virker, og klyngekommunikation fungerer stadig, hvis du kører mere end én node. En test kun med VPN består komfortabelt, mens portalen er i stykker.

Afslut med at skrive den tilladte sti ned for hver tjeneste: hvilket soket, hvilken binding, hvilken videresendelsesregel, hvilken netværkskontrol. Det dokument er det nyttige sikkerhedsresultat. Et minimalt soketantal er det ikke, og en masse-reset, der lukker lyttere, som ingen har nået at identificere, er det heller ikke.