Vilka portar lyssnar OpenVPN Access Server egentligen på?
Gå igenom socketlistan på en Access Server-värd: känn igen standardlyssnarna, skilj loopback från publicerade portar och kontrollera vidarebefordran innan du stänger en port.
Du kör ss -lntup på en Access Server-värd och får en lista som är dubbelt så lång som väntat. Hälften av posterna är daemonformade portar som ingen nämnde under installationen. Reflexen är att stänga allt som inte är 443 eller 1194, och det är så folk förstör sin egen klientportal.
Access Server är inte en enda lyssnare. Det är en VPN-tjänst, en webbtjänst och en klusterdeltagare, och det kan generera extra daemonspecifika portar och brandväggsvidarebefordringar beroende på hur många TCP-daemoner du har konfigurerat.
Gå igenom inventeringen i ordning: läs socketarna, kartlägg de kända, klassificera resten efter ägare och bindning, och kontrollera sedan vad som faktiskt publicerar dem.
Börja med ett enda skrivskyddat kommando
sudo ss -lntup ger dig transport, lokal adress, port och ägarprocess för varje lyssnande socket. Flaggorna spelar roll: -l lyssnar, -n numeriskt, -t TCP, -u UDP, -p process. Utan root får du socketar men inte processnamn, och det är exakt den kolumnen du behöver för klassificering.
Anteckna fyra fält per rad innan du bildar dig en uppfattning: protokoll, bindningsadress, port och kommando. Håll Access Server-versionen och det konfigurerade antalet daemoner bredvid listan, eftersom båda ändrar vad som förväntas.
Två rader som ser identiska ut är inte det. TCP och UDP på samma nummer är separata socketar med separat exponering, och 0.0.0.0 och :: är separata bindningar för separata adressfamiljer. En tjänst som bara är bunden till 127.0.0.1 är inte direkt nåbar från en annan värd, även om en lokal vidarebefordran fortfarande kan publicera den.
Lyssnarna du bör känna igen
Dessa standardvärden täcker de flesta installationer och ger dig en baslinje att jämföra med. De är standardvärden, inte en fullständig tillåtelselista.
| 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 |
Allt utöver det kräver en förklaring, inte ett antagande. Du kommer ofta att se lokala lyssnare som tillhör komponenter som produkten installerar för sig själv. Bekräfta dem via PID och tjänstekonfiguration i stället för ett ihågkommet portnummer, och behandla inte en okänd port som fientlig bara för att den är okänd.
En socket utanför det kända paret är inte heller automatiskt en rest. När flera TCP-daemoner är konfigurerade skapar Access Server lyssnare per daemon och omdirigerar trafik till dem, så deras antal och portvärden följer den konfigurationen.
Klassificera innan du stänger något
För varje osäker rad, svara på tre frågor i denna ordning.
- Ägare och syfte. Matcha PID:n mot en enhet eller process och läs den tjänstens konfiguration. Om du inte kan namnge ägaren är du inte redo att avgöra något om socketen.
- Bindningsomfång. Loopback är lokalt för namnområdet. En wildcard-bindning är bara nåbar om routing, värdtrafikfiltrering och eventuella regler på molnnivå tillåter det, så bindningsadressen är nödvändig men inte tillräcklig. Kontrollera IPv4 och IPv6 som separata beslut.
- Publicerad väg. Leta efter tjänsteforwarding, daemonspecifika omdirigeringar, en extern proxy och den effektiva brandväggspolicyn. Det här är steget folk hoppar över, och det är det som förvandlar en oskyldigt utseende backend-port till en nåbar administrativ väg.
Samma fråga läses annorlunda utanför värden. En port utan värdbrandväggsregel kan fortfarande stängas av en molnsäkerhetsgrupp, och en port med en tillåtande värdregel kan vara onåbar eftersom ingenting routar dit. Titta på båda ändarna innan du skriver inventeringens slutsats.
Där den publicerade vägen skiljer sig från socketlistan
Access Servers egen dokumentation täcker fallet som skapar mest förvirring: när flera TCP-daemoner körs vidarebefordrar frontporten till daemonspecifika portar, och den synliga layouten slutar matcha socketlistan. handledningen om filtrering av webbgränssnittet beskriver dessa regler och varför ett filter som bara skrivits för den uppenbara porten kan missa den omdirigerade vägen helt.
Klusterkontroll är den andra platsen där versionen spelar roll. Från 3.0 delar den 943; äldre klusterkonfigurationer använde 945. Att öppna eller blockera en av dem utan att kontrollera versionen ger en inventering som ser prydlig ut och är fel.
Så den utifrån synliga ytan är föreningen av tre saker: lyssnande socketar, vidarebefordringsregler som publicerar dem igen och nätverkskontrollerna framför värden. Varje inventering som bara registrerar det första är ofullständig, och varje ändring som bara beaktar det första lämnar antingen en väg öppen eller skär av en tjänst.
Verifiera efter varje ändring
Ändra lyssnarinställningarna via den stödda konfigurationsägaren och håll en återställningskonsol öppen medan du gör det. Att förlora administrativ åtkomst till ett webbgränssnitt på en fjärrvärd går inte att återställa via den VPN du just inaktiverade.
Validera sedan de fyra saker en installation vanligtvis behöver: en VPN-klient ansluter, klientportalen laddas, administrativ åtkomst fungerar, och klusterkommunikation fungerar fortfarande om du kör mer än en nod. Ett test med bara VPN går bekvämt igenom medan portalen är trasig.
Avsluta med att skriva ner den tillåtna vägen för varje tjänst: vilken socket, vilken bindning, vilken vidarebefordringsregel, vilken nätverkskontroll. Det dokumentet är det nyttiga säkerhetsresultatet. Ett minimalt socketantal är det inte, och inte heller en massåterställning som stänger lyssnare som ingen hunnit identifiera.