Sett VPN-gatewayen ved siden av Windows XP, ikke inni det

Et sted i bygningen står en maskin som kjører en applikasjon ingen kan erstatte, på et operativsystem ingen bør koble til noe. Å gå utover fra nettverksadapteren på den verten er den raskeste måten å se hvor tunnelen hører hjemme. I de fleste design hører den ikke til på verten i det hele tatt. Flytt den ett hopp unna til en vedlikeholdt gateway, og det gamle problemet krymper tilbake til applikasjonen det begynte som.

Start ved vertens adapter, ikke ved en VPN-klient

Åpne adapteregenskapene og gi verten en fast adresse på et lite dedikert segment, med gatewayen som standardrute. Verten trenger da verken tunnelklient, tunneltilgang eller rutingtabelloppføringer inn i det bredere bedriftsnettet. Hvis applikasjonen trenger ett eksternt subnett, legg til nøyaktig den ene ruten.

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

Den kommandoen fester én destinasjon til gatewayen og lar alt annet være urutbart, og det er formen du vil ha. Bekreft resultatet med route print i stedet for å stole på avslutningskoden. Kontroller deretter at applikasjonen fortsatt løser opp servernavnet sitt, for en gammel vert med ødelagt resolver ser nøyaktig ut som en nettverksfeil, og å reparere resolveren er en femminuttersjobb mens å bygge en applikasjon på nytt etter en feil nettverksendring ikke er det. Hver destinasjon verten ikke når, er én ting mindre en gammel nettverksstakk kan lures til å angripe.

Sett tunnelen på maskinvare du kan oppdatere

Gatewayen vil ha to grensesnitt: ett mot vertssegmentet og ett mot stedet der applikasjonen bor, med tunnelen som avsluttes på det andre. Den enheten kan ta fastvareoppdateringer, bytte kryptografisk konfigurasjon og logge flyter uten at noen rører den gamle maskinen. Leverandøren leverer også rettelser for tunnelimplementasjonen, som verten aldri vil få. To maskiner og en frist er ikke grunn til å kopiere en oppskrift med statisk hemmelighet fra et foruminnlegg.

Gi hver gateway sin egen peer-identitet i stedet for å klone én klientkonfigurasjon over en hel flåte. Når en enhet byttes, tilbakekall den gamle identiteten i samme øyeblikk som du setter den nye i drift, ellers sitter du igjen med to ukontrollerte kopier som autentiserer mot samme endepunkt. Lagre nøklene der gatewayens administrasjonsplan forventer dem, behandle en sikkerhetskopi av konfigurasjonen som en hemmelighet og gjennomgå hvem som kan skyve den konfigurasjonen, for den avgjør nå hva den gamle verten kan nå.

Tillat tjenester, ikke nettverk

Skriv policyen i form av protokoll, port og retning mellom de to tilkoblingene. Én tillatt port til én applikasjonsadresse er det vanlige svaret, og en administrativ vei gjennom en hoppvert dekker resten.

Fjernadministrasjon av den gamle verten bør ikke gå på samme regel som applikasjonen, og å teste avvisningen er like viktig som å skrive regelen. Send én forespørsel fra verten til en destinasjon du forventer blir avvist, og bekreft at avvisningen kommer fra policyen og ikke fra en manglende rute. Logg flytene du tillater mens designet er nytt, så du ser hva applikasjonen faktisk bruker og ikke hva dokumentasjonen hevder. Å slå sammen to subnett fordi en broet veiledning så kortere ut, er måten et gammelt segment stille blir et springbrett.

Ikke eksponer den gamle lytteren direkte mot internett som en snarvei rundt gatewayen. Hold den administrative veien atskilt fra applikasjonsveien, så kompromittering av den ene ikke overleverer den andre. En regel som aldri utøves, er en regel ingen har verifisert, og derfor hører den avviste destinasjonen hjemme i akseptkjøringen.

Gjenoppretting må fungere uten tunnelen

Bestem hvem som oppdaterer og gjenoppretter gatewayen før det første avbruddet, og sørg for at den personen kan nå den uten tunnelen den avslutter. Konsolltilgang, en lokal administrasjonsport eller en out-of-band-vei teller alle som svar. En gateway som bare kan konfigureres gjennom tunnelen den leverer, er en felle som tålmodig venter på en dårlig fastvareoverføring.

Skriv runboken for feilen du faktisk vil møte: tunnel nede, gateway død, vertsdisk borte. Hold gjenopprettingsbildet av verten under enhver støtteordning som fortsatt finnes, og husk at en gjenoppretting også gjenoppretter programtilstanden og tilgangsopplysningene i bildet. Gjenopprett først til det isolerte segmentet, bekreft at applikasjonen starter, og koble først deretter til noe igjen; når gatewayen endres, oppdater runboken og inventaret i samme økt.

Sertifikater, klokker og signaturvarsler

Utløpet av installasjonsprogrammets sertifikat forutsier ikke i seg selv hva en signaturkontroll vil si i dag. Microsofts veiledning om Authenticode-tidsstempler forklarer at et tidsstempel kan holde en signatur verifiserbar etter at signeringssertifikatet utløper, og at validering fortsatt avhenger av signaturen, tillitskjeden og verifikatoren som gjør jobben. To maskiner med ulike tillitslagre kan derfor være uenige om samme fil. En utløpt signerer er ikke bevis for at en binærfil er ondsinnet, og en gyldig signatur er ikke bevis for at programvaren vedlikeholdes.

Ikke flytt systemklokken bakover og ikke slå av signaturkontroller for å få et gammelt installasjonsprogram til å kjøre. Skaff et autorisert artefakt fra den som fortsatt støtter applikasjonen, og la dem si hva plattformen godtar. Behandle innlegg som hevder at en bestemt build var den siste for XP, som historie og ikke som installasjonsmål, fordi det virkelige kravet avhenger av applikasjonen; hvis bevaringsarbeid virkelig er nødvendig, hold det på et isolert segment langt fra produksjonstilgang og dokumenter hvorfor det finnes.