VPN for eit lite kontor: hald han borte frå domenekontrolleren

Tre tilhøve avgjer om kontoret sin einaste Windows-server òg skal avslutte VPN-en: kor mykje internettvend programvare du vil køyre på katalogen, om du kan autentisere fjernbrukarar utan den rolla, og kva som skjer med administrasjonstilgangen din når verten startar på nytt. Dersom eitt av dei tre har eit dårleg svar, skil rollene. At kontoret er lite endrar budsjettet, ikkje risikoen.

Kvar maskin i domenet stolar på ein domenekontroller; ein VPN-gateway kan nåast av kven som helst på internett. Den asymmetrien er heile argumentet.

To jobbar med to ulike eksponeringsprofilar

Gatewayen tek imot tilkoplingar utanfrå, så lyttaren, TLS-stakken og autentiseringsoverflata er alle tilgjengelege frå ikkje-klarerte nettverk. Katalogen har ein autoritet som andre maskinar stolar på, difor behandlar Microsoft sine herdingsrettleiingar domenekontrollerrolla og hostingmiljøet som særleg sensitivt. Kvar teneste som blir lagd til den verten, arvar tillitsposisjonen til katalogen og legg til si eiga åtaksflate. Installasjonskomfort er ikkje ei tillitsgrense.

Å skilje rollene fjernar ikkje avhengnadene. Fjernbrukarar treng framleis autentisering, ruter, DNS og tilgangsreglar, og ein gateway som hoppar over dei er ikkje tryggare, berre mindre nyttig.

Autentisering utan katalogrolla

Ein gateway kan validere legitimasjon gjennom ein støtta ekstern integrasjon utan å hoste katalogen sjølv. Kva den integrasjonen enn er, gje han ein konto der rettane passar til føremålet: lese attributta som trengst for autentisering, ikkje meir. Å ta inn VPN-brukarar krev aldri at dei vanlege kontoane deira blir domeneadministratorar, og det krev aldri at gatewayen har ein kopi av katalogen.

Avgrens deretter nettverksbanene fjernklienten faktisk treng. Tilgang til éin intern filteneste, pluss namneoppløysings- og identitetstenestene den arbeidsflyten er avhengig av, er eit definert sett med baner. Det er ikkje grunn til å tillate kvar domenekontrollerport eller kvart administrativt grensesnitt frå VPN-poolen.

Éin vert er framleis eitt feildomene

To gjester på éin hypervisor skil operativsystemkonfigurasjonen sin og skil ikkje skjebnen sin. Administratorane til hypervisoren, virtuell svitsjing, lagring og sikkerheitskopiar er framleis del av designet, og ein omstart av verten fjernar begge tenestene samtidig. Å kalle det høg tilgjenge fordi diagrammet viser to VM-ar er ein vanleg og dyr feil. Dersom den einaste vegen tilbake går gjennom VPN-en på den verten, tek ein feil bort sambandet som trengst for å reparere han.

Planlegg difor ein uavhengig administrasjonsbane som ikkje er avhengig av tunnelen, og skriv ned kva som blir tilgjengeleg under vedlikehald. Planlegg gatewayoppdateringar og katalogvedlikehald kvar for seg, og noter kva brukarar eller applikasjonar kvar avbrot rører.

Eit vedlikehaldsvindauge som krev at VPN-en er oppe for å reparere VPN-en, er ikkje eit vedlikehaldsvindauge.

Flytt det utan å låse deg ute

Dersom rollene allereie deler éin installasjon, unngå ein forhasta fjernmigrering. Inventer kva gatewayen eig i dag: adresser, vidaresendingsreglar, NAT, DNS-innstillingar, autentiseringskonfigurasjon og eventuelle publiserte tenester. Førebu både erstatninga og ein veg tilbake før du flyttar lyttaren eller endrar ei standardrute. Test deretter ein vanleg fjernbrukar sitt faktiske arbeid gjennom den nye grensa, og stadfest at unødvendig administrativ tilgang framleis feilar.

Målet er ikkje eit penare diagram. Det er evna til å reparere eller byggje opp VPN-en på nytt utan å røre boksen som forankrar katalogtilliten for heile kontoret. Det er ulike mål, og berre eitt av dei treng ein ekstra server.

Noter avgjerda uansett, inkludert vilkåra som ville opne henne på nytt. Eit lite kontor veks, og svaret som passa éin server passar kanskje ikkje den neste.