Przeniesienie maszyny z VPN do warsztatu bez jej utraty
Numer seryjny w adresie nie tworzy podsieci. Trzymaj tożsamość w inwentarzu, daj warsztatowi własny segment i przenieś własność trasy jako krok pracy.
Maszyna opuszcza siedzibę klienta, trafia do warsztatu i zachowuje tę samą tożsamość zasobu, choć jej położenie w sieci zmienia się całkowicie. Ile planowania wymaga ten ruch, decydują trzy warunki. Czy klient ponownie używa adresów, których i ty używasz wewnętrznie, czy segment warsztatu jest odizolowany od sieci personelu i czy starą ścieżkę można wyciszyć, a nie tylko przebić priorytetem. Pomylisz pierwszy i będziesz debugować maszynę, która jest sprawna.
Tożsamość to nie adres
Inwentarz i nazewnictwo powinny nieść zasób, klienta i zadanie. Adres niesie to, gdzie maszyna jest teraz podłączona, a to fakt, który zmienia się przy przenoszeniu. Mieszanie obu daje klasyczny błąd odczytywania znaczenia z cyfr.
Numer seryjny zakodowany w ostatnim oktecie wygląda schludnie i niczego nie dowodzi routerowi. Długości prefiksów decydują, co host uważa za lokalne, i żadna ilość zapadającej w pamięć numeracji nie zmieni tej arytmetyki.
Jeśli chcesz, by adres sugerował klienta, to konwencja, a konwencje są w porządku, dopóki nikt nie buduje na nich polityki. Szukaj zasobu w inwentarzu, nie adresu, a przeprowadzka do warsztatu przestaje być polowaniem na skarb. Przetrwa też przenumerowanie, które prędzej czy później dotrze do każdej lokalizacji.
Numer seryjny to nie długość prefiksu
Urządzenia używające szerokiej maski, takiej jak 10.0.0.0/8, będą traktować każdy adres w tym zakresie jako podłączony bezpośrednio, więc ruch do maszyny klienta oddalonej o dwie sieci nigdy nie dotrze do routera. Maszyna po prostu rozgłasza pytanie do sąsiada, który nie może odpowiedzieć.
RFC 4632 definiuje prefiksy według długości, a nie według tego, co sugerują liczby z kropkami. Twój plan potrzebuje jawnych długości dla każdej grupy podłączenia: segmentu usług, kontekstu klienta, stołu warsztatowego. Nazwanie tych grup najpierw czyni długości oczywistymi.
Praktyczna zasada to zaprojektować najmniejszy prefiks obejmujący jedną grupę podłączenia i używać go wszędzie w tej grupie. Tekst adresu jest dla ludzi; maska jest tym, na czym działa jądro.
Gdy dwóch klientów używa tych samych adresów
Klient A i klient B mogą obaj używać 192.168.10.0/24 i obaj będą mieli rację w swoich budynkach. To nie jest problem, który rozwiązuje się przenumerowaniem cudzego zakładu.
Trzymaj konteksty osobno albo zapewnij celowe aliasy przez projekt, który dokumentuje, który adres należy do którego klienta w którym momencie. Globalny inwentarz to właściwe narzędzie do rozróżniania maszyn; nie jest dowodem, że adresy są globalnie unikalne. Ścieżka aliasów wymaga pisemnej zasady wygaśnięcia, inaczej przeżyje pracę, która ją stworzyła.
Czego trzeba unikać, to jednoczesnej dostępności obu kontekstów bez żadnego znacznika. Dwa identyczne adresy na dwóch żywych ścieżkach to tryb awarii, który wysyła aktualizację firmware do złej maszyny. Objaw rzadko wygląda jak błąd; wygląda jak urządzenie, które ktoś inny przekonfigurował. Najpierw znacznik, potem osiągalność.
Daj warsztatowi własną granicę
Sprzęt klienta przybywający do serwisu należy do segmentu usług z wyraźnie dozwolonym dostępem, a nie do sieci personelu tylko dlatego, że port na stole był wolny.
Traktuj nieznane urządzenie przemysłowe jak inną domenę zaufania. Zapisz, który host inżynierski może do niego dotrzeć, jakich usług ten host potrzebuje i jakie dane logowania należą do zadania. Trzymaj pliki klienta razem z zadaniem klienta, a nie na współdzielonym dysku, który każdy może czytać.
Izolacja musi przetrwać także nudny środek zadania: podczas aktualizacji, przez noc i podczas oczekiwania na kuriera.
Przekaż trasę jako krok pracy
Zwykle centralny router dociera do maszyny przez tunel klienta. Gdy maszyna stoi na stole, ścieżka warsztatu staje się właścicielem tego prefiksu lub węższego celu, jeśli potrzebujesz tylko jednej usługi.
Zapisz trzy rzeczy przed przeniesieniem: starą ścieżkę, nową ścieżkę i sposób odwrócenia zmiany. Przekazanie, które istnieje tylko w czyjejś pamięci, nie jest przekazaniem.
Uważaj z metrykami. Niższa metryka ma znaczenie tylko wśród tras, które proces wyboru naprawdę porównuje, a bardziej szczegółowy prefiks lub reguła polityki mogą rozstrzygnąć wynik, zanim metryki w ogóle zostaną sprawdzone.
Uwzględnij w planie nieaktualne sesje. Połączenie nawiązane starą ścieżką może nadal dostarczać polecenia po zmianie trasy, i to jest dokładnie ta sytuacja, w której dwie kopie jednego adresu wyrządzają realną szkodę. Zamknij starą ścieżkę jawnie, zamiast czekać na jej wygaśnięcie.
Zamknij pętlę, gdy maszyna zostanie wysłana
Przywróć zamierzoną trasę zdalną, usuń tymczasowe uprawnienia i potwierdź zasób w punkcie końcowym, który uważasz za wybrany. Następnie zweryfikuj od strony klienta, a nie tylko z warsztatu.
Rozwiązywanie nazw i inwentarz wykonują tu pracę zwróconą ku operatorowi: stabilna nazwa i przeszukiwalny rekord zasobu czynią zadanie przewidywalnym, podczas gdy plan sieci pozostaje uczciwy co do tego, gdzie maszyna jest dziś.
Testem dobrego przekazania jest to, że kolega, który nigdy nie widział zadania, potrafi przeczytać twoje notatki i odpowiedzieć na jedno pytanie: jeśli ta maszyna teraz odpowiada, którą ścieżką przyszła odpowiedź? Jeśli notatki nie potrafią na to odpowiedzieć, przekazanie jest udokumentowane, ale nieukończone.