NAS-administrado tra VPN: konservu la nomon, forlasu la publikan pordon
Atingu la administran paĝon tra la tunelo, ne per nova publika pordo. Solvu la veran nomon, kongruigu la atestilon al ĝi kaj permesu unu servon el unu fonto.
La NAS-administra paĝo funkcias hejme kaj ĉesas funkcii en la momento, kiam la administranto vojaĝas, do iu malfermas pordon kaj la problemo malaperas kune kun la privateco. Ekzistas pli bona formo por tio. Lasu la paĝon tie, kie ĝi estas, lasu la tunelon provizi atingeblon, kaj faru tion, kion vi dokumentas, plenan URL-on kun nomita permesa vojo anstataŭ aparata adreso, kiu hazarde respondas. Ĉiu decido sube, de la nomo ĝis la atestilo kaj la sola permesita pordo, sekvas el skribi ĝin tiel.
La dezjena unuo estas URL, ne adreso
Skribu la eniron kiel plenan URL-on kun ĝia pordo kaj skemo, poste aldonu la kondiĉojn: kiu rajtas uzi ĝin, el kiu reto kaj laŭ kiu vojo. Ekzemplo povus esti https://nas.corp.example:8443 publikigita nur al aprobitaj privataj klientoj, kie la nomo kaj pordo reprezentas tion, kion la aparato efektive aŭskultas.
Tiu kadro devigas la decidojn frue. URL implicas nomon, nomo implicas atestilon, kaj atestilo implicas fidinterkonsenton. Adreso implicas neniun el tiuj, kaj ĝuste tial la versio nur kun adreso postvivas ĝis la unua retumila averto kaj poste fariĝas kutimo klaki tra ĝi.
| 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 |
Konservu la nomon, por kiu la atestilo estis eldonita
La kliento bezonas permesitan itineron al la privata adreso de la NAS, kaj privata DNS-aranĝo povas solvi la celatan gastignomon al tiu adreso konservante la nomon, kiun la HTTPS-servo atendas. Ambaŭ duonoj gravas: la itinero portas pakaĵojn tien, la nomo diras al la kliento, kiun identecon kontroli.
Tajpi la numeran adreson anstataŭe ŝanĝas la identecpostulon. RFC 9525 apartigas la nomon, kiun kliento intencas kontakti, de la identeco, kiun servo prezentas, do atestilo eldonita por nas.corp.example povas laŭleĝe malsukcesi, kiam la retumilo estis direktita al 10.20.0.15. La averto estas ĝusta, kaj la solvo estas la nomo, ne escepto.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleRulu ambaŭ antaŭ ol kulpigi la tunelon. La unua montras, ĉu la privata nomo solviĝas tie, kie vi pensas, kaj la dua montras, kiun atestilon kaj kiujn alternativajn subjektnomojn la servo efektive prezentas. Privata CA povas esti tute bone administrata elekto; tio, kio ne devus fariĝi rutino, estas instrui homojn ignori identecajn avertojn.
Limigu la administran vojon
Permesu precize la administran servon el la celata fonto, kaj ĉe la enirejo kaj ĉe la NAS. Tiu frazo kaŝas detalon, kiu mordas: enkursigita klientaro kaj enirejo kun fonttradukado alvenas al la NAS kun malsamaj fontadresoj, do permesa regulo skribita por unu silentas malsukcese por la alia.
La NAS ankaŭ bezonas revenan vojon, kaj la retumilo devas uzi la agorditan pordon kaj skemon anstataŭ la fabrikantan defaŭlton el forumafiŝo. Atingi la aparaton ne estas permeso atingi ĉiun pordon sur ĝi. La breĉo inter aparato, kiu respondas al ping, kaj administra paĝo, kiu ŝargiĝas, estas la breĉo inter du apartaj reguloj. Skribu ilin kiel du regulojn kun du komentoj, por ke la sekva persono vidu, kial ambaŭ ekzistas.
Apartigu VPN-akcepton de NAS-privilegio
Esti lasita tra la tunelo ne samas kiel rajtis administri la aparaton. Uzanto, kiu laŭleĝe bezonas dosierstokadon, ne devus heredi aparatan administradon nur ĉar ambaŭ loĝas malantaŭ unu enirejo, kaj la kontomodelo de la NAS estas la loko, kie tiu apartigo devas esti devigita.
Komunigita aŭ tradukita elira adreso ankaŭ ne povas identigi unuopan administranton. Se la revizia spuro devas nomi personon, la identeco devas veni de aŭtentigita konto anstataŭ de la fontadreso de tunelo, kiun uzas multaj homoj.
Kion ne publikigi hazarde
Publika inversa prokurilo kaj vendista relajso ambaŭ estas realaj arkitekturoj, kaj ĉiu portas siajn proprajn decidojn pri fido kaj elmetiĝo. Neniu fariĝas necesa ĉar administranto estas for de hejmo, kaj neniu devus aperi kiel flankefiko de elmetado de aŭdovida servilo aŭ dosierkomunigo.
Dokumentu kvar aferojn kaj haltu: la privatan nomon, la aŭskultanton al kiu ĝi mapiĝas, la grupon permesitan uzi ĝin, kaj la restaŭran vojon se la tunelo ne disponeblas. Tiuj kvar ankaŭ respondas la demandojn, kiujn revizio de okazaĵo demandos, kio ne veras pri ekrankopio de pordplusenda paĝo. Tio, kion vi finfine havas, estas unu stabila administra enirpunkto anstataŭ aparato, kies ĉiu funkcio frontas al la interreto.