Kierowanie Internetu oddziału przez centralę za pomocą IPsec

Jeśli ruch internetowy oddziału ma być centralnie kontrolowany i wychodzić przez łącze WAN centrali, Sophos Firewall może użyć tunelu Site-to-Site IPsec policy-based. Klienci oddziału wysyłają wtedy ruch tunelem zamiast bezpośrednio do lokalnego WAN. W centrali działają centralne reguły firewalla, NAT i zabezpieczeń.

LAN oddziału → Firewall oddziału → IPsec policy-based → Centrala → MASQ → Internet

Ten projekt wymaga więcej niż zielonego tunelu VPN. Route Precedence, Traffic Selectors, kolejność reguł i droga powrotna muszą być spójne. W przypadku awarii tunelu lub centrali oddział zazwyczaj nie ma w tym projekcie automatycznego lokalnego dostępu do Internetu.

⚠️ Ta procedura dotyczy wyłącznie IPsec policy-based. Peer nie może być route-based. W nowych lub rozwijających się projektach zaleca się route-based Any-to-Any: oba peery używają selektorów Any, każdy otrzymuje interfejs XFRM i wymaga jawnych tras Static, SD-WAN lub dynamicznych. Nie należy łączyć tych kroków z poniższą procedurą policy-based. Wybór opisuje artykuł Konfiguracja VPN IPsec Site-to-Site.

Przykład i wymagania

W przykładzie używana jest sieć oddziału 10.20.0.0/24. Centrala ma działające łącze WAN i zaplanowany tunel policy-based. 10.20.0.0/24 jest wartością dokumentacyjną, którą trzeba zastąpić rzeczywistą siecią oddziału.

W tym projekcie globalna Route Precedence musi mieć kolejność VPN, Static, SD-WAN. Przed zmianą należy zapisać bieżącą wartość i zidentyfikować wszystkie inne ścieżki Static, VPN i SD-WAN, których może ona dotyczyć. Kontrolowaną procedurę opisuje Bezpieczna zmiana Route Precedence.

Domyślna kolejność w SFOS 22 to Static, SD-WAN, VPN. Ten projekt jest inny, ponieważ Remote subnet: Any tworzy w oddziale automatyczną trasę VPN policy-based dla wszystkich celów. Nie należy usuwać istniejącej trasy domyślnej Static 0.0.0.0/0 do lokalnego WAN: pozostaje ona dostępna dla ruchu generowanego przez firewall po wyłączeniu użycia VPN oraz dla kontrolowanego wycofania. Bieżącą wartość odczytuje się w Device Console poleceniem system route_precedence show; osobny artykuł zawiera polecenie zmiany, analizę wpływu i drogę powrotną.

Przed zmianą muszą być również dostępne:

• działający tunel IPsec policy-based między obiema zaporami;
• przetestowany dostęp administracyjny do obu lokalizacji;
• wystarczająca wydajność Internetu i firewalla w centrali;
• DNS, Web Policies, IPS, Application Control i zaplanowane wyjątki;
• aktualna kopia zapasowa konfiguracji i zapis zmiany zawierający pierwotne selektory, Route Precedence, opcję ruchu systemowego oraz identyfikatory firewalla i NAT;
• udokumentowana droga powrotna i okno serwisowe.

W przypadku HA przed zmianą dla każdej lokalizacji zapisuje się aktywny węzeł, poprawny stan klastra i dostęp administracyjny do peera. HA nie zastępuje drugiego łącza WAN centrali ani drugiej lokalizacji. Failover jest oddzielnym testem i nie wynika z zielonego tunelu.

Ustawianie selektorów IPsec

W centrali ustawić Local subnet na Any, a Remote subnet na LAN oddziału. W oddziale zastosować wartości odwrotne: lokalną sieć oddziału i zdalne Any.

Następnie przetestować tunel z wewnętrznym celem w centrali. Ścieżkę internetową włączyć dopiero po potwierdzeniu ruchu między lokalizacjami w obu kierunkach. Pozwala to odróżnić błąd IPsec od problemu NAT lub reguły.

Tworzenie reguł firewalla i NAT

Reguły tworzy się w Rules and policies > Firewall rules. Automatycznie wygenerowane reguły VPN nie są kompletnym projektem dla tej ścieżki internetowej.

Centrala: VPN do WAN

Reguła Branch_VPN_to_WAN zezwala na ruch oddziału do Internetu:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: tylko rzeczywiście wymagane usługi
• Log firewall traffic: włączone
• Create linked NAT rule > Translated source (SNAT): MASQ

Web Policy, IPS, Application Control i TLS Inspection wybiera się świadomie. Powiązana reguła MASQ tłumaczy klientów oddziału na publiczny adres centrali. Dla ruchu wychodzącego SFOS najpierw ocenia regułę firewalla, a potem SNAT; trzeba więc sprawdzić kolejność NAT, ponieważ wcześniejsza pasująca reguła NAT ma pierwszeństwo. NAT nie tworzy też trasy, a zmiany NAT dotyczą tylko nowych połączeń.

Droga powrotna składa się z dwóch części: MASQ kieruje odpowiedzi internetowe do adresu WAN centrali, a następnie centrala używa automatycznej trasy VPN policy-based do odtworzonego celu 10.20.0.0/24. Jeśli LAN oddziału znajduje się za innym routerem, trzeba udokumentować i przetestować również jego drogę w obu kierunkach.

Oddział: zezwalanie z LAN do VPN

Reguła Branch_LAN_to_VPN znajduje się nad każdą lokalną regułą zezwalającą z LAN do WAN:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: tylko rzeczywiście wymagane usługi
• Log firewall traffic: włączone

⚠️ Najpierw wyjaśnij skuteczność blokowania ruchu WWW: informacje producenta dotyczące Drop, HTTP/HTTPS, uwierzytelniania i Web Exceptions są sprzeczne. Sama reguła Drop nie dowodzi zatem pełnego zablokowania lokalnego dostępu do Internetu. Przed wdrożeniem produkcyjnym potwierdź zachowanie konkretnej wersji i buildu SFOS oraz ścieżki przetwarzania poprzez pisemne wyjaśnienie Sophos lub wyraźnie zatwierdzony, izolowany test. Przypadki testowe i warunki przerwania opisuje artykuł Akcje i rejestrowanie reguł firewalla. Jeśli dostęp do WWW jest niejasny lub nieoczekiwanie dozwolony, nie wdrażaj rozwiązania produkcyjnie.

Następnie umieszcza się precyzyjną regułę Branch_LAN_to_WAN_drop dla tej samej sieci oddziału z LAN do WAN. Realizuje ona planowaną logikę blokowania lokalnej ścieżki internetowej obok tunelu; jej rzeczywiste działanie trzeba potwierdzić zgodnie z powyższym opisem. Nie należy przypadkowo obejmować nią innych sieci ani wyraźnie wymaganych usług lokalnych.

Kolejność jest elementem bezpieczeństwa: precyzyjne wyjątki, Branch_LAN_to_VPN, następnie Branch_LAN_to_WAN_drop, a potem szersze reguły. Po zmianach testuje się nowe połączenia klientów, a nie tylko istniejące sesje.

Artykuł Bezpieczne tworzenie reguł firewalla wyjaśnia wspólną kontrolę pozycji, Rule ID i powiązanej reguły NAT.

Oddzielna decyzja o ruchu generowanym przez system

Powyższe reguły sterują przekazywanym ruchem klientów. DNS, NTP, aktualizacje, Central i inne połączenia generowane przez sam firewall oddziału są ruchem generowanym przez system.

DNS również rozdziela się według źródła. Klient używający publicznego resolvera podąża ścieżką klienta przez tunel. Wewnętrzny resolver w centrali wymaga odpowiedniego selektora, reguły firewalla i drogi powrotnej. Tylko zapytania DNS generowane przez sam firewall podlegają poniższej opcji ruchu systemowego. Dlatego osobno testuje się publiczny adres IP i FQDN.

Udokumentowana wartość domyślna to enable; nie potwierdza ona rzeczywistego stanu istniejącej instalacji. Dla SFOS 22/23 poniższe polecenie odczytu (getter) wymaga osobnego potwierdzenia dla zainstalowanego buildu. Stanowi ono zatem wyłącznie punkt odniesienia do potwierdzenia, a nie zweryfikowaną instrukcję odczytu: należy go używać tylko wtedy, gdy składnia i znaczenie wyniku zostały potwierdzone dla zainstalowanego buildu przez jego pomoc CLI lub Sophos Support. W przeciwnym razie nie należy go wykonywać i trzeba skorzystać z potwierdzonej metody odczytu. Przed zmianą należy odczytać tą metodą rzeczywistą wartość opcji i zapisać ją w dokumentacji zmiany; ponadto musi być ustalona dokładna procedura przywrócenia z użyciem udokumentowanych poleceń ustawiających enable lub disable. Bez potwierdzonej metody odczytu, rzeczywistej wartości sprzed zmiany i dokładnej procedury przywrócenia nie należy zmieniać opcji.

show routing policy-based-ipsec-vpn system-generate-traffic

Jeśli tylko ruch klientów ma korzystać z centrali, ruch generowany przez firewall może wychodzić bezpośrednio przez WAN oddziału:

⚠️ Ta zmiana restartuje wszystkie tunele IPsec na firewallu. Najpierw należy udokumentować stan, okno serwisowe i drogę odzyskiwania. Polecenia nie wykonuje się tylko w ramach testu ani na podstawie przypuszczenia.

set routing policy-based-ipsec-vpn system-generate-traffic disable

Bezpośrednio po ustawieniu należy ponownie odczytać wartość opcji tą samą potwierdzoną metodą odczytu; musi ona wynosić disable. To potwierdzenie stanu nie zastępuje opisanych poniżej testów wszystkich tuneli, wymaganych usług firewalla oraz wybranej lokalnej lub centralnej ścieżki danych. Jeśli wynik jest niejednoznaczny lub nie odpowiada wartości docelowej, nie należy wprowadzać kolejnych zmian na podstawie przypuszczeń, lecz wyjaśnić rozbieżność z Sophos Support.

Podczas wycofania należy odtworzyć udokumentowany poprzedni stan. Przywrócenie opcji również restartuje wszystkie tunele IPsec; wcześniej należy zastosować te same środki ostrożności dotyczące stanu, okna serwisowego i drogi odzyskiwania. Jeśli opcja była wcześniej aktywna, użyć:

set routing policy-based-ipsec-vpn system-generate-traffic enable

Jeśli zapisana wartość sprzed zmiany wynosiła disable, podczas wycofywania zmiany nie wolno automatycznie ustawiać enable. Jeśli bieżąca wartość opcji już odpowiada wartości sprzed zmiany, ponowne wykonanie polecenia ustawiającego nie jest potrzebne; w przeciwnym razie należy przywrócić dokładnie zapisaną wartość sprzed zmiany za pomocą odpowiedniego udokumentowanego polecenia ustawiającego. Po każdej zmianie i każdym jej wycofaniu należy ponownie odczytać wartość opcji tą samą potwierdzoną metodą odczytu i porównać ją z odpowiednią wartością docelową lub zapisaną wartością sprzed zmiany. Osobno należy ponownie sprawdzić wszystkie połączenia IPsec, wymagane usługi firewalla oraz ustaloną lokalną lub centralną ścieżkę danych. Jeśli wynik ponownego odczytu jest niejednoznaczny lub niezgodny z oczekiwaną wartością, nie należy deklarować pomyślnego przywrócenia i trzeba skontaktować się z Sophos Support.

Weryfikacja ścieżki danych

Klient z 10.20.0.0/24 najpierw otwiera publiczny adres IP, a następnie FQDN przez HTTPS. Test potwierdza kilka warstw:

1. W oddziale pasuje Branch_LAN_to_VPN; lokalna reguła odrzucająca LAN-to-WAN nie pasuje do tego prawidłowego przepływu.
2. W centrali pasują Branch_VPN_to_WAN i powiązana reguła MASQ.
3. Publicznie widoczny adres źródłowy należy do centrali.
4. DNS, HTTPS i cel celowo zablokowany zachowują się zgodnie z centralną polityką.
5. W Diagnostics > Packet capture pola In interface, Out interface, Rule ID, NAT ID, Status i Reason pokazują pakiety żądania i odpowiedzi przez tunel oraz WAN centrali.
6. Ruch generowany przez system wykorzystuje wcześniej wybraną ścieżkę lokalną lub centralną.
7. Current activities > IPsec connections pozostaje zestawione podczas testu, a Log viewer nie pokazuje nieoczekiwanych odrzuceń.
8. W HA oddzielnie wykonuje się zatwierdzony failover węzła i powtarza pełny test. Bez tego nie potwierdza się redundancji HA.

Sam Speedtest nie wystarczy. Trzeba też przetestować rzeczywiste aplikacje, DNS, logi zabezpieczeń i dłuższe pobieranie. Przy problemach z wydajnością pomagają osobne procedury testu prędkości Internetu oraz MTU i MSS w VPN.

Typowe błędy i wycofanie

• Klient oddziału nadal używa lokalnego WAN: sprawdzić kolejność reguł, sieć źródłową, regułę LAN-to-VPN i regułę odrzucającą. Nie dodawać szerokiego wyjątku jako szybkiej poprawki.
• Tunel jest zielony, ale Internet nie działa: w centrali sprawdzić regułę VPN-to-WAN, Rule ID, MASQ, bramę WAN, DNS i drogę powrotną.
• Tylko sam firewall używa niewłaściwej ścieżki: sprawdzić policy-based-ipsec-vpn system-generate-traffic. Nie mylić ruchu klientów z ruchem generowanym przez system.
• Inne tunele przestają działać po zmianie CLI: restart wszystkich tuneli IPsec jest udokumentowanym zachowaniem. Odtworzyć poprzedni stan i oddzielnie zweryfikować każdy tunel.
• Awaria tunelu lub centrali: standardowy projekt nie zapewnia lokalnego wyjścia do Internetu. Taki fallback wymaga świadomie zaplanowanej oddzielnej ścieżki bezpieczeństwa i routingu.
• Publiczny adres IP działa, ale FQDN nie: sprawdzić adres DNS klienta, regułę DNS, ścieżkę do centralnego resolvera i odpowiedzi. Opcja ruchu systemowego ma znaczenie tylko wtedy, gdy zapytanie generuje firewall.

Przed wycofaniem należy najpierw przygotować nad Branch_LAN_to_WAN_drop tymczasową regułę LAN-to-WAN ograniczoną do jednego klienta testowego. Następnie przywrócić zapisaną wartość Route Precedence i sprawdzić lokalną ścieżkę WAN w nowej sesji tego klienta. Jeśli test się nie powiedzie, natychmiast przywrócić pierwszeństwo tras i stan reguł full tunnel przez niezależny dostęp administracyjny. Dopiero po udanym teście włączyć poprzednią zwykłą regułę LAN-to-WAN, wyłączyć Branch_LAN_to_WAN_drop i usunąć regułę tymczasową.

Następnie przywrócić poprzednią wartość opcji ruchu systemowego i sprawdzić wszystkie połączenia IPsec, ponieważ ta zmiana restartuje tunele. Branch_LAN_to_VPN, VPN-to-WAN i MASQ wyłączać lub usuwać tylko wtedy, gdy Rule ID, NAT ID i użycie potwierdzają brak innych zależnych przepływów. Na końcu przywrócić pierwotne selektory IPsec lub usunąć tunel utworzony wyłącznie dla tej ścieżki. Kopię zapasową konfiguracji i niezależny dostęp administracyjny zachować do czasu pomyślnego zestawienia nowych sesji DNS, HTTPS i aplikacji w obu lokalizacjach.

FAQ