Millä porteilla OpenVPN Access Server oikeastaan kuuntelee?
Käy läpi Access Server -isännän socket-luettelo: tunnista oletuskuuntelijat, erota loopback julkaistuista ja tarkista edelleenohjaus ennen portin sulkemista.
Suoritat ss -lntup Access Server -isännällä ja saat kaksinkertaisen listan odotettuun verrattuna. Puolet merkinnöistä on daemonin muotoisia portteja, joita kukaan ei maininnut asennuksen aikana. Refleksi on sulkea kaikki, mikä ei ole 443 tai 1194, ja niin ihmiset rikkovat oman asiakasportaalinsa.
Access Server ei ole yksi kuuntelija. Se on VPN-palvelu, verkkopalvelu ja klusterin osallistuja, ja se voi luoda ylimääräisiä daemonikohtaisia portteja ja palomuurin uudelleenohjauksia riippuen siitä, kuinka monta TCP-daemonia olet määrittänyt.
Käy luettelo läpi järjestyksessä: lue socketit, kartoita tutut, luokittele loput omistajan ja sidonnan mukaan ja tarkista sitten, mikä ne oikeastaan julkaisee.
Aloita yhdellä vain luku -komennolla
sudo ss -lntup antaa sinulle kuljetuksen, paikallisen osoitteen, portin ja omistajaprosessin jokaiselle kuuntelevalle socketille. Liput ovat tärkeitä: -l kuuntelu, -n numeerinen, -t TCP, -u UDP, -p prosessi. Ilman rootia saat socketit mutta et prosessien nimiä, ja juuri se sarake tarvitaan luokitteluun.
Kirjaa neljä kenttää riviä kohden ennen kuin muodostat mitään mielipidettä: protokolla, sidontaosoite, portti ja komento. Pidä Access Server -versio ja määritetty daemonien määrä luettelon vieressä, koska molemmat muuttavat sitä, mitä odotetaan.
Kaksi samalta näyttävää riviä eivät ole samoja. TCP ja UDP samalla numerolla ovat erilliset socketit erillisellä altistuksella, ja 0.0.0.0 ja :: ovat erilliset sidonnat erillisille osoiteperheille. Palvelu, joka on sidottu vain osoitteeseen 127.0.0.1 , ei ole suoraan tavoitettavissa toiselta isännältä, vaikka paikallinen uudelleenohjaus voi silti julkaista sen.
Kuuntelijat, jotka sinun pitäisi tunnistaa
Nämä oletukset kattavat useimmat asennukset ja antavat vertailupohjan. Ne ovat oletuksia, eivät täydellinen sallittujen luettelo.
| 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 |
Kaikki sitä pidemmälle vaatii selityksen, ei oletusta. Näet usein vain paikallisia kuuntelijoita, jotka kuuluvat komponenteille, jotka tuote asentaa itseään varten. Vahvista ne PID:n ja palvelukokoonpanon avulla muistetun portin numeron sijaan, äläkä pidä tuntematonta porttia vihamielisenä pelkän tuntemattomuuden vuoksi.
Tutun parin ulkopuolinen socket ei sekään ole automaattisesti jäänne. Kun useita TCP-daemoneja on määritetty, Access Server luo kuuntelijat daemonia kohden ja ohjaa liikennettä niille, joten niiden määrä ja porttiarvot seuraavat tätä kokoonpanoa.
Luokittele ennen kuin suljet mitään
Vastaa jokaisen epävarman rivin kohdalla kolmeen kysymykseen tässä järjestyksessä.
- Omistaja ja tarkoitus. Yhdistä PID yksikköön tai prosessiin ja lue kyseisen palvelun kokoonpano. Jos et voi nimetä omistajaa, et ole valmis päättämään socketista mitään.
- Sidonnan laajuus. Loopback on paikallinen nimiavaruudelle. Wildcard-sidonta on tavoitettavissa vain, jos reititys, isännän suodatus ja mahdolliset pilvitason säännöt sen sallivat, joten sidontaosoite on välttämätön mutta ei riittävä. Tarkista IPv4 ja IPv6 erillisinä päätöksinä.
- Julkaistu polku. Etsi palvelun edelleenohjausta, daemonikohtaisia uudelleenohjauksia, ulkoista välityspalvelinta ja tehokasta palomuurikäytäntöä. Tämä on se vaihe, jonka ihmiset ohittavat, ja juuri se muuttaa harmittomalta näyttävän backend-portin tavoitettavaksi hallintapoluksi.
Sama kysymys luetaan eri tavalla isännän ulkopuolelta. Portin, jolla ei ole isännän palomuurisääntöä, voi silti sulkea pilven tietoturvaryhmä, ja sallivan isäntäsäännön portti voi olla tavoittamaton, koska mikään ei reititä sinne. Katso molempia päitä ennen kuin kirjoitat luettelon johtopäätöksen.
Missä julkaistu polku eroaa socket-luettelosta
Access Serverin oma dokumentaatio kattaa tapauksen, joka aiheuttaa eniten sekaannusta: kun useita TCP-daemoneja ajetaan, etuportti välittää daemonikohtaisille porteille, ja näkyvä asettelu lakkaa vastaamasta socket-luetteloa. verkkokäyttöliittymän suodatusohje kuvaa nämä säännöt ja sen, miksi vain ilmeiselle portille kirjoitettu suodatin voi jättää uudelleenohjatun polun kokonaan huomaamatta.
Klusterin hallinta on toinen paikka, jossa versiolla on merkitystä. Versiossa 3.0 ja uudemmissa se jakaa 943:n; vanhemmat klusterikokoonpanot käyttivät 945:tä. Toisen avaaminen tai estäminen ilman version tarkistamista tuottaa siistiltä näyttävän ja väärän luettelon.
Ulkoisesti näkyvä pinta on siis kolmen asian liitto: kuuntelevat socketit, ne uudelleenjulkaisevat välityssäännöt ja isännän edessä olevat verkkokontrollit. Jokainen luettelo, joka tallentaa vain ensimmäisen, on puutteellinen, ja jokainen muutos, joka huomioi vain ensimmäisen, joko jättää polun auki tai katkaisee palvelun.
Vahvista jokaisen muutoksen jälkeen
Muuta kuuntelijan asetuksia tuetun kokoonpanon omistajan kautta ja pidä palautuskonsoli avoinna samalla. Hallintapääsyn menettäminen etäisännän verkkokäyttöliittymään ei ole palautettavissa juuri poistamasi VPN:n kautta.
Validoi sitten neljä asiaa, jotka asennus yleensä tarvitsee: VPN-asiakas yhdistää, asiakasportaali latautuu, hallintapääsy toimii ja klusteriviestintä toimii edelleen, jos ajat useampaa kuin yhtä solmua. Pelkkä VPN-testi menee mukavasti läpi, kun portaali on rikki.
Lopeta kirjoittamalla jokaisen palvelun sallittu polku: mikä socket, mikä sidonta, mikä välityssääntö, mikä verkkokontrolli. Tämä asiakirja on hyödyllinen tietoturvatulos. Minimaalinen socket-määrä ei ole, eikä myöskään joukkopalautus, joka sulkee kuuntelijoita, joita kukaan ei ehtinyt tunnistaa.