Migrace z VPN postavené na PPP bez převzetí jejích předpokladů

Migrace VPN je hotová, když jsou uživatelé, cíle, překlad jmen i chování při výpadku stále správné, ne když nový klient zobrazí zelenou ikonu. Stará nasazení na bázi PPP nesou předpoklady, které nikdy nebyly zapsané: sdílené tajemství, které sloužilo jako jediná kontrola identity, pevný adresní fond, který firewall má na seznamu povolených, DNS sufix, který posílá server. Nahrazení protokolu bez inventarizace těchto předpokladů vytvoří tunel, který dokončí handshake, a hranici, která neexistuje. Postup níže je pořadí, které používám já, a poslední krok je ten, který týmy přeskakují.

Krok 1: zinventarizujte, co staré spojení poskytuje

Inventář se píše, ne pamatuje. Zapište podporované klienty, role autentizace, adresní fondy, chráněné sítě, požadavky na DNS a oprávnění ke službám, která každá skupina uživatelů potřebuje.

U L2TP/IPsec obě vrstvy výslovně oddělte. Identita IPsec protějšku autentizuje stroje; PPP autentizuje uživatele, obvykle pomocí CHAP nebo MSCHAPv2.

Právě v tomto oddělení stará nasazení skrývají své předpoklady. Sdílený předsdílený klíč, který používá každý klient, autentizuje skupinu, nikoli zařízení, a často je to jediná věc, která se kdy rotovala. Pokud je PPP účet skutečnou kontrolou na uživatele, řekněte to, protože náhrada musí tuto kontrolu reprodukovat něčím, co není sdílený řetězec. Zapište také pevné zdrojové adresy a výjimky pro místní síť, protože to jsou závislosti, které nikdo nedokumentuje, dokud se nerozbijí.

Krok 2: navrhněte náhradu záměrně

Volba náhrady je mapování požadavek za požadavkem: protokol a udržovaný klient, které organizace podporuje, přičemž každý požadavek na identitu a přístup dopadá na skutečný mechanismus. Sdílené tajemství není automaticky ekvivalentní klíči či certifikátu pro zařízení a PPP účet pro uživatele není ekvivalentní certifikátu zařízení.

Adresní rozsahy sladit především ostatním, protože náhradní fond, který se překrývá s domácí nebo kancelářskou LAN, vytváří selhání, které nemá nic společného se silou šifry. Zkontrolujte fond proti stejnému seznamu, který jste sestavili pro starou službu, plus to, co nový klient předpokládá ve výchozím nastavení. Potvrďte zpětnou směrování pro chráněné sítě a potvrďte, že nový klient umí posílat nebo dokumentovat DNS sufix, který posílal starý. Tyto dvě položky způsobují více migračních tiketů než samotná změna protokolu.

Krok 3: zaveďte po etapách a ověřte povolení i odmítnutí

Zaveďte s jedním reprezentativním uživatelem a jednou reprezentativní aplikací. Do testu zahrňte překlad soukromých jmen přes DNS, protože tunel, který dosáhne adresy, ale nedokáže přeložit interní jméno, je migrovaný jen napůl. Zahrňte i očekávaný stav nedostupnosti: co se má stát, když tunel spadne, a zda to klient vynucuje.

Pak otestujte cíl, který má zůstat odmítnutý. Široké dočasné pravidlo povolení může nový tunel vypadat zdravě, zatímco tiše odstraňuje autorizační hranici, kterou stará služba vynucovala, a nikdo si toho nevšimne do auditu. Porovnejte výsledky povolení a odmítnutí vedle sebe, ze stejného klienta, ve stejné relaci. Nechte starou službu běžet, dokud se oba sloupce neshodují s návrhem.

Než přesunete přístup správce, potvrďte, že máte autorizovanou cestu obnovy, která nezávisí na tunelu, který měníte.

Krok 4: vyřaďte starou identitu

Správné vyřazení staré identity znamená zrušit zastaralé uživatele a přihlašovací údaje zařízení prostřednictvím služby, která je vlastní, a poté odstranit staré profily a posluchače, jakmile nezůstane žádná závislost. Smazání místního souboru nezruší kopii jinde a starý posluchač, který stále přijímá staré sdílené tajemství, jsou nedohledaná vrata.

Tento bod stojí za zpomalení. Vyřazený klientský profil na notebooku není zrušený přihlašovací údaj; údaj žije na serveru a zůstává platný, dokud jej server přestane přijímat. Hledejte další kopie staré konfigurace — testovací zařízení, zapomenutý telefon, instalátor, který si někdo nechal — a vypnutí posluchače berte jako okamžik, kdy stará služba skutečně končí. Do té doby má migrace dvoje přední dveře.

Záznam o převzetí je inventář z prvního kroku s přidaným sloupcem: co nový návrh dělá pro každý řádek a jak jste to ověřili. Tím se z upgradu protokolu stává požadavek na službu s důkazy.

Držte výsledek svázaný s tím, co služba potřebuje, ne s názvem protokolu, protože moderní protokol s opsanými starými předpoklady je stejné riziko s lepším rámcem. RFC 3193 popisuje, jak se L2TP přenáší přes IPsec, což je užitečná připomínka, že ty dvě vrstvy byly vždy samostatná rozhodnutí. Pokud má inventář řádek, který nedokážete vysvětlit, zastavte se a zjistěte, co na něm závisí. Migrace je hotová, když je seznam nudný.