Placer VPN-gatewayen ved siden af Windows XP, ikke inde i det

Et sted i bygningen står en maskine, der kører en applikation, som ingen kan erstatte, på et styresystem, som ingen bør forbinde til noget. At gå ud fra værtens netværksadapter er den hurtigste måde at se, hvor tunnelen hører hjemme. I de fleste design hører den slet ikke til på værten. Flyt den et hop væk til en vedligeholdt gateway, og det gamle problem skrumper ind til den applikation, det begyndte som.

Start ved værtens adapter, ikke ved en VPN-klient

Åbn adapterens egenskaber, og giv værten en fast adresse på et lille dedikeret segment med gatewayen som standardrute. Værten behøver så hverken tunnelklient, tunnellegitimering eller rutenettabellposter ind i det bredere virksomhedsnetværk. Hvis applikationen har brug for et enkelt fjernsubnet, tilføjes præcis den ene rute.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

Den kommando fastgør en enkelt destination til gatewayen og lader alt andet være urutbart, og det er den form, du ønsker. Bekræft resultatet med route print i stedet for at stole på exitkoden. Kontrollér derefter, at applikationen stadig opløser sit servernavn, for en gammel vært med en ødelagt resolver ligner præcis en netværksfejl, og at reparere resolveren er et femminutters job, mens genopbygning af en applikation efter en forkert netværksændring ikke er. Hver destination, som værten ikke kan nå, er én ting mindre, som en gammel netværksstak kan lokkes til at angribe.

Læg tunnelen på hardware, du kan opdatere

Gatewayen vil have to grænseflader: en mod værtens segment og en mod det sted, hvor applikationen bor, med tunnelen, der terminerer på den anden. Den enhed kan tage firmwareopdateringer, udskifte sin kryptografiske konfiguration og logge flows, uden at nogen rører den gamle maskine. Dens leverandør leverer også rettelser til tunnelimplementeringen, som værten aldrig får. To maskiner og en deadline er ikke grund til at kopiere en opskrift med statisk hemmelighed fra et forumindlæg.

Giv hver gateway sin egen peer-identitet i stedet for at klone én klientkonfiguration til en hel flåde. Når en enhed udskiftes, tilbagekaldes den gamle identitet i samme øjeblik, den nye sættes online, ellers står du med to ukontrollerede kopier, der godkender sig mod samme endepunkt. Opbevar nøglerne, hvor gatewayens styreplan forventer dem, behandl en sikkerhedskopi af konfigurationen som en hemmelighed, og gennemgå, hvem der kan skubbe konfigurationen, for den afgør nu, hvad den gamle vært kan nå.

Tillad tjenester, ikke netværk

Skriv politikken i form af protokol, port og retning mellem de to tilslutninger. Én tilladt port til én applikationsadresse er det sædvanlige svar, og en administrativ vej gennem en jump-host dækker resten.

Fjernadministration af den gamle vært bør ikke køre på samme regel som applikationen, og afprøvning af afvisningen er lige så vigtig som at skrive reglen. Send én anmodning fra værten til en destination, som du forventer afvises, og bekræft, at afvisningen kommer fra politikken og ikke fra en manglende rute. Log de flows, du tillader, mens designet er nyt, så du kan se, hvad applikationen faktisk bruger, i stedet for hvad dens dokumentation påstår. At slå to subnets sammen, fordi en broet vejledning så kortere ud, er måden, hvorpå et gammelt segment stille bliver et springbræt.

Udsæt ikke den gamle lytter direkte for internettet som en genvej uden om gatewayen. Hold den administrative vej adskilt fra applikationsvejen, så et kompromis i den ene ikke overdrager den anden. En regel, der aldrig udøves, er en regel, som ingen har verificeret, og derfor hører den afviste destination med i acceptkørslen.

Gendannelse skal virke uden tunnelen

Beslut, hvem der opdaterer og gendanner gatewayen, før den første afbrydelse, og sørg for, at den person kan nå den uden den tunnel, den terminerer. Konsoladgang, en lokal administrationsport eller en out-of-band-vej tæller alle som svar. En gateway, der kun kan konfigureres gennem den tunnel, den leverer, er en fælde, der tålmodigt venter på et dårligt firmware-push.

Skriv runbooken til det svigt, du faktisk møder: tunnel nede, gateway død, værtens disk væk. Hold værtens gendannelsesbillede under den støtteordning, der stadig findes, og husk, at en gendannelse også gendanner softwaretilstanden og legitimeringen i billedet. Gendan først til det isolerede segment, bekræft, at applikationen starter, og tilslut først derefter noget; når gatewayen ændres, opdateres runbook og inventar i samme omgang.

Certifikater, ure og signaturadvarsler

En installationsprograms certifikatudløb forudsiger ikke i sig selv, hvad en signaturkontrol vil sige i dag. Microsofts vejledning om Authenticode-tidsstempler forklarer, at et tidsstempel kan holde en signatur verificerbar, efter signeringscertifikatet udløber, og at validering stadig afhænger af signaturen, tillidskæden og den verifier, der udfører arbejdet. To maskiner med forskellige tillidslagre kan derfor være uenige om den samme fil. En udløbet signer er ikke bevis for, at en binær fil er ondsindet, og en gyldig signatur er ikke bevis for, at softwaren vedligeholdes.

Flyt ikke systemuret baglæns, og slå ikke signaturkontroller fra for at få et gammelt installationsprogram til at køre. Skaff et autoriseret artefakt gennem dem, der stadig supporterer applikationen, og lad dem sige, hvad platformen accepterer. Behandl indlæg, der hævder, at et bestemt build var det sidste til XP, som historie og ikke som installationsmål, fordi det egentlige krav afhænger af applikationen; hvis bevaringsarbejde virkelig er nødvendigt, holdes det på et isoleret segment væk fra produktionsadgang, og der dokumenteres, hvorfor det findes.