Migracja z VPN opartego na PPP bez kopiowania jego założeń

Migracja VPN jest zakończona, gdy użytkownicy, cele, rozwiązywanie nazw i zachowanie przy awarii nadal są poprawne, a nie gdy nowy klient pokazuje zieloną ikonę. Stare wdrożenia oparte na PPP niosą założenia, których nigdy nie zapisano: wspólny sekret, który był też jedynym sprawdzianem tożsamości, stała pula adresów, którą zapora trzyma na liście dozwolonych, oraz sufiks DNS wysyłany przez serwer. Zastąpienie protokołu bez zinwentaryzowania tych założeń daje tunel, który wykonuje handshake, i granicę, która nie istnieje. Kolejność poniżej to ta, której używam, a ostatni krok to ten, który zespoły pomijają.

Krok 1: zinwentaryzuj, co zapewnia stare połączenie

Inwentarz się zapisuje, a nie pamięta. Zapisz obsługiwanych klientów, role uwierzytelniania, pule adresów, chronione sieci, wymagania DNS i uprawnienia do usług, których potrzebuje każda grupa użytkowników.

W przypadku L2TP/IPsec rozdziel jawnie obie warstwy. Tożsamość peera IPsec uwierzytelnia maszyny; PPP uwierzytelnia użytkownika, zwykle za pomocą CHAP lub MSCHAPv2.

Właśnie w tym rozdzieleniu stare wdrożenia ukrywają swoje założenia. Wspólny klucz wstępny, którego używa każdy klient, uwierzytelnia grupę, a nie urządzenie, i często jest to jedyna rzecz, którą kiedykolwiek wymieniono. Jeśli konto PPP jest rzeczywistą kontrolą na użytkownika, powiedz to, bo zamiennik musi odtworzyć tę kontrolę czymś, co nie jest współdzielonym ciągiem. Zapisz też stałe adresy źródłowe i wyjątki sieci lokalnej, bo to zależności, których nikt nie dokumentuje, dopóki się nie zepsują.

Krok 2: zaprojektuj zamiennik świadomie

Wybór zamiennika to mapowanie wymagania po wymaganiu: protokół i utrzymywany klient, które organizacja wspiera, a każde wymaganie tożsamości i dostępu trafia do rzeczywistego mechanizmu. Wspólny sekret nie jest automatycznie równy kluczowi lub certyfikatowi na urządzenie, a konto PPP na użytkownika nie jest równe certyfikatowi urządzenia.

Zakresy adresów uzgodnij przede wszystkim, bo pula zastępcza nachodząca na sieć domową lub biurową tworzy awarię, która nie ma nic wspólnego z siłą szyfru. Sprawdź pulę względem tej samej listy, którą zbudowałeś dla starej usługi, plus tego, co nowy klient zakłada domyślnie. Potwierdź routing powrotny dla sieci chronionych i potwierdź, że nowy klient potrafi wypchnąć lub udokumentować sufiks DNS, który wypychał stary. Te dwa punkty generują więcej zgłoszeń migracyjnych niż sama zmiana protokołu.

Krok 3: wdrażaj etapami i weryfikuj zarówno zezwolenie, jak i odmowę

Wdróż z jednym reprezentatywnym użytkownikiem i jedną reprezentatywną aplikacją. Uwzględnij w teście prywatne rozwiązywanie DNS, bo tunel, który dociera do adresu, ale nie potrafi rozwiązać nazwy wewnętrznej, jest tylko w połowie zmigrowany. Uwzględnij też oczekiwany stan niedostępności: co ma się stać, gdy tunel padnie, i czy klient to wymusza.

Następnie przetestuj cel, który ma pozostać zabroniony. Szeroka tymczasowa reguła zezwolenia może sprawić, że nowy tunel wygląda zdrowo, jednocześnie po cichu usuwając granicę autoryzacji, którą wymuszała stara usługa, i nikt tego nie zauważy do audytu. Porównaj wyniki zezwolenia i odmowy obok siebie, z tego samego klienta, w tej samej sesji. Utrzymuj starą usługę w działaniu, dopóki obie kolumny nie zgodzą się z projektem.

Zanim przeniesiesz dostęp administratora, potwierdź, że masz autoryzowaną ścieżkę odzyskiwania, która nie zależy od tunelu, który zmieniasz.

Krok 4: wycofaj starą tożsamość

Prawidłowe wycofanie starej tożsamości oznacza unieważnienie przestarzałych użytkowników i poświadczeń urządzeń przez usługę, która nimi zarządza, a następnie usunięcie starych profili i nasłuchów, gdy nie pozostaje żadna zależność. Usunięcie pliku lokalnego nie unieważnia kopii gdzie indziej, a stary nasłuch, który nadal akceptuje stary wspólny sekret, jest drzwiami bez nadzoru.

W tym miejscu warto zwolnić. Wycofany profil klienta na laptopie nie jest unieważnionym poświadczeniem; poświadczenie żyje na serwerze i pozostaje ważne, dopóki serwer nie przestanie go akceptować. Poszukaj innych kopii starej konfiguracji — urządzeń testowych, zapomnianego telefonu, instalatora, który ktoś zachował — i traktuj wyłączenie nasłuchu jako moment, w którym stara usługa naprawdę się kończy. Do tego czasu migracja ma dwoje przednich drzwi.

Zapis odbioru to inwentarz z pierwszego kroku z dodaną kolumną: co nowy projekt robi dla każdego wiersza i jak to zweryfikowałeś. To zamienia aktualizację protokołu w wymaganie usługi z dowodami.

Utrzymuj wynik powiązany z tym, czego potrzebuje usługa, a nie z nazwą protokołu, bo nowoczesny protokół z wkopiowanymi starymi założeniami to to samo ryzyko w lepszej ramie. RFC 3193 opisuje, jak L2TP jest przenoszony przez IPsec, co jest użytecznym przypomnieniem, że te dwie warstwy zawsze były osobnymi decyzjami. Jeśli inwentarz ma wiersz, którego nie potrafisz wyjaśnić, zatrzymaj się i ustal, co od niego zależy. Migracja jest skończona, gdy lista jest nudna.