VPN foar in lyts kantoar: hâld it by de domeinkontrôler wei

Trije betingsten bepale oft de iennichste Windows-tsjinner fan it kantoar ek de VPN beëinigje moat: hoefolle ynternetrjochte software jo op de map rinne litte wolle, oft jo fierôf brûkers sûnder dy rol ferifiearje kinne, en wat der mei jo behearstagonk bart as de host wer opstart. As ien fan de trije in min antwurd hat, skied de rollen. Dat it kantoar lyts is, feroaret it budzjet, net it risiko.

Elke masine yn it domein fertrout in domeinkontrôler; in VPN-poarte is foar elkenien op it ynternet berikber. Dy asymmetry is it hiele argumint.

Twa taken mei twa ferskillende bleatstellingsprofylen

De poarte akseptearret ferbiningen fan bûten, dus har harker, har TLS-stapel en har ferifikaasje-oerflak binne allegear berikber fan net-fertroude netwurken. De map hat in autoriteit dêr't oare masines op fertrouwe, dêrom behannelje Microsoft syn fersterkingsrjochtlinen de domeinkontrôlerrol en syn hostingomjouwing as bysûnder gefoelich. Eltse tsjinst dy't oan dy host tafoege wurdt, erft de fertrouwensposysje fan de map wylst se har eigen oanfalsoerflak tafoegt. Gemak fan ynstallaasje is gjin fertrouwensgrins.

It skieden fan de rollen hellet de ôfhinklikheden net fuort. Fierôf brûkers hawwe noch hieltyd ferifikaasje, rûtes, DNS en tagongsregels nedich, en in poarte dy't dy oerslacht is net feiliger, allinnich minder nuttich.

Ferifikaasje sûnder de maprol

In poarte kin bewiisstikken ferifiearje fia in stipe eksterne yntegraasje sûnder de map sels te hosten. Hokker yntegraasje dat ek is, jou it in akkount wêrfan de rjochten by it doel passe: de attributen lêze dy't nedich binne foar ferifikaasje, net mear. It talitten fan VPN-brûkers freget nea dat har gewoane akkounts domeinbehearders wurde, en it freget nea dat de poarte in kopy fan de map hâldt.

Behein dan de netwurkpaden dy't de fierôf kliïnt echt nedich hat. Tagong ta ien ynterne triemtsjinst, plus de namme-oplossings- en identiteitstsjinsten dêr't dy wurkstream fan ôfhinklik is, is in definiearre set paden. It is gjin reden om elke domeinkontrôlerpoarte of elk beheerynterface fan de VPN-pool ta te litten.

Ien host is noch hieltyd ien flaterdomein

Twa gasten op ien hypervisor skiede har bestjoeringssysteemkonfiguraasje en skiede har lot net. De behearders fan de hypervisor, firtuele skeakeling, opslach en backups bliuwe diel fan it ûntwerp, en in werstart fan de host hellet beide tsjinsten tagelyk fuort. Dat hege beskikberens neame om't it diagram twa VM's toant is in algemiene en djoere flater. As de iennichste wei werom troch de VPN op dy host rint, nimt in flater de ferbining wei dy't nedich is om it te reparearjen.

Plan dus in ûnôfhinklike behearwei dy't net fan de tunnel ôfhinklik is, en skriuw op wat ûnder ûnderhâld beskikber bliuwt. Plen poartebywurkingen en mapûnderhâld apart, en notearje hokker brûkers of applikaasjes elke ûnderbrekking rekket.

In ûnderhâldsfinster dat freget dat de VPN oan is om de VPN te reparearjen is gjin ûnderhâldsfinster.

Ferpleats it sûnder josels bûten te sluten

As de rollen al ien ynstallaasje diele, foarmje in oerhaaste fierôf migraasje. Meitsje in ynventarisaasje fan wat de poarte hjoed besit: adressen, trochstjoerregels, NAT, DNS-ynstellings, ferifikaasjekonfiguraasje en alle publisearre tsjinsten. Tariede sawol de ferfanging as in wei werom foardat jo de harker ferpleatse of in standertrûte feroarje. Test dan it echte wurk fan in gewoane fierôf brûker troch de nije grins, en befêstigje dat ûnnodige beheertagonk noch hieltyd mislearret.

It doel is gjin moaier diagram. It is it fermogen om de VPN te reparearjen of wer op te bouwen sûnder de kast oan te reitsjen dy't it mapfertrouwen foar it hiele kantoar ferankere. Dat binne ferskillende doelen, en mar ien fan har hat in twadde tsjinner nedich.

Skriuw de beslissing hoe dan ek op, ynklusyf de betingsten dy't it wer iepenje soene. In lyts kantoar groeit, en it antwurd dat by ien tsjinner paste, past miskien net by de folgjende.