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 IPsec policy-based. W nowych lub rozwijających się projektach route-based Any-to-Any z XFRM i jawnym routingiem jest często bardziej elastyczny. 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.

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;
• udokumentowana droga powrotna i okno serwisowe.

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. Bez prawidłowej drogi powrotnej i NAT tunel może być zielony, ale połączenia internetowe nie otrzymają odpowiedzi.

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
• 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.

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.

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. Packet Capture pokazuje pakiety żądania i odpowiedzi przez tunel oraz WAN centrali.
6. Ruch generowany przez system wykorzystuje wcześniej wybraną ścieżkę lokalną lub centralną.

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.

Podczas wycofania najpierw wyłączyć Branch_LAN_to_WAN_drop i kontrolowanie przywrócić wcześniej dozwoloną lokalną ścieżkę internetową. Następnie usunąć reguły VPN-to-WAN i MASQ tylko wtedy, gdy nie potrzebuje ich żaden inny przepływ. Route Precedence i opcję ruchu systemowego przywrócić dokładnie do udokumentowanych poprzednich wartości, a następnie ponownie przetestować obie lokalizacje.

FAQ