NAS-administration over en VPN: behold navnet, drop den offentlige port
Nå administrationssiden gennem tunnelen, ikke gennem en ny offentlig port. Slå det rigtige navn op, match certifikatet til det, og tillad én tjeneste fra én kilde.
NAS-administrationssiden virker derhjemme og holder op med at virke i det øjeblik, administratoren rejser, så nogen åbner en port, og problemet forsvinder sammen med privatlivet. Der er en bedre form for dette. Lad siden blive, hvor den er, lad tunnelen levere tilgængeligheden, og gør det, du dokumenterer, til en fuld URL med en navngivet tilladelsessti i stedet for en enhedsadresse, der tilfældigvis svarer. Hver beslutning nedenfor, fra navnet til certifikatet til den eneste tilladte port, følger af at skrive det sådan.
Designenheden er en URL, ikke en adresse
Skriv posten som en fuld URL med dens port og skema, og knyt derefter betingelserne til: hvem der må bruge den, fra hvilket netværk og ad hvilken vej. Et eksempel kan være https://nas.corp.example:8443, der kun udgives til godkendte private klienter, hvor navnet og porten står for det, enheden faktisk lytter på.
Den ramme tvinger beslutningerne tidligt. En URL forudsætter et navn, et navn forudsætter et certifikat, og et certifikat forudsætter en tillidsordning. En adresse forudsætter intet af det, og netop derfor overlever adresse-only-versionen indtil den første browseradvarsel og bliver derefter en vane med at klikke igennem 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 det navn, certifikatet blev udstedt til
Klienten har brug for en tilladt rute til NAS'ens private adresse, og en privat DNS-ordning kan slå det tilsigtede værtsnavn op til den adresse og samtidig bevare det navn, HTTPS-tjenesten forventer. Begge halvdele betyder noget: ruten får pakkerne derhen, navnet fortæller klienten, hvilken identitet der skal verificeres.
At taste den numeriske adresse i stedet ændrer identitetskravet. RFC 9525 adskiller det navn, en klient agter at kontakte, fra den identitet, en tjeneste præsenterer, så et certifikat udstedt til nas.corp.example kan med rette fejle, når browseren blev peget på 10.20.0.15. Advarslen er korrekt, og løsningen er navnet, ikke en undtagelse.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleKør begge, før du bebrejder tunnelen. Den første viser, om det private navn slår op, hvor du tror, og den anden viser, hvilket certifikat og hvilke alternative subjektnavne tjenesten faktisk præsenterer. En privat CA kan være et helt velstyret valg; det, der ikke bør blive rutine, er at lære folk at afvise identitetsadvarsler.
Afgræns administrationsstien
Tillad præcis administrationstjenesten fra den tilsigtede kilde, både på gatewayen og på NAS'en. Den sætning skjuler en detalje, der bider: en routed klientpulje og en gateway med kildetranslation ankommer til NAS'en med forskellige kildeadresser, så en tilladelsesregel skrevet til den ene fejler lydløst for den anden.
NAS'en har også brug for en returvej, og browseren skal bruge den konfigurerede port og skema i stedet for leverandørens standard fra et forumindlæg. At nå enheden er ikke tilladelse til at nå hver port på den. Kløften mellem en enhed, der svarer på ping, og en administrationsside, der indlæses, er kløften mellem to separate regler. Skriv dem som to regler med to kommentarer, så den næste person kan se, hvorfor begge findes.
Adskil VPN-adgang fra NAS-privilegium
At blive lukket ind gennem tunnelen er ikke det samme som at måtte administrere enheden. En bruger, der legitimt har brug for fillagring, bør ikke arve enhedsadministration, fordi begge bor bag én gateway, og NAS'ens kontomodel er stedet, hvor den adskillelse skal håndhæves.
En delt eller oversat udgangsadresse kan heller ikke identificere en individuel administrator. Hvis revisionssporet skal navngive en person, skal identiteten komme fra en autentificeret konto i stedet for fra kildeadressen på en tunnel, som mange mennesker bruger.
Hvad du ikke bør offentliggøre ved et uheld
En offentlig reverse proxy og et leverandørrelay er begge rigtige arkitekturer, og hver især bærer deres egne tillids- og eksponeringsbeslutninger. Ingen af dem bliver nødvendige, fordi en administrator er væk hjemmefra, og ingen af dem bør dukke op som en bivirkning af at eksponere en medieserver eller en fildeling.
Dokumentér fire ting og stop: det private navn, den listener det mapper til, den gruppe der har tilladelse til at bruge det, og gendannelsesstien, hvis tunnelen er utilgængelig. De fire besvarer også de spørgsmål, en hændelsesgennemgang vil stille, hvilket ikke gælder for et skærmbillede af en portforwarding-side. Det, du ender med, er ét stabilt administrativt indgangspunkt i stedet for en enhed, hvis hver funktion vender mod internettet.