NAS-administrasjon over en VPN: behold navnet, slipp den offentlige porten
Nå administrasjonssiden gjennom tunnelen, ikke gjennom en ny offentlig port. Slå opp det ekte navnet, tilpass sertifikatet til det, og tillat én tjeneste fra én kilde.
NAS-administrasjonssiden fungerer hjemme og slutter å fungere i det øyeblikket administratoren reiser, så noen åpner en port, og problemet forsvinner sammen med personvernet. Det finnes en bedre form for dette. La siden bli der den er, la tunnelen levere tilgjengeligheten, og gjør det du dokumenterer til en fullstendig URL med en navngitt tillatelsessti i stedet for en enhetsadresse som tilfeldigvis svarer. Hver beslutning nedenfor, fra navnet til sertifikatet til den eneste tillatte porten, følger av å skrive det slik.
Designenheten er en URL, ikke en adresse
Skriv oppføringen som en fullstendig URL med porten og skjemaet, og fest deretter betingelsene: hvem som kan bruke den, fra hvilket nettverk og via hvilken sti. Et eksempel kan være https://nas.corp.example:8443 som bare publiseres til godkjente private klienter, der navnet og porten står for det enheten faktisk lytter på.
Den rammen tvinger beslutningene tidlig. En URL forutsetter et navn, et navn forutsetter et sertifikat, og et sertifikat forutsetter en tillitsordning. En adresse forutsetter ingenting av dette, og nettopp derfor overlever adresse-bare-versjonen til den første nettleseradvarselen og blir deretter en vane med å klikke seg gjennom den.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
Behold navnet sertifikatet ble utstedt til
Klienten trenger en tillatt rute til NAS-ens private adresse, og en privat DNS-ordning kan slå opp det tiltenkte vertsnavnet til den adressen og samtidig bevare navnet HTTPS-tjenesten forventer. Begge halvdelene betyr noe: ruten får pakkene dit, navnet forteller klienten hvilken identitet som skal verifiseres.
Å taste den numeriske adressen i stedet endrer identitetskravet. RFC 9525 skiller navnet en klient har til hensikt å kontakte fra identiteten en tjeneste presenterer, så et sertifikat utstedt til nas.corp.example kan med rette feile når nettleseren ble pekt på 10.20.0.15. Advarselen er riktig, og rettelsen er navnet, ikke et unntak.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleKjør begge før du klandrer tunnelen. Den første viser om det private navnet slås opp der du tror, og den andre viser hvilket sertifikat og hvilke alternative subjektnavn tjenesten faktisk presenterer. En privat CA kan være et helt velstyrt valg; det som ikke bør bli rutine, er å lære folk å avvise identitetsadvarsler.
Begrens administrasjonsstien
Tillat nøyaktig administrasjonstjenesten fra den tiltenkte kilden, både på gatewayen og på NAS-en. Den setningen skjuler en detalj som biter: en rutet klientpool og en gateway med kildeoversettelse ankommer NAS-en med forskjellige kildeadresser, så en tillatelsesregel skrevet for den ene feiler stille for den andre.
NAS-en trenger også en returvei, og nettleseren må bruke den konfigurerte porten og skjemaet i stedet for leverandørens standard fra et foruminnlegg. Å nå enheten er ikke tillatelse til å nå hver port på den. Gapet mellom en enhet som svarer på ping og en administrasjonsside som lastes, er gapet mellom to separate regler. Skriv dem som to regler med to kommentarer, slik at neste person ser hvorfor begge finnes.
Skill VPN-innslipp fra NAS-privilegium
Å bli sluppet inn gjennom tunnelen er ikke det samme som å få administrere enheten. En bruker som legitimt trenger fillagring, bør ikke arve enhetsadministrasjon fordi begge bor bak én gateway, og NAS-ens kontomodell er stedet der den skillet må håndheves.
En delt eller oversatt utgangsadresse kan heller ikke identifisere en individuell administrator. Hvis revisjonssporet skal navngi en person, må identiteten komme fra en autentisert konto i stedet for fra kildeadressen til en tunnel som mange mennesker bruker.
Hva du ikke bør publisere ved et uhell
En offentlig omvendt proxy og et leverandørrelé er begge ekte arkitekturer, og hver av dem bærer sine egne tillits- og eksponeringsbeslutninger. Ingen av dem blir nødvendige fordi en administrator er borte hjemmefra, og ingen av dem bør dukke opp som en bivirkning av å eksponere en medieserver eller en fildeling.
Dokumenter fire ting og stopp: det private navnet, lytteren det tilordnes, gruppen som har tillatelse til å bruke det, og gjenopprettingsstien hvis tunnelen er utilgjengelig. De fire svarer også på spørsmålene en hendelsesgjennomgang vil stille, noe som ikke gjelder for et skjermbilde av en portvideresendingsside. Det du ender med, er ett stabilt administrativt inngangspunkt i stedet for en enhet der hver funksjon vender mot internett.