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

Następnie umieszcza się precyzyjną regułę Branch_LAN_to_WAN_drop dla tej samej sieci oddziału z LAN do WAN. Zapobiega ona ominięciu planowanej ścieżki tunelu przez zbyt szeroką lokalną regułę internetową. 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.

Wartością domyślną jest enable. Ponieważ istniejący system może mieć inne ustawienie, najpierw należy wyświetlić bieżący stan za pomocą tego polecenia tylko do odczytu w Device Console:

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:

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

⚠️ 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.

Podczas wycofania należy odtworzyć udokumentowany poprzedni stan. Jeśli opcja była wcześniej aktywna, użyć:

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

Po każdej zmianie ponownie przetestować wszystkie połączenia IPsec i wymagane usługi firewalla.

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ą policy.
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