NAS-beheer via een VPN: houd de naam, laat de openbare poort los
Bereik de beheerpagina via de tunnel, niet via een nieuwe openbare poort. Los de echte naam op, laat het certificaat daarbij passen en sta één dienst vanaf één bron toe.
De beheerpagina van de NAS werkt thuis en stopt op het moment dat de beheerder reist, dus iemand opent een poort en het probleem verdwijnt samen met de privacy. Hiervoor bestaat een betere vorm. Laat de pagina waar hij is, laat de tunnel de bereikbaarheid leveren, en maak van wat je documenteert een volledige URL met een benoemd toestemmingspad in plaats van een apparaatadres dat toevallig antwoordt. Elke beslissing hieronder, van de naam tot het certificaat tot de enige toegestane poort, volgt uit het zo opschrijven.
De ontwerpeenheid is een URL, niet een adres
Schrijf de ingang als een volledige URL met zijn poort en schema en hang er dan de voorwaarden aan: wie hem mag gebruiken, vanaf welk netwerk en via welk pad. Een voorbeeld kan https://nas.corp.example:8443 zijn dat alleen naar goedgekeurde privéclients wordt gepubliceerd, waarbij de naam en poort staan voor wat het apparaat werkelijk beluistert.
Dat kader dwingt de beslissingen vroeg af. Een URL impliceert een naam, een naam impliceert een certificaat en een certificaat impliceert een vertrouwensregeling. Een adres impliceert niets daarvan, en juist daarom overleeft de versie met alleen een adres tot de eerste browserwaarschuwing en wordt het daarna een gewoonte om erdoorheen te klikken.
| 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 |
Houd de naam waarvoor het certificaat is uitgegeven
De client heeft een toegestane route naar het privéadres van de NAS nodig, en een privé-DNS-regeling kan de bedoelde hostnaam naar dat adres oplossen en tegelijk de naam bewaren die de HTTPS-dienst verwacht. Beide helften tellen: de route brengt de pakketten erheen, de naam vertelt de client welke identiteit te verifiëren.
Het numerieke adres intypen verandert in plaats daarvan de identiteitseis. RFC 9525 scheidt de naam die een client wil benaderen van de identiteit die een dienst presenteert, dus een certificaat dat voor nas.corp.example is uitgegeven kan terecht falen wanneer de browser op 10.20.0.15 is gericht. De waarschuwing is correct, en de oplossing is de naam, geen uitzondering.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleVoer beide uit voordat je de tunnel de schuld geeft. De eerste laat zien of de privénaam oplost waar je denkt, en de tweede laat zien welk certificaat en welke alternatieve onderwerpnamen de dienst werkelijk presenteert. Een privé-CA kan een volledig goed beheerde keuze zijn; wat geen routine moet worden, is mensen leren identiteitswaarschuwingen weg te klikken.
Begrens het beheerpad
Sta precies de beheerdienst vanaf de bedoelde bron toe, zowel op de gateway als op de NAS. Die zin verbergt een detail dat bijt: een gerouteerde clientpool en een gateway met bronvertaling komen bij de NAS aan met verschillende bronadressen, dus een toestemmingsregel die voor de ene is geschreven, faalt stil voor de andere.
De NAS heeft ook een terugweg nodig, en de browser moet de geconfigureerde poort en het schema gebruiken in plaats van de standaardwaarde van de leverancier uit een forumbericht. Het apparaat bereiken is geen toestemming om elke poort erop te bereiken. De kloof tussen een apparaat dat op ping antwoordt en een beheerpagina die laadt, is de kloof tussen twee afzonderlijke regels. Schrijf ze als twee regels met twee opmerkingen, zodat de volgende persoon ziet waarom beide bestaan.
Scheid VPN-toelating van NAS-bevoegdheid
Door de tunnel worden toegelaten is niet hetzelfde als het apparaat mogen beheren. Een gebruiker die legitiem bestandsopslag nodig heeft, zou geen apparaatbeheer moeten erven omdat beide achter één gateway leven, en het accountmodel van de NAS is de plek waar die scheiding moet worden afgedwongen.
Een gedeeld of vertaald uitgangsadres kan ook geen individuele beheerder identificeren. Als het auditspoor een persoon moet noemen, moet de identiteit uit een geauthenticeerd account komen en niet uit het bronadres van een tunnel die veel mensen gebruiken.
Wat je niet per ongeluk moet publiceren
Een openbare reverse proxy en een leveranciersrelay zijn beide echte architecturen, en elk draagt zijn eigen vertrouwens- en blootstellingsbeslissingen. Geen van beide wordt nodig omdat een beheerder van huis is, en geen van beide zou moeten verschijnen als bijwerking van het blootstellen van een mediaserver of een bestandsshare.
Documenteer vier dingen en stop: de privénaam, de listener waarop die wordt gemapt, de groep die hem mag gebruiken en het herstelpad als de tunnel niet beschikbaar is. Die vier beantwoorden ook de vragen die een incidentreview zal stellen, wat niet geldt voor een schermafbeelding van een poortdoorschakelingspagina. Wat je uiteindelijk hebt, is één stabiel administratief toegangspunt in plaats van een apparaat waarvan elke functie naar het internet kijkt.