Migreren van een op PPP gebaseerde VPN zonder de aannames te kopiëren

Een VPN-migratie is pas klaar als de gebruikers, bestemmingen, naamresolutie en het gedrag bij storingen nog steeds kloppen, niet als de nieuwe client een groen pictogram toont. Oude op PPP gebaseerde implementaties dragen aannames die nooit zijn opgeschreven: een gedeeld geheim dat ook de enige identiteitscontrole was, een vaste adrespoel die de firewall op de allowlist heeft, een DNS-suffix die de server pusht. Het protocol vervangen zonder die aannames te inventariseren levert een tunnel die de handshake voltooit en een grens die niet bestaat. De volgorde hieronder is de volgorde die ik gebruik, en de laatste stap is degene die teams overslaan.

Stap 1: inventariseer wat de oude verbinding biedt

De inventaris wordt geschreven, niet onthouden. Noteer de ondersteunde clients, de authenticatierollen, de adrespoelen, de beschermde netwerken, de DNS-eisen en de dienstmachtigingen die elke gebruikersgroep nodig heeft.

Voor L2TP/IPsec scheidt u de twee lagen expliciet. De IPsec-peeridentiteit authenticeert de machines; PPP authenticeert de gebruiker, meestal met CHAP of MSCHAPv2.

In die scheiding verbergen oude implementaties hun aannames. Een vooraf gedeelde sleutel die elke client deelt, authenticeert een groep in plaats van een apparaat, en vaak is dat het enige dat ooit is geroteerd. Als het PPP-account de echte controle per gebruiker is, zeg dat dan, want de vervanging moet die controle reproduceren met iets dat geen gedeelde tekenreeks is. Noteer ook vaste bronadressen en uitzonderingen voor het lokale netwerk, want dat zijn de afhankelijkheden die niemand documenteert tot ze breken.

Stap 2: ontwerp de vervanging bewust

De vervanging kiezen is een koppeling eis voor eis: een protocol en een onderhouden client die de organisatie ondersteunt, waarbij elke identiteits- en toegangseis in een echt mechanisme landt. Een gedeeld geheim is niet automatisch gelijk aan een sleutel of certificaat per apparaat, en een PPP-account per gebruiker is niet gelijk aan een apparaatcertificaat.

Stem adresbereiken af vóór al het andere, want een vervangende poel die een thuis- of kantoornetwerk overlapt, veroorzaakt een storing die niets met ciphersterkte te maken heeft. Controleer de poel tegen dezelfde lijst die u voor de oude dienst heeft opgesteld, plus wat de nieuwe client standaard aanneemt. Bevestig de retourroutering voor de beschermde netwerken en bevestig dat de nieuwe client de DNS-suffix kan pushen of documenteren die de oude pushte. Die twee punten veroorzaken meer migratietickets dan de protocolwijziging zelf.

Stap 3: voer het gefaseerd in en verifieer zowel toestaan als weigeren

Voer in met één representatieve gebruiker en één representatieve toepassing. Neem privé-DNS-resolutie op in de test, want een tunnel die een adres bereikt maar geen interne naam kan oplossen, is maar half gemigreerd. Neem ook de verwachte niet-beschikbare toestand op: wat er moet gebeuren als de tunnel wegvalt, en of de client dat afdwingt.

Test daarna een bestemming die geweigerd moet blijven. Een brede tijdelijke toestaanregel kan de nieuwe tunnel gezond laten lijken terwijl hij stilletjes de autorisatiegrens wegneemt die de oude dienst afdwong, en niemand merkt het tot een audit. Vergelijk toestaan- en weigerresultaten naast elkaar, vanaf dezelfde client, in dezelfde sessie. Houd de oude dienst draaiend tot beide kolommen met het ontwerp overeenkomen.

Voordat u beheerderstoegang verplaatst, bevestigt u dat u een geautoriseerd herstelpad hebt dat niet afhangt van de tunnel die u wijzigt.

Stap 4: neem de oude identiteit uit dienst

De oude identiteit correct uit dienst nemen betekent verouderde gebruikers en apparaatreferenties intrekken via de dienst die ze bezit, en daarna oude profielen en luisteraars verwijderen zodra er geen afhankelijkheid meer is. Een lokaal bestand verwijderen trekt geen kopie elders in, en een oude luisteraar die nog steeds het oude gedeelde geheim accepteert, is een deur zonder toezicht.

Dat punt verdient het om even af te remmen. Een uit dienst genomen clientprofiel op een laptop is geen ingetrokken referentie; de referentie leeft op de server en blijft geldig tot de server hem niet meer accepteert. Zoek naar andere kopieën van de oude configuratie — testapparaten, een vergeten telefoon, een installatieprogramma dat iemand heeft bewaard — en beschouw het uitschakelen van de luisteraar als het moment waarop de oude dienst echt eindigt. Tot dan heeft de migratie twee voordeuren.

Het acceptatierecord is de inventaris uit stap één met een kolom erbij: wat het nieuwe ontwerp voor elke rij doet, en hoe u dat heeft geverifieerd. Dat maakt van een protocol-upgrade een dienstvereiste met bewijs.

Houd de uitkomst gekoppeld aan wat de dienst nodig heeft en niet aan de protocolnaam, want een modern protocol met de oude aannames erin gekopieerd is hetzelfde risico met een beter kader. RFC 3193 beschrijft hoe L2TP over IPsec wordt vervoerd, wat een nuttige herinnering is dat de twee lagen altijd afzonderlijke beslissingen waren. Als de inventaris een rij heeft die u niet kunt uitleggen, stop dan en zoek uit wat ervan afhangt. De migratie is klaar wanneer de lijst saai is.