Kieruj podsieć oddziału przez wyjście internetowe SonicWall w centrali

Telefony oddziału powinny wychodzić przez centralę, podczas gdy laptopy oddziału nadal korzystają z lokalnego WAN, a sama polityka routingu tego nie zapewni. Trasa oddziału może wybrać tunel, ale polityka tunelu musi zaakceptować ruch, centrala musi go przekazać i przetłumaczyć, a odpowiedź musi wrócić tą samą drogą. Pomiń którykolwiek z tych trzech i objawem będzie podzbiór klientów, którzy tracą internet dokładnie wtedy, gdy tunel jest aktywny.

Zacznij od selektora, nie od trasy

Polityka routingu dopasowuje po źródle, więc źródło musi być stabilne przed wszystkim innym. Umieść wybrane urządzenia w grupie adresów utrzymywanej przez administratora lub, lepiej, w dedykowanym segmencie, którego członkostwo podąża za rolą urządzenia. Gdy zwykła rotacja DHCP może przenieść dopasowany adres na inną maszynę, polityka po cichu wybiera złego klienta, a pierwsze zgłoszenie dotyczy zwykle wolnego przeglądania, które w rzeczywistości jest objazdem.

Nazwij grupę według polityki, której służy, a nie według piętra lub działu, ponieważ reguła routingu przetrwa oba. Zapisz, które urządzenia są w niej i kto może dodać jedno.

Dodaj politykę oddziału, a następnie broń jej kolejności

Na SonicWall oddziału polityka trasy wybiera grupę źródeł, nazywa zamierzone miejsca docelowe i ustawia interfejs tunelu jako bramę, i właśnie do tego istnieje obsługiwany projekt interfejsu tunelu. Utrzymuj reguły dla miejsc lokalnych i prywatnych powyżej szerokiej reguły internetowej, ponieważ pierwsze dopasowanie wygrywa, a prywatny prefiks wepchnięty do tunelu dociera do centrali tylko po to, by zostać odrzuconym. Zachowaj także własną trasę zapory do jej partnera VPN, w przeciwnym razie transport tunelu pójdzie według polityki, od której zależy. Nic z tego nie zmusza cię do konwersji każdego istniejącego tunelu opartego na polityce; interfejs tunelu jest jednym z kilku obsługiwanych wyborów.

Kolejność to część, która zmienia się przez przypadek. Każdy, kto dodaje wyjątek, musi wstawić go powyżej szerokiej reguły, a każdy, kto edytuje szeroką regułę, może odwrócić cały projekt jednym zapisem. Zapisz zamierzoną kolejność obok polityki i sprawdź ją ponownie po aktualizacjach oprogramowania układowego, ponieważ nazewnictwo interfejsów i renderowanie polityk naprawdę zmieniają się między wydaniami.

Dokończ ścieżkę w centrali

Polityka tunelu w centrali musi zaakceptować ruch, który teraz wybiera trasa oddziału. Selektor międzybiuszowy ograniczony do prywatnej sieci LAN centrali nie jest pozwoleniem na przenoszenie dowolnych publicznych miejsc docelowych, więc polityka potrzebuje źródła oddziału i zakresu miejsc docelowych, który naprawdę masz na myśli. Centrala przekazuje następnie ten przychodzący ruch do swojego łącza internetowego według własnych reguł dostępu, a przykład centralnego wyjścia SonicWall obejmuje tłumaczenie źródła dla sieci zdalnej w centralnym WAN. Bez tego tłumaczenia zdalna strona widzi prywatny adres oddziału i nie ma trasy powrotnej.

Odpowiedzi to druga połowa umowy. Muszą wracać przez tunel lub przez utworzone dla nich tłumaczenie stanowe, a ruch do witryn prywatnych może wymagać innego traktowania NAT niż wyjście publiczne. Utrzymuj te reguły rozróżnialne, ponieważ jedna szeroka reguła tłumaczenia, która ukrywa każde wewnętrzne źródło, znacznie utrudnia czytanie późniejszego rejestrowania i rozwiązywania problemów.

Zdecyduj, co grupa robi, gdy tunel padnie

Jeśli centralne wyjście jest wymogiem, a nie preferencją, powrót do lokalnego WAN jest naruszeniem zgodności, nawet jeśli użytkownicy pozostają online. SonicOS dokumentuje trasę z odrzuceniem interfejsu tunelu jako obsługiwany sposób powstrzymania wybranego ruchu przed wejściem na niepożądaną trasę alternatywną.

Dopasuj zakres i priorytet tej trasy do zainstalowanego wydania i przetestuj ją, wyłączając tunel, zamiast ufać etykiecie. Grupa, która nigdy nie powinna wychodzić lokalnie, powinna zawieść zamknięta, podczas gdy grupa, w której dostępność jest ważniejsza, może legalnie wrócić; oba są decyzjami i żadna nie powinna zdarzyć się domyślnie.

Sprawdź z trzech klientów, a następnie czysto wycofaj

Ping do centralnej bramy testuje niewłaściwą rzecz, ponieważ pochodzi z zapory, a nie z wybranego klienta. Testuj z urządzeń i przetestuj trzy z nich: wybrane urządzenie, zwykłe urządzenie, które powinno pozostać lokalne, oraz jedno zależne od usług lokalnych.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Porównaj, gdzie publiczne żądanie faktycznie się pojawiło. Wybrany klient powinien dotrzeć do internetu przez wyjście centrali, a zwykły klient powinien nadal prezentować własny adres oddziału po drugiej stronie; 203.0.113.10 to adres dokumentacyjny używany jako zamiennik docelowego miejsca, na którym ci zależy. Uwzględnij DNS w tym samym przebiegu, ponieważ klient pytający resolver oddziału może wygenerować zapytanie pochodzące z routera z innym źródłem i tym samym inną trasą.

Wycofanie to zapisana kolejność polityk plus grupa adresów. Przywróć poprzednią kolejność, usuń grupę z polityki i ponownie przetestuj obie klasy urządzeń. Zachowaj wyeksportowaną konfigurację wraz z zapisem zmian, ponieważ następny inżynier musi wiedzieć, która reguła była szeroka, zanim ktoś ją edytował.