NAS-administrasjon over ein VPN: hald på namnet, slepp den offentlege porten
Nå administrasjonssida gjennom tunnelen, ikkje gjennom ein ny offentleg port. Løys opp det verkelege namnet, tilpass sertifikatet til det, og tillat éin teneste frå éin kjelde.
NAS-administrasjonssida fungerer heime og sluttar å fungere i det augneblunken administratoren reiser, så nokon opnar ein port, og problemet forsvinn saman med personvernet. Det finst ei betre form for dette. Lat sida bli der ho er, lat tunnelen levera tilgjengelegheita, og gjer det du dokumenterer til ein fullstendig URL med ein namngjeven tillatingssti i staden for ei einingadresse som tilfeldigvis svarar. Kvar avgjerd nedanfor, frå namnet til sertifikatet til den einaste tillatne porten, følgjer av å skrive det slik.
Designininga er ein URL, ikkje ei adresse
Skriv oppføringa som ein fullstendig URL med porten og skjemaet, og fest deretter vilkåra: kven som kan bruke han, frå kva nettverk og via kva sti. Eit døme kan vere https://nas.corp.example:8443 som berre blir publisert til godkjende private klientar, der namnet og porten står for det eininga faktisk lyttar på.
Den ramma tvingar avgjerdene tidleg. Ein URL føreset eit namn, eit namn føreset eit sertifikat, og eit sertifikat føreset ei tillitsordning. Ei adresse føreset ingenting av dette, og nettopp difor overlever adresse-berre-versjonen til den første nettlesaråtvaringa og blir deretter ein vane med å klikke seg gjennom henne.
| 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 |
Hald på namnet sertifikatet vart utstedt til
Klienten treng ein tillaten rute til den private adressa til NAS-en, og ei privat DNS-ordning kan løysa opp det tiltenkte vertsnamnet til den adressa og samstundes ta vare på namnet HTTPS-tenesta ventar. Båe halvdelane tel: ruta får pakkane dit, namnet fortel klienten kva identitet som skal verifiserast.
Å taste den numeriske adressa i staden endrar identitetskravet. RFC 9525 skil namnet ein klient har til føremål å kontakte frå identiteten ei teneste presenterer, så eit sertifikat utstedt til nas.corp.example kan med rette feile når nettlesaren vart peika på 10.20.0.15. Åtvaringa er riktig, og rettinga er namnet, ikkje eit unntak.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleKøyr båe før du klandrar tunnelen. Den første viser om det private namnet blir løyst opp der du trur, og den andre viser kva sertifikat og kva alternative subjektnamn tenesta faktisk presenterer. Ein privat CA kan vere eit heilt velstyrt val; det som ikkje bør bli rutine, er å lære folk å avvise identitetsåtvaringsar.
Avgrens administrasjonsstien
Tillat nøyaktig administrasjonstenesta frå den tiltenkte kjelda, både på gatewayen og på NAS-en. Den setninga skjuler ein detalj som bit: ein ruta klientpool og ein gateway med kjeldeomsetjing kjem til NAS-en med ulike kjeldeadresser, så ein tillatingsregel skriven for den eine feilar stille for den andre.
NAS-en treng òg ein returveg, og nettlesaren må bruke den konfigurerte porten og skjemaet i staden for standardverdien til leverandøren frå eit foruminnlegg. Å nå eininga er ikkje løyve til å nå kvar port på henne. Gapet mellom ei eining som svarar på ping og ei administrasjonsside som lastar, er gapet mellom to separate reglar. Skriv dei som to reglar med to kommentarar, slik at neste person ser kvifor båe finst.
Skil VPN-innslepp frå NAS-privilegium
Å bli sleppt inn gjennom tunnelen er ikkje det same som å få administrere eininga. Ein brukar som legitimt treng fillagring, bør ikkje arve einingadministrasjon fordi båe bur bak ein gateway, og kontomodellen til NAS-en er staden der det skiljet må handhevast.
Ei delt eller omsett utgangsadresse kan heller ikkje identifisere ein individuell administrator. Viss revisjonssporet skal namngje ein person, må identiteten kome frå ein autentisert konto i staden for frå kjeldeadressa til ein tunnel som mange menneske brukar.
Kva du ikkje bør publisere ved eit uhell
Ein offentleg omvend proxy og eit leverandørrelé er båe ekte arkitekturar, og kvar av dei ber sine eigne tillits- og eksponeringsavgjerder. Ingen av dei blir nødvendige fordi ein administrator er borte heimanfrå, og ingen av dei bør dukke opp som ei biverknad av å eksponere ein medieserver eller ei fildeling.
Dokumenter fire ting og stopp: det private namnet, lyttaren det blir mappa til, gruppa som har løyve til å bruke det, og gjenopprettingsstien viss tunnelen ikkje er tilgjengeleg. Dei fire svarar òg på spørsmåla ein hendingsgjennomgang vil stille, noko som ikkje gjeld for eit skjermbilete av ei portvideresendingsside. Det du endar med, er eitt stabilt administrativt inngangspunkt i staden for ei eining der kvar funksjon vender mot internett.