Umieść bramę VPN obok Windows XP, a nie w nim

Gdzieś w budynku stoi maszyna uruchamiająca aplikację, której nikt nie może zastąpić, na systemie operacyjnym, którego nie należy podłączać do niczego. Wyjście od karty sieciowej tego hosta jest najszybszym sposobem, by zobaczyć, gdzie powinien być tunel. W większości projektów w ogóle nie należy on do hosta. Przenieś go o jeden krok dalej, na utrzymywaną bramę, a stary problem zmniejszy się z powrotem do aplikacji, od której się zaczął.

Zacznij od karty hosta, nie od klienta VPN

Otwórz właściwości karty i nadaj hostowi stały adres w małym dedykowanym segmencie, z bramą jako jego trasą domyślną. Host nie potrzebuje wtedy klienta tunelu, danych logowania tunelu ani wpisów tablicy routingu do szerszej sieci firmowej. Jeśli aplikacja potrzebuje jednej podsieci zdalnej, dodaj dokładnie tę jedną trasę.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

To polecenie przypina jeden cel do bramy i pozostawia wszystko inne bez trasy, i to jest kształt, którego chcesz. Potwierdź wynik za pomocą route print zamiast ufać kodowi wyjścia. Następnie sprawdź, czy aplikacja nadal rozwiązuje nazwę swojego serwera, bo stary host z zepsutym resolverem wygląda dokładnie jak awaria sieci, a naprawa resolvera to pięciominutowa praca, podczas gdy odbudowa aplikacji po błędnej zmianie sieci już nie. Każdy cel, do którego host nie dotrze, to o jedną rzecz mniej, do której można namówić stary stos sieciowy.

Umieść tunel na sprzęcie, który możesz aktualizować

Brama chce dwóch interfejsów: jednego w stronę segmentu hosta i jednego w stronę miejsca, gdzie żyje aplikacja, z tunelem kończącym się na drugim. To urządzenie może otrzymywać aktualizacje firmware, wymieniać konfigurację kryptograficzną i rejestrować przepływy, bez dotykania starej maszyny. Jego dostawca dostarcza także poprawki do implementacji tunelu, których host nigdy nie otrzyma. Dwie maszyny i termin nie są powodem, by kopiować przepis ze statycznym sekretem z postu na forum.

Nadaj każdej bramie własną tożsamość peera zamiast klonować jedną konfigurację klienta na całą flotę. Gdy urządzenie jest wymieniane, unieważnij starą tożsamość w tym samym momencie, w którym uruchamiasz nową, inaczej zostaną dwie niekontrolowane kopie uwierzytelniające się w tym samym punkcie końcowym. Przechowuj klucze tam, gdzie oczekuje ich płaszczyzna zarządzania bramy, traktuj kopię zapasową konfiguracji jako sekret i sprawdzaj, kto może tę konfigurację wysyłać, bo teraz to decyduje, do czego stary host może dotrzeć.

Zezwalaj na usługi, nie na sieci

Napisz politykę w kategoriach protokołu, portu i kierunku między dwoma połączeniami. Jeden dozwolony port do jednego adresu aplikacji to zwykła odpowiedź, a ścieżka administracyjna przez host skoku pokrywa resztę.

Zdalna administracja starego hosta nie powinna jechać na tej samej regule co aplikacja, a testowanie odmowy jest równie ważne jak pisanie reguły. Wyślij jedno żądanie z hosta do celu, który ma zostać odrzucony, i potwierdź, że odmowa pochodzi z polityki, a nie z brakującej trasy. Rejestruj przepływy, na które pozwalasz, dopóki projekt jest nowy, aby widzieć, czego aplikacja naprawdę używa, a nie co twierdzi jej dokumentacja. Łączenie dwóch podsieci, bo samouczek z mostem wyglądał na krótszy, to sposób, w jaki stary segment po cichu staje się odskocznią.

Nie wystawiaj starego nasłuchu bezpośrednio do internetu jako skrótu wokół bramy. Trzymaj ścieżkę administracyjną oddzielnie od ścieżki aplikacji, aby kompromitacja jednej nie oddawała drugiej. Reguła, która nigdy nie jest ćwiczą, jest regułą, której nikt nie zweryfikował, dlatego odrzucony cel należy do przebiegu akceptacyjnego.

Odtwarzanie musi działać bez tunelu

Zdecyduj, kto aktualizuje i odtwarza bramę przed pierwszym wyłączeniem, i upewnij się, że ta osoba dotrze do niej bez tunelu, który ona kończy. Dostęp konsolowy, lokalny port zarządzania lub ścieżka poza pasmem liczą się jako odpowiedzi. Brama, którą można skonfigurować tylko przez tunel, który zapewnia, jest pułapką cierpliwie czekającą na zły push firmware.

Napisz runbook dla awarii, z którą naprawdę się spotkasz: tunel padł, brama martwa, dysk hosta zniknął. Trzymaj obraz odtwarzania hosta w ramach dowolnej wciąż istniejącej umowy wsparcia i pamiętaj, że odtworzenie przywraca także stan oprogramowania i dane uwierzytelniające w tym obrazie. Najpierw odtwórz na izolowanym segmencie, potwierdź, że aplikacja startuje, i dopiero potem podłącz cokolwiek ponownie; gdy brama się zmieni, zaktualizuj runbook i inwentarz w tej samej sesji.

Certyfikaty, zegary i ostrzeżenia o podpisie

Wygasnięcie certyfikatu instalatora samo w sobie nie przewiduje, co dzisiaj powie kontrola podpisu. Wskazówki Microsoftu dotyczące znaczników czasu Authenticode wyjaśniają, że znacznik czasu może utrzymać podpis weryfikowalny po wygaśnięciu certyfikatu podpisywania, a walidacja nadal zależy od podpisu, łańcucha zaufania i weryfikatora wykonującego pracę. Dwie maszyny z różnymi magazynami zaufania mogą więc nie zgadzać się co do tego samego pliku. Wygasły podpisujący nie jest dowodem, że plik binarny jest złośliwy, a ważny podpis nie jest dowodem, że oprogramowanie jest utrzymywane.

Nie cofaj zegara systemowego i nie wyłączaj kontroli podpisu, aby uruchomić stary instalator. Uzyskaj autoryzowany artefakt od tego, kto nadal wspiera aplikację, i pozwól im powiedzieć, co akceptuje platforma. Traktuj posty twierdzące, że dany build był ostatnim dla XP, jako historię, a nie cel instalacji, bo rzeczywiste wymaganie zależy od aplikacji; jeśli prace konserwatorskie są naprawdę potrzebne, trzymaj je na izolowanym segmencie z dala od dostępu produkcyjnego i dokumentuj, dlaczego istnieją.