Migrera från ett PPP-baserat VPN utan att kopiera dess antaganden

En VPN-migrering är klar när användarna, destinationerna, namnmatchningen och beteendet vid fel fortfarande stämmer, inte när den nya klienten visar en grön ikon. Gamla PPP-baserade installationer bär på antaganden som aldrig skrevs ned: en delad hemlighet som också var den enda identitetskontrollen, en fast adresspool som brandväggen har på tillåtlistan, och ett DNS-suffix som servern skickar ut. Att byta protokoll utan att inventera dessa antaganden ger en tunnel som genomför handskakningen och en gräns som inte finns. Ordningen nedan är den jag använder, och det sista steget är det som team hoppar över.

Steg 1: inventera vad den gamla anslutningen erbjuder

Inventeringen skrivs, inte memoreras. Registrera de klienter som stöds, autentiseringsrollerna, adresspoolerna, de skyddade näten, DNS-kraven och de tjänstetillstånd som varje användargrupp behöver.

För L2TP/IPsec ska du uttryckligen skilja på de två lagren. IPsec-motpartens identitet autentiserar maskinerna; PPP autentiserar användaren, vanligtvis med CHAP eller MSCHAPv2.

Det är i den uppdelningen gamla installationer gömmer sina antaganden. En i förväg delad nyckel som alla klienter delar autentiserar en grupp och inte en enhet, och den är ofta det enda som någonsin har roterats. Om PPP-kontot är den verkliga kontrollen per användare, säg det, eftersom ersättningen måste återskapa den kontrollen med något som inte är en delad sträng. Notera också fasta källadresser och undantag för det lokala nätet, för det är beroendena som ingen dokumenterar förrän de går sönder.

Steg 2: designa ersättningen medvetet

Att välja ersättningen är en krav-för-krav-mappning: ett protokoll och en underhållen klient som organisationen stöder, där varje identitets- och åtkomstkrav landar i en faktisk mekanism. En delad hemlighet är inte automatiskt likvärdig med en nyckel eller ett certifikat per enhet, och ett PPP-konto per användare är inte likvärdigt med ett enhetscertifikat.

Samordna adressintervallen före allt annat, eftersom en ersättningspool som överlappar ett hem- eller kontorsnät skapar ett fel som inte har något med chiffrestyrka att göra. Kontrollera poolen mot samma lista som du byggde för den gamla tjänsten, plus det den nya klienten antar som standard. Bekräfta returrutningen för de skyddade näten och bekräfta att den nya klienten kan skicka ut eller dokumentera det DNS-suffix som den gamla skickade ut. Dessa två punkter ger fler migreringsärenden än själva protokollbytet.

Steg 3: inför stegvis och verifiera både tillåt och neka

Inför med en representativ användare och en representativ applikation. Ta med privat DNS-uppslagning i testet, eftersom en tunnel som når en adress men inte kan lösa ett internt namn bara är halvt migrerad. Ta också med det förväntade otillgängliga tillståndet: vad som ska hända när tunneln faller, och om klienten genomdriver det.

Testa sedan en destination som ska förbli nekad. En bred tillfällig tillåtelseregel kan få den nya tunneln att se frisk ut medan den tyst tar bort den auktoriseringsgräns som den gamla tjänsten upprätthöll, och ingen märker det förrän vid en revision. Jämför tillåt- och nekaresultat sida vid sida, från samma klient, i samma session. Håll den gamla tjänsten igång tills båda kolumnerna stämmer med designen.

Innan du flyttar administratörsåtkomsten, bekräfta att du har en auktoriserad återställningsväg som inte beror på tunneln du ändrar.

Steg 4: avveckla den gamla identiteten

Korrekt avveckling av den gamla identiteten innebär att återkalla föråldrade användare och enhetsuppgifter via tjänsten som äger dem, och sedan ta bort gamla profiler och lyssnare när inget beroende återstår. Att radera en lokal fil återkallar inte en kopia någon annanstans, och en gammal lyssnare som fortfarande accepterar den gamla delade hemligheten är en dörr utan övervakning.

Den punkten är värd att sakta ner för. En avvecklad klientprofil på en bärbar dator är inte en återkallad autentiseringsuppgift; uppgiften lever på servern och förblir giltig tills servern slutar acceptera den. Leta efter andra kopior av den gamla konfigurationen — testenheter, en glömd telefon, ett installationsprogram som någon har sparat — och behandla nedstängningen av lyssnaren som ögonblicket då den gamla tjänsten faktiskt upphör. Tills dess har migreringen två ytterdörrar.

Acceptansprotokollet är inventeringen från steg ett med en kolumn tillagd: vad den nya designen gör för varje rad, och hur du verifierade det. Det gör en protokolluppgradering till ett tjänstekrav med bevis.

Håll resultatet knutet till vad tjänsten behöver och inte till protokollnamnet, eftersom ett modernt protokoll med de gamla antagandena inkopierade är samma risk med bättre ramverk. RFC 3193 beskriver hur L2TP bärs över IPsec, vilket är en nyttig påminnelse om att de två lagren alltid var separata beslut. Om inventeringen har en rad du inte kan förklara, stanna och ta reda på vad som beror på den. Migreringen är klar när listan är tråkig.