Pangangasiwa ng NAS sa VPN: itago ang pangalan, bitawan ang pampublikong port
Abutin ang pahina ng pangangasiwa sa pamamagitan ng tunel, hindi sa bagong pampublikong port. Lutasin ang tunay na pangalan, itugma ang sertipiko dito, at payagan ang isang serbisyo mula sa isang pinagmulan.
Gumagana ang pahina ng pangangasiwa ng NAS sa bahay at tumitigil itong gumana sa sandaling maglakbay ang administrador, kaya may nagbubukas ng port at nawawala ang problema kasama ng pagkapribado. May mas mabuting anyo para dito. Iwanan ang pahina kung saan ito naroroon, hayaang ang tunel ang magbigay ng maabot, at gawin ang dokumentado mo na isang buong URL na may pinangalanang landas ng pahintulot, hindi isang address ng device na nagkataong sumasagot. Bawat desisyon sa ibaba, mula sa pangalan hanggang sa sertipiko at sa nag-iisang pinapayagang port, ay nagmumula sa pagsulat nito nang ganoon.
Ang yunit ng disenyo ay URL, hindi address
Isulat ang pasukan bilang buong URL kasama ang port at scheme nito, pagkatapos idagdag ang mga kundisyon: sino ang puwedeng gumamit, mula sa aling network at sa aling landas. Isang halimbawa ay ang https://nas.corp.example:8443 na inilalathala lamang sa mga aprubadong pribadong kliyente, kung saan ang pangalan at port ang kumakatawan sa aktwal na pinakikinggan ng device.
Pinipilit ng balangkas na iyon ang mga desisyon nang maaga. Ang URL ay nagpapahiwatig ng pangalan, ang pangalan ay nagpapahiwatig ng sertipiko, at ang sertipiko ay nagpapahiwatig ng kasunduan sa tiwala. Ang address ay walang ipinapahiwatig sa mga iyon, at iyon mismo ang dahilan kung bakit ang bersyong address-lamang ay tumatagal hanggang sa unang babala ng browser at pagkatapos ay nagiging ugali ang pag-click dito.
| 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 |
Itago ang pangalang inilaan ng sertipiko
Kailangan ng kliyente ng pinapayagang ruta patungo sa pribadong address ng NAS, at ang pribadong kaayusan ng DNS ay maaaring lutasin ang nilalayong hostname patungo sa address na iyon habang pinapanatili ang pangalang inaasahan ng serbisyong HTTPS. Mahalaga ang dalawang hati: dinadala ng ruta ang mga packet doon, sinasabi ng pangalan sa kliyente kung aling pagkakakilanlan ang i-verify.
Ang pag-type ng numerong address sa halip ay nagbabago ng pangangailangan sa pagkakakilanlan. Hinihiwalay ng RFC 9525 ang pangalang nilalayon ng kliyenteng kontakin mula sa pagkakakilanlang ipinapakita ng serbisyo, kaya ang sertipikong inilaan para sa nas.corp.example ay maaaring lehitimong mabigo kapag ang browser ay itinuro sa 10.20.0.15. Tama ang babala, at ang lunas ay ang pangalan, hindi isang eksepsiyon.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.examplePatakbuhin ang dalawa bago sisihin ang tunel. Ipinapakita ng una kung ang pribadong pangalan ay nalulutas sa lugar na iniisip mo, at ipinapakita ng pangalawa kung aling sertipiko at aling mga alternatibong pangalan ng paksa ang aktwal na ipinapakita ng serbisyo. Ang pribadong CA ay maaaring maging ganap na mahusay na pinamamahalaang pagpipilian; ang hindi dapat maging routine ay ang turuan ang mga tao na balewalain ang mga babala sa pagkakakilanlan.
Limitahan ang landas ng pangangasiwa
Payagan ang eksaktong serbisyo ng pangangasiwa mula sa nilalayong pinagmulan, sa gateway at sa NAS. Itinatago ng pangungusap na iyon ang isang detalyeng kumakagat: ang naka-rutang pool ng kliyente at ang gateway na may pagsasalin ng pinagmulan ay dumarating sa NAS na may magkaibang address ng pinagmulan, kaya ang tuntunin ng pahintulot na isinulat para sa isa ay tahimik na nabibigo para sa isa.
Kailangan din ng NAS ng ruta ng pagbabalik, at kailangang gamitin ng browser ang naka-configure na port at scheme sa halip na ang default ng vendor mula sa isang post sa forum. Ang maabot ang device ay hindi pahintulot na maabot ang bawat port nito. Ang agwat sa pagitan ng device na sumasagot sa ping at ng pahina ng pangangasiwa na naglo-load ay ang agwat sa pagitan ng dalawang magkaibang tuntunin. Isulat ang mga ito bilang dalawang tuntunin na may dalawang komento, upang makita ng susunod na tao kung bakit pareho silang umiiral.
Ihiwalay ang pagtanggap sa VPN mula sa pribilehiyo sa NAS
Ang mapayagang makapasok sa tunel ay hindi katulad ng mapayagang pamahalaan ang device. Ang isang user na lehitimong nangangailangan ng imbakan ng file ay hindi dapat magmana ng pangangasiwa ng device dahil lang pareho silang nasa likod ng isang gateway, at ang modelo ng account ng NAS ang lugar kung saan dapat ipatupad ang paghihiwalay na iyon.
Ang ibinahagi o isinaling address ng labasan ay hindi rin makapagkikilanlan ng isang indibidwal na administrador. Kung kailangang pangalanan ng audit trail ang isang tao, ang pagkakakilanlan ay dapat magmula sa isang authenticated na account at hindi sa address ng pinagmulan ng tunel na ginagamit ng maraming tao.
Ano ang hindi dapat ilathala nang aksidente
Ang pampublikong reverse proxy at ang relay ng vendor ay parehong tunay na arkitektura, at bawat isa ay may sariling desisyon sa tiwala at pagkakalantad. Wala sa kanila ang nagiging kailangan dahil ang isang administrador ay wala sa bahay, at wala sa kanila ang dapat lumitaw bilang side effect ng paglalantad ng isang media server o file sharing.
Idokumento ang apat na bagay at huminto: ang pribadong pangalan, ang listener na kinakabitan nito, ang grupong pinapayagang gumamit nito, at ang landas ng pagbawi kung hindi available ang tunel. Sinasagot din ng apat na iyon ang mga tanong na itatanong ng isang pagsusuri ng insidente, na hindi totoo para sa isang screenshot ng pahina ng port forwarding. Ang nauuwi sa iyo ay isang matatag na administratibong pasukan sa halip na isang device na bawat tampok ay nakaharap sa internet.