Domowe laboratorium i dzielony tunel: kieruj tylko to, czego potrzebujesz

Rada, że domowe laboratorium potrzebuje pełnego tunelu, zwykle pochodzi z poradnika, który go miał, a nie z wymagania. Dzielony tunel nie jest kompromisową wersją porządnego VPN; to wersja, której tablicę tras potrafisz wyjaśnić. Laboratorium z pięcioma usługami i interfejsem zarządzania nie potrzebuje, aby każdy pakiet opuszczający dom przechodził przez tunel. Potrzebuje inwentaryzacji i trasy dla każdego elementu tej inwentaryzacji.

Mit: dzielony tunel to kompromis

Mit trwa, bo pełny tunel łatwiej skonfigurować raz, a trudniej później debugować. Ta wymiana jest rozsądna dla laptopa w publicznym Wi-Fi i błędna dla szafy w piwnicy.

Ukrywa też drugie założenie: adresacja laboratorium nie ma nic wspólnego z siecią, z której się łączysz.

Zinwentaryzuj zasoby przed trasami

Zapisz każdą podsieć laboratorium, usługę, która tam mieszka, nazwę, po której ją rozwiązujesz, i to, kto może się do niej dostać; notatki o przekazywaniu dla twojej bramy opisują drogę powrotną, pod którą planujesz. Dodaj zakresy kontenerów i zakresy LAN, których zdalny klient może już używać, bo nakładanie się to awaria, której ta inwentaryzacja zapobiega. Trasa obejmująca każdy prywatny adres prędzej czy później zderzy się z siecią domową. Inwentaryzacja jest też planem testów, dlatego warto ją zrobić przed konfiguracją, a nie po niej.

Przypisz każdemu zasobowi ścieżkę: przez tunel, bezpośrednio lub zabronioną. Zasób bez przypisanej ścieżki to ten, który później tworzy zagmatwane pytanie do pomocy technicznej.

Pięć wierszy i kolumna decyzji bije tablicę tras, której nikt nie potrafi odczytać.

Brama potrzebuje drogi powrotnej

Przekazywanie na bramie to tylko połowa. Laboratorium potrzebuje trasy powrotnej do puli klientów albo obsługiwanego układu tłumaczenia, który umożliwia powrót. Jeśli odpowiedzi nie mogą znaleźć klienta, tunel wygląda na połączony, a każde żądanie kończy się przekroczeniem czasu; to objaw routingu, a nie awaria VPN. Sprawdzaj drogę powrotną jako część projektu, a nie krok rozwiązywania problemów.

Pula klientów nakładająca się na własną adresację laboratorium to druga połowa tego problemu i zawodzi dokładnie w ten sam sposób.

Napraw plan, a nie objawy, gdy dwa zakresy kolidują.

Role zarządzania i internetu są rozdzielone

Zdecyduj, czy tunelu używa tylko ruch laboratorium, czy staje się on także wyjściem do internetu. Nie dodawaj trasy domyślnej tylko dlatego, że poradnik jej użył, bo ta decyzja zmienia, dokąd trafia każde zapytanie DNS i każde sprawdzenie aktualizacji. Zachowaj zewnętrzną trasę do samego punktu końcowego VPN, inaczej tunel spróbuje nieść własne połączenie zewnętrzne. Utrzymuj dostęp zarządzania wąski i osiągalny przez zatwierdzoną metodę odzyskiwania.

Prywatny DNS można wybrać dla nazw laboratorium bez zakładania, że każde publiczne zapytanie potrzebuje tego samego resolvera. To decyzja o resolverze, nie decyzja o trasie.

To, że są rozdzielone, sprawia, że tryby awarii są później rozróżnialne.

Testuj z zewnątrz, nie z LAN

Użyj zewnętrznego autoryzowanego połączenia zamiast testu z tego samego LAN, bo test z tego samego LAN może całkowicie ukryć brakującą trasę powrotną. Sprawdź adres laboratoryjny, jego prywatną nazwę hosta, zamierzony cel bezpośredni i wymagane zachowanie przy awarii. Przypadek awarii jest tak samo ważny jak przypadek sukcesu: zasób, do którego nie powinno być dostępu, musi naprawdę być nieosiągalny. Zapisz wszystkie cztery wyniki, zanim uznasz projekt za skończony.

Potem zapisz konfigurację tras i DNS obok inwentaryzacji, z nazwanym właścicielem. Gdy laboratorium zyska kolejną podsieć, zaktualizuj oba i przetestuj ponownie.

Niewyjaśniona trasa nakładająca się na istniejącą sieć domową to domyślny wynik pominięcia tego kroku.

Skończony projekt jest mały, udokumentowany i nudny, i dokładnie tego laboratorium chce od swojej sieci. Ciekawa wersja to ta, która psuje się, gdy jesteś poza domem.