Który tryb Sophos RED pasuje do Twojej sieci oddziału?
RED to rola zdalnej lokalizacji, a nie protokół. Wybierz Standard/Unified, Standard/Split lub Transparent/Split zależnie od tego, kto posiada bramę oddziału i DHCP.
Sophos RED to rola zdalnej lokalizacji, a nie protokół VPN, dlatego porównanie z IPsec lub OpenVPN odpowiada na niewłaściwe pytanie. Urządzenie rozciąga kontrolę centralnej zapory na oddział, a wybrany tryb decyduje, kto dostarcza bramę oddziału, kto przydziela adresy i jaki ruch przechodzi przez tunel. Te trzy odpowiedzi ważą więcej niż nazwy trybów. Zapisanie ich najpierw zamienia wybór produktu w decyzję projektową.
RED to rola, nie protokół
Urządzenie RED przyłącza oddział do centralnej Sophos Firewall, a konfiguracja zapory określa, czym oddział się staje. Tunel jest szczegółem implementacji tego przyłączenia, a nie uniwersalnym punktem końcowym VPN, który można skierować do dowolnego partnera.
To ujęcie ma znaczenie, ponieważ RED nie jest wymienny z dowolnym partnerem IPsec. Oczekuje, że zarządzać nim będzie centralna zapora, a obsługiwane tryby opisują, jaką część oddziału przejmuje. Traktowanie go jak zwykłego punktu końcowego tunelu tworzy oczekiwania, których produkt nigdy nie obiecał. Traktowanie go jak roli daje pytania, które naprawdę decydują o projekcie.
Trzy poniższe warunki zmieniają odpowiedź i wszystkie dotyczą własności, a nie szyfrowania.
Trzy warunki, które wybierają tryb
Zapytaj, kto posiada bramę oddziału, kto prowadzi DHCP i DNS dla klientów oddziału i czy lokalne wyjście do internetu musi przetrwać awarię tunelu.
Standard/Unified odpowiada na wszystkie trzy tak samo: centralna zapora posiada sieć LAN oddziału, w tym zadania bramy i DHCP, a ruch przechodzi przez tunel. Standard/Split zachowuje centralne zarządzanie i wysyła tunelem tylko skonfigurowane sieci. Transparent/Split pozostawia istniejącej sieci oddziału zarządzanie własną bramą i adresami, a do tunelu przekierowuje tylko wybrany ruch. Trzy tryby, trzech różnych właścicieli.
| Mode | Branch gateway and DHCP | Traffic through the tunnel |
|---|---|---|
| Standard/Unified | Central firewall owns both | All branch traffic |
| Standard/Split | Central firewall owns both | Only the configured networks |
| Transparent/Split | The existing branch router keeps both | Only the selected flows |
Najpierw przeczytaj środkową kolumnę, bo ona decyduje, jaka część oddziału jeszcze działa, gdy tunelu nie ma.
Kto posiada bramę oddziału i DHCP
W układzie zunifikowanym oddział nie ma samodzielnej bramy, co upraszcza konfigurację i koncentruje awarię. Ta koncentracja jest w porządku, gdy oddział jest mały, a centralna zapora ma wysoką dostępność.
We wdrożeniu przezroczystym oddział zachowuje własny router, a RED stoi w ścieżce, aby przekierowywać wybrany ruch. To zachowuje lokalną kontrolę i dodaje urządzenie, którego pozycja w ścieżce ma teraz znaczenie dla każdego przekierowanego przepływu. Udokumentuj, gdzie stoi, bo późniejsza zmiana routera oddziału może je po cichu ominąć. Żaden układ nie wygrywa ogólnie; rozdzielają odpowiedzialność inaczej.
Własność adresów to część, którą trzeba zapisać, bo dwa serwery DHCP w jednym segmencie powodują sporadyczne usterki zgłaszane jako problemy z VPN.
Co się dzieje, gdy tunel padnie
Praca w trybie Split bywa czytana jako obietnica, że lokalny internet działa dalej podczas awarii tunelu, a ta lektura nie jest bezpieczna. Dokładne zachowanie zależy od wybranego trybu, firmware'u i urządzenia, więc należy do kryteriów odbioru, a nie do założenia.
Zdecyduj, co oddział musi jeszcze robić bez tunelu: docierać do lokalnych drukarek, rozwiązywać nazwy, przyjmować płatności albo nic. Potem sprawdź ten stan celowo, blokując tunel i obserwując oddział. Oddział, który po cichu traci DNS, jest gorszy niż taki, który głośno zawodzi, bo zgłoszenie do pomocy technicznej przychodzi godziny później. Zapisz zaobserwowany wynik w notatce projektowej.
Zależność centralna jest taka sama w każdym trybie: ktoś musi posiadać ścieżkę odzyskiwania samego urządzenia.
Zapisz umowę oddziału, zanim wdrożysz
Umowa oddziału mieści się na jednej stronie: właściciele, źródła adresów, prefiksy tunelowane, polityka wyjścia i zaakceptowane zachowanie przy awarii.
Następnie sprawdź wynik wdrożony, a nie zamierzony. Sprawdź adres klienta oddziału, jego bramę domyślną, które prefiksy są rozwiązywane przez tunel i co jeszcze odpowiada, gdy tunel jest zablokowany. Zgodność, osiągalność i licencjonowanie trzeba zweryfikować z aktualną dokumentacją dostawcy dla dokładnego modelu, bo nazwa produktu nie gwarantuje trybu. Trzymaj tę stronę razem z kartą urządzenia, aby następny inżynier odziedziczył decyzje, a nie schemat.
ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.example
Powtórz ten blok z zablokowanym tunelem, a różnica między dwoma uruchomieniami to zachowanie przy awarii, które naprawdę kupiłeś.