Placera VPN-gatewayen bredvid Windows XP, inte inuti det

Någonstans i byggnaden står en maskin som kör en applikation ingen kan ersätta, på ett operativsystem som ingen bör ansluta till något. Att gå utåt från värdens nätverksadapter är det snabbaste sättet att se var tunneln hör hemma. I de flesta konstruktioner hör den inte till på värden alls. Flytta den ett steg bort till en underhållen gateway, och det gamla problemet krymper tillbaka till applikationen det började som.

Börja vid värdens adapter, inte vid en VPN-klient

Öppna adapterns egenskaper och ge värden en fast adress på ett litet dedikerat segment, med gatewayen som standardväg. Värden behöver då varken tunnelklient, tunneluppgifter eller routingtabellposter in i det bredare företagsnätet. Om applikationen behöver ett enda fjärrsubnät, lägg till exakt den enda vägen.

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

Det kommandot fäster en enda destination vid gatewayen och lämnar allt annat oroutbart, och det är formen du vill ha. Bekräfta resultatet med route print i stället för att lita på slutkoden. Kontrollera sedan att applikationen fortfarande löser upp sitt servernamn, för en gammal värd med trasig resolver ser exakt ut som ett nätverksfel, och att reparera resolvern är ett femminutersjobb medan att bygga om en applikation efter en felaktig nätverksändring inte är det. Varje destination som värden inte når är en sak mindre som en gammal nätverksstack kan övertalas att attackera.

Sätt tunneln på hårdvara du kan uppdatera

Gatewayen vill ha två gränssnitt: ett mot värdsegmentet och ett mot platsen där applikationen bor, med tunneln som slutar på det andra. Den enheten kan ta emot firmwareuppdateringar, byta sin kryptografiska konfiguration och logga flöden utan att någon rör den gamla maskinen. Dess leverantör levererar också rättelser för tunnelimplementeringen, som värden aldrig kommer att få. Två maskiner och en deadline är inte skäl att kopiera ett recept med statisk hemlighet från ett foruminlägg.

Ge varje gateway sin egen peer-identitet i stället för att klona en klientkonfiguration över en hel flotta. När en enhet byts ut, återkalla den gamla identiteten i samma ögonblick som du sätter den nya i drift, annars står du kvar med två okontrollerade kopior som autentiserar mot samma slutpunkt. Lagra nycklarna där gatewayens hanteringsplan förväntar sig dem, behandla en säkerhetskopia av konfigurationen som en hemlighet och granska vem som kan skicka den konfigurationen, för den avgör nu vad den gamla värden kan nå.

Tillåt tjänster, inte nätverk

Skriv policyn i termer av protokoll, port och riktning mellan de två anslutningarna. En enda tillåten port till en enda applikationsadress är det vanliga svaret, och en administrativ väg genom en hoppvärd täcker resten.

Fjärradministration av den gamla värden borde inte gå på samma regel som applikationen, och att testa avvisningen är lika viktigt som att skriva regeln. Skicka en begäran från värden till en destination som du förväntar dig ska avvisas och bekräfta att avvisningen kommer från policyn och inte från en saknad väg. Logga de flöden du tillåter medan designen är ny, så att du ser vad applikationen faktiskt använder och inte vad dess dokumentation påstår. Att slå ihop två subnät för att en bryggad handledning såg kortare ut är hur ett gammalt segment tyst blir ett språngbräda.

Exponera inte den gamla lyssnaren direkt mot internet som en genväg runt gatewayen. Håll den administrativa vägen skild från applikationsvägen, så att kompromettering av den ena inte överlämnar den andra. En regel som aldrig utövas är en regel som ingen har verifierat, och därför hör den avvisade destinationen hemma i acceptanskörningen.

Återställning måste fungera utan tunneln

Bestäm vem som uppdaterar och återställer gatewayen före det första avbrottet, och se till att den personen kan nå den utan tunneln den avslutar. Konsolåtkomst, en lokal hanteringsport eller en väg utanför bandet räknas alla som svar. En gateway som bara kan konfigureras genom tunneln den tillhandahåller är en fälla som tålmodigt väntar på en dålig firmware-överföring.

Skriv runbooken för det fel du faktiskt kommer att möta: tunnel nere, gateway död, värdens disk borta. Behåll värdens återställningsavbildning under vilken supportöverenskommelse som än fortfarande finns, och kom ihåg att en återställning också återställer mjukvarutillståndet och inloggningsuppgifterna i avbildningen. Återställ först till det isolerade segmentet, bekräfta att applikationen startar och återanslut först därefter något; när gatewayen ändras, uppdatera runbooken och inventariet i samma sittning.

Certifikat, klockor och signaturvarningar

Ett installationsprograms certifikatutgång förutsäger inte i sig vad en signaturkontroll kommer att säga i dag. Microsofts vägledning om Authenticode-tidsstämplar förklarar att en tidsstämpel kan hålla en signatur verifierbar efter att signeringscertifikatet har gått ut, och valideringen beror fortfarande på signaturen, förtroendekedjan och verifieraren som gör arbetet. Två maskiner med olika förtroendelager kan därför vara oense om samma fil. En utgången undertecknare är inte bevis för att en binärfil är skadlig, och en giltig signatur är inte bevis för att programvaran underhålls.

Flytta inte systemklockan bakåt och slå inte av signaturkontroller för att få ett gammalt installationsprogram att köra. Skaffa en auktoriserad artefakt från den som fortfarande stöder applikationen och låt dem säga vad plattformen accepterar. Behandla inlägg som hävdar att en viss build var den sista för XP som historia, inte som installationsmål, eftersom det verkliga kravet beror på applikationen; om bevarandearbete verkligen behövs, håll det på ett isolerat segment långt från produktionsåtkomst och dokumentera varför det finns.