Átállás PPP-alapú VPN-ről a feltevéseinek másolása nélkül

Egy VPN-átállás akkor kész, amikor a felhasználók, a célok, a névfeloldás és a hiba esetén mutatott viselkedés továbbra is helyes, nem akkor, amikor az új kliens zöld ikont mutat. A régi PPP-alapú telepítések soha le nem írt feltevéseket hordoznak: egy közös titkot, amely egyben az egyetlen identitásellenőrzés volt, egy fix címtartományt, amelyet a tűzfal az engedélyezési listán tart, egy DNS-utótagot, amelyet a kiszolgáló küld. A protokoll lecserélése e feltevések leltározása nélkül olyan alagutat ad, amely végrehajtja a kézfogást, és olyan határt, amely nem létezik. Az alábbi sorrend az, amelyet én használok, és az utolsó lépés az, amelyet a csapatok kihagynak.

1. lépés: leltározza, mit nyújt a régi kapcsolat

A leltárt írni kell, nem megjegyezni. Rögzítse a támogatott klienseket, a hitelesítési szerepköröket, a címtartományokat, a védett hálózatokat, a DNS-követelményeket és a szolgáltatási engedélyeket, amelyekre az egyes felhasználói csoportoknak szükségük van.

A L2TP/IPsec esetében kifejezetten válassza szét a két réteget. Az IPsec-partner identitása a gépeket hitelesíti; a PPP a felhasználót hitelesíti, általában CHAP vagy MSCHAPv2 segítségével.

Pont ebben a szétválasztásban rejtik el a régi telepítések a feltevéseiket. Egy előre megosztott kulcs, amelyet minden kliens használ, egy csoportot hitelesít és nem egy eszközt, és gyakran ez az egyetlen dolog, amelyet valaha cseréltek. Ha a PPP-fiók az igazi felhasználónkénti vezérlés, mondja ki, mert a helyettesítésnek azt a vezérlést olyasmivel kell újrateremtenie, ami nem közös karaktersorozat. Jegyezze fel a fix forráscímeket és a helyi hálózati kivételeket is, mert ezek azok a függőségek, amelyeket senki nem dokumentál, amíg el nem törnek.

2. lépés: tervezze meg szándékosan a helyettesítést

A helyettesítés kiválasztása követelmény-követelmény leképezés: egy protokoll és egy karbantartott kliens, amelyet a szervezet támogat, és minden identitás- és hozzáférési követelmény valódi mechanizmusba kerül. A közös titok nem automatikusan egyenlő az eszközönkénti kulccsal vagy tanúsítvánnyal, és a felhasználónkénti PPP-fiók nem egyenlő az eszköztanúsítvánnyal.

Mindenek előtt hangolja össze a címtereket, mert az otthoni vagy irodai LAN-nal átfedő helyettesítő tartomány olyan hibát okoz, amelynek semmi köze a titkosítás erősségéhez. Ellenőrizze a tartományt ugyanazon lista ellen, amelyet a régi szolgáltatáshoz készített, plusz amit az új kliens alapértelmezés szerint feltételez. Erősítse meg a védett hálózatok visszaútvonalazását, és erősítse meg, hogy az új kliens képes küldeni vagy dokumentálni azt a DNS-utótagot, amelyet a régi küldött. Ez a két pont több átállási jegyet okoz, mint maga a protokollcsere.

3. lépés: vezesse be fokozatosan, és ellenőrizze az engedélyezést és a tiltást is

Egy reprezentatív felhasználóval és egy reprezentatív alkalmazással vezesse be. A tesztbe vegye bele a privát DNS-feloldást, mert az az alagút, amely elér egy címet, de nem tud feloldani egy belső nevet, csak félig van átállítva. Vegye bele a várt elérhetetlen állapotot is: mi történjen, ha az alagút megszakad, és kikényszeríti-e ezt a kliens.

Ezután teszteljen egy célt, amelynek tiltottnak kell maradnia. Egy széles ideiglenes engedélyezési szabály egészségesnek mutathatja az új alagutat, miközben csendben eltávolítja azt a felhatalmazási határt, amelyet a régi szolgáltatás érvényesített, és ezt senki nem veszi észre egy auditig. Hasonlítsa össze az engedélyezési és tiltási eredményeket egymás mellett, ugyanattól a klienstől, ugyanabban a munkamenetben. Tartsa működésben a régi szolgáltatást, amíg mindkét oszlop meg nem felel a tervnek.

Mielőtt áthelyezi az adminisztrátori hozzáférést, erősítse meg, hogy van olyan engedélyezett helyreállítási útvonala, amely nem függ az átalakított alagúttól.

4. lépés: vonja ki a régi identitást

A régi identitás helyes kivonása azt jelenti, hogy az elavult felhasználókat és eszközhitelesítő adatokat a tulajdonos szolgáltatáson keresztül visszavonjuk, majd eltávolítjuk a régi profilokat és figyelőket, amikor már nincs függőség. Egy helyi fájl törlése nem vonja vissza a máshol lévő másolatot, és az a régi figyelő, amely még elfogadja a régi közös titkot, megfigyelés nélküli ajtó.

Érdemes lassítani ennél a pontnál. Egy leszerelt ügyfélprofil a laptopon nem visszavont hitelesítő adat; a hitelesítő adat a kiszolgálón él, és érvényes marad, amíg a kiszolgáló el nem kezdi elutasítani. Keressen másolatokat a régi konfigurációból — teszteszközök, egy elfelejtett telefon, egy megőrzött telepítő —, és tekintse a figyelő leállítását arra a pillanatra, amikor a régi szolgáltatás valóban véget ér. Addig az átállásnak két előajtaja van.

Az átvételi jegyzőkönyv az első lépés leltára egy hozzáadott oszloppal: mit tesz az új terv minden sorért, és hogyan ellenőrizte. Ez a protokollfrissítést bizonyítékokkal ellátott szolgáltatási követelménnyé alakítja.

Tartsa az eredményt a szolgáltatás igényeihez kötve, ne a protokoll nevéhez, mert egy modern protokoll a bele másolt régi feltevésekkel ugyanaz a kockázat jobb kerettel. A RFC 3193 leírja, hogyan szállítják az L2TP-t IPsec felett, ami hasznos emlékeztető arra, hogy a két réteg mindig külön döntés volt. Ha a leltárban van olyan sor, amelyet nem tud megmagyarázni, álljon meg, és derítse ki, mi függ tőle. Az átállás akkor kész, amikor a lista unalmas.