Administrarea NAS prin VPN: păstrați numele, renunțați la portul public
Ajungeți la pagina de administrare prin tunel, nu printr-un port public nou. Rezolvați numele real, potriviți certificatul cu el și permiteți un singur serviciu dintr-o singură sursă.
Pagina de administrare a NAS funcționează acasă și se oprește în momentul în care administratorul călătorește, așa că cineva deschide un port și problema dispare împreună cu confidențialitatea. Există o formă mai bună pentru asta. Lăsați pagina unde este, lăsați tunelul să asigure accesibilitatea și faceți din ceea ce documentați un URL complet cu o cale de permisiune numită, nu o adresă de dispozitiv care răspunde din întâmplare. Fiecare decizie de mai jos, de la nume la certificat și la singurul port permis, decurge din a o scrie astfel.
Unitatea de proiectare este un URL, nu o adresă
Scrieți intrarea ca URL complet cu portul și schema sa, apoi atașați condițiile: cine o poate folosi, din ce rețea și pe ce cale. Un exemplu ar putea fi https://nas.corp.example:8443 publicat doar pentru clienți privați aprobați, cu numele și portul reprezentând ceea ce dispozitivul ascultă de fapt.
Această structură forțează deciziile devreme. Un URL implică un nume, un nume implică un certificat, iar un certificat implică o înțelegere de încredere. O adresă nu implică nimic din toate acestea, și exact de aceea versiunea doar cu adresă supraviețuiește până la primul avertisment al browserului și apoi devine un obicei de a face clic prin el.
| 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 |
Păstrați numele pentru care a fost emis certificatul
Clientul are nevoie de o rută permisă către adresa privată a NAS, iar o configurație DNS privată poate rezolva numele de gazdă dorit către acea adresă păstrând totodată numele pe care serviciul HTTPS îl așteaptă. Ambele jumătăți contează: ruta duce pachetele acolo, numele îi spune clientului ce identitate să verifice.
Tastarea adresei numerice în schimb schimbă cerința de identitate. RFC 9525 separă numele cu care un client intenționează să contacteze de identitatea pe care o prezintă un serviciu, așa că un certificat emis pentru nas.corp.example poate eșua în mod legitim când browserul a fost îndreptat către 10.20.0.15. Avertismentul este corect, iar soluția este numele, nu o excepție.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleRulați ambele înainte de a da vina pe tunel. Primul arată dacă numele privat se rezolvă unde credeți, iar al doilea arată ce certificat și ce nume alternative de subiect prezintă de fapt serviciul. O CA privată poate fi o alegere perfect gestionată; ceea ce nu ar trebui să devină rutină este să învățăm oamenii să ignore avertismentele de identitate.
Limitați calea de administrare
Permiteți exact serviciul de administrare din sursa dorită, atât la poartă, cât și la NAS. Acea frază ascunde un detaliu care mușcă: un pool de clienți rutat și o poartă cu traducere de sursă ajung la NAS cu adrese de sursă diferite, așa că o regulă de permisiune scrisă pentru una eșuează în silențiu pentru cealaltă.
NAS-ul are nevoie și de o cale de întoarcere, iar browserul trebuie să folosească portul și schema configurate, nu valoarea implicită a producătorului luată dintr-o postare pe forum. A ajunge la dispozitiv nu este permisiunea de a ajunge la fiecare port al acestuia. Diferența dintre un dispozitiv care răspunde la ping și o pagină de administrare care se încarcă este diferența dintre două reguli separate. Scrieți-le ca două reguli cu două comentarii, ca următoarea persoană să vadă de ce există ambele.
Separați admiterea VPN de privilegiul NAS
Să fii lăsat să treci prin tunel nu este același lucru cu a avea voie să administrezi dispozitivul. Un utilizator care are nevoie în mod legitim de stocare de fișiere nu ar trebui să moștenească administrarea dispozitivului doar pentru că ambele stau în spatele unei porți, iar modelul de conturi al NAS este locul unde acea separare trebuie impusă.
O adresă de ieșire partajată sau tradusă nu poate identifica nici un administrator individual. Dacă urma de audit trebuie să numească o persoană, identitatea trebuie să vină dintr-un cont autentificat, nu din adresa de sursă a unui tunel folosit de mulți oameni.
Ce să nu publicați din greșeală
Un proxy invers public și un releu al producătorului sunt ambele arhitecturi reale, iar fiecare poartă propriile decizii de încredere și expunere. Niciunul nu devine necesar pentru că un administrator este plecat de acasă, și niciunul nu ar trebui să apară ca efect secundar al expunerii unui server media sau al unei partajări de fișiere.
Documentați patru lucruri și opriți-vă: numele privat, listenerul căruia îi este mapat, grupul permis să îl folosească și calea de recuperare dacă tunelul nu este disponibil. Acele patru răspund și întrebărilor pe care le va pune o analiză a incidentului, ceea ce nu este valabil pentru o captură de ecran a unei pagini de redirecționare de porturi. Ce obțineți în final este un punct de intrare administrativ stabil în locul unui dispozitiv cu fiecare funcție îndreptată spre internet.