NAS-administration över en VPN: behåll namnet, släpp den publika porten
Nå administrationssidan genom tunneln, inte genom en ny publik port. Slå upp det riktiga namnet, matcha certifikatet mot det och tillåt en tjänst från en källa.
NAS-administrationssidan fungerar hemma och slutar fungera i samma stund som administratören reser, så någon öppnar en port och problemet försvinner tillsammans med integriteten. Det finns en bättre form för detta. Låt sidan vara där den är, låt tunneln leverera nåbarheten, och gör det du dokumenterar till en fullständig URL med en namngiven behörighetsväg i stället för en enhetsadress som råkar svara. Varje beslut nedan, från namnet till certifikatet till den enda tillåtna porten, följer av att skriva det så.
Designenheten är en URL, inte en adress
Skriv posten som en fullständig URL med dess port och schema och fäst sedan villkoren: vem som får använda den, från vilket nätverk och via vilken väg. Ett exempel kan vara https://nas.corp.example:8443 som bara publiceras till godkända privata klienter, där namnet och porten står för det enheten faktiskt lyssnar på.
Den ramen tvingar fram besluten tidigt. En URL förutsätter ett namn, ett namn förutsätter ett certifikat och ett certifikat förutsätter en förtroendeordning. En adress förutsätter inget av detta, och just därför överlever adressvarianten till den första webbläsarvarningen och blir därefter en vana att klicka sig igenom 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 |
Behåll namnet som certifikatet utfärdades för
Klienten behöver en tillåten väg till NAS:ens privata adress, och en privat DNS-ordning kan slå upp det avsedda värdnamnet till den adressen och samtidigt bevara namnet som HTTPS-tjänsten förväntar sig. Båda halvorna spelar roll: vägen får paketen dit, namnet berättar för klienten vilken identitet som ska verifieras.
Att skriva in den numeriska adressen i stället ändrar identitetskravet. RFC 9525 skiljer namnet en klient avser att kontakta från identiteten en tjänst presenterar, så ett certifikat utfärdat för nas.corp.example kan med rätta misslyckas när webbläsaren pekades mot 10.20.0.15. Varningen är korrekt, och rättelsen är namnet, inte ett undantag.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleKör båda innan du skyller på tunneln. Den första visar om det privata namnet slås upp där du tror, och den andra visar vilket certifikat och vilka alternativa subjektnamn tjänsten faktiskt presenterar. En privat CA kan vara ett helt välskött val; det som inte bör bli rutin är att lära människor avfärda identitetsvarningar.
Begränsa administrationsvägen
Tillåt exakt administrationstjänsten från den avsedda källan, både på gatewayen och på NAS:en. Den meningen döljer en detalj som biter: en routad klientpool och en gateway med källöversättning anländer till NAS:en med olika källadresser, så en tillåtelseregel skriven för den ena misslyckas tyst för den andra.
NAS:en behöver också en returväg, och webbläsaren måste använda den konfigurerade porten och schemat i stället för leverantörens standard från ett foruminlägg. Att nå enheten är inte tillstånd att nå varje port på den. Klyftan mellan en enhet som svarar på ping och en administrationssida som laddas är klyftan mellan två separata regler. Skriv dem som två regler med två kommentarer, så att nästa person ser varför båda finns.
Separera VPN-inträde från NAS-behörighet
Att släppas in genom tunneln är inte samma sak som att få administrera enheten. En användare som legitimt behöver fillagring bör inte ärva enhetsadministration bara för att båda bor bakom en gateway, och NAS:ens kontomodell är platsen där den separationen måste upprätthållas.
En delad eller översatt utgångsadress kan inte heller identifiera en enskild administratör. Om granskningsspåret måste namnge en person måste identiteten komma från ett autentiserat konto i stället för från källadressen till en tunnel som många människor använder.
Vad du inte bör publicera av misstag
En offentlig omvänd proxy och ett leverantörsrelä är båda riktiga arkitekturer, och var och en bär sina egna beslut om förtroende och exponering. Ingen av dem blir nödvändig för att en administratör är bortrest, och ingen av dem bör dyka upp som en bieffekt av att exponera en medieserver eller en fildelning.
Dokumentera fyra saker och sluta: det privata namnet, lyssnaren det mappas till, gruppen som har tillåtelse att använda det och återställningsvägen om tunneln inte är tillgänglig. De fyra svarar också på frågorna en incidentgranskning kommer att ställa, vilket inte gäller för en skärmbild av en portvidarebefordringssida. Det du slutar med är en stabil administrativ ingångspunkt i stället för en enhet där varje funktion är vänd mot internet.