Konfiguracja i testowanie aliasu IP na Sophos Firewall

Alias IP wiąże dodatkowy adres IPv4 lub IPv6 z istniejącym interfejsem fizycznym Sophos Firewall. Jest przydatny, gdy operator dostarcza kilka adresów publicznych przez to samo łącze WAN albo gdy interfejs wewnętrzny ma obsługiwać drugą podsieć podczas migracji.

Ważna różnica polega na tym, że alias nie jest drugim łączem internetowym, osobną strefą ani niezależną ścieżką gatewaya. Adres korzysta z tego samego fizycznego interfejsu nadrzędnego. Routing, reguły firewalla, NAT i Device Access muszą więc nadal odpowiadać istniejącemu projektowi interfejsu.

⚠️ Przed dodaniem publicznego aliasu IP należy udokumentować aktualny backup, niezależne połączenie administracyjne, przydział operatora, pierwotny stan ARP oraz planowane reguły firewalla i NAT. Dodatkowy adres sam w sobie nie publikuje serwera, ale może udostępnić lokalne usługi firewalla zgodnie z regułami Device Access strefy nadrzędnej.

Przykład używa IPv4 na interfejsie WAN. SFOS obsługuje również aliasy IPv6, jeśli wersja IP jest zgodna z interfejsem nadrzędnym. Neighbor Discovery dla IPv6 i NAT66 nie są jednak częścią tego konkretnego przykładu.

Alias IP w ośmiu krokach

1. Potwierdzić, że operator lub sieć wewnętrzna rzeczywiście dostarcza dodatkowy adres przez ten sam interfejs fizyczny.
2. Udokumentować interfejs nadrzędny, wersję IP, adres, maskę podsieci i przeznaczenie.
3. Sprawdzić Device Access, istniejące reguły oraz niezależną ścieżkę administracyjną.
4. Powiązać adres z interfejsem nadrzędnym w Network > Interfaces > Add interface > Add alias.
5. Jeśli jest potrzebny w regułach i NAT, utworzyć czytelnie nazwany IP Host z dokładnie tym adresem.
6. Skonfigurować DNAT lub SNAT tylko dla zamierzonego przepływu; ruch systemowy obsłużyć osobno.
7. Sprawdzić ścieżkę operatora, ARP, Firewall Rule ID, NAT Rule ID oraz oba kierunki przy użyciu nowego połączenia.
8. Przetestować urządzenie zastępcze, failover HA i rollback w oknie serwisowym z użyciem tego samego przepływu.

Kiedy alias IP jest odpowiedni

Alias IP jest odpowiedni, gdy kilka adresów ma korzystać z tej samej fizycznej ścieżki warstwy 2 i tego samego gatewaya. Typowe przypadki:

• kilka publicznych adresów IPv4 na jednym statycznym łączu WAN;
• osobny adres publiczny dla DNAT, WAF lub usługi pocztowej;
• stały adres źródłowy dla wybranego ruchu przekazywanego;
• druga podsieć wewnętrzna w tym samym segmencie fizycznym podczas kontrolowanej migracji;
• kilka adresów operatora w tej samej podsieci, dla których osobne interfejsy WAN powodowałyby problemy ARP.

Kilka interfejsów WAN w tej samej podsieci nie jest właściwym zamiennikiem. Sophos ostrzega, że z powodu problemów ARP gatewaye mogą stać się niedostępne, i wskazuje alias lub LAG jako odpowiednie formy interfejsu. Strefy i interfejsy na Sophos Firewall wyjaśnia podstawowy wybór między portami fizycznymi, VLAN, LAG, bridge i XFRM.

Alias nie jest odpowiedni, jeśli wymagane są drugie łącze, osobny gateway, niezależny stan linku, inna strefa bezpieczeństwa lub rzeczywisty failover. W takim przypadku potrzebny jest osobny projekt interfejsu, VLAN, LAG, WAN lub routingu.

Jeśli zapora nie ma lokalnie posiadać dodatkowego adresu IPv4, a jedynie odpowiadać w jego imieniu na zapytania ARP w bezpośrednio podłączonym segmencie, jest to inny projekt. Konfiguracja Proxy ARP na Sophos Firewall wyjaśnia tę decyzję oraz ściśle ograniczoną procedurę CLI i testowania.

Przykład i wartości do zastąpienia

Przykład publikuje wewnętrzną usługę HTTPS przez drugi adres publiczny:

• Interfejs nadrzędny: Port2
• Strefa nadrzędna: WAN
• Adres główny: 203.0.113.9/29
• Gateway operatora: 203.0.113.14
• Alias IP: 203.0.113.10/29
• Obiekt hosta aliasu: WAN_ALIAS_APP_203.0.113.10
• Serwer wewnętrzny: APP-DMZ_10.20.40.20
• IP serwera: 10.20.40.20
• Usługa: HTTPS
• Zewnętrzny host testowy: 198.51.100.25

203.0.113.0/24 i 198.51.100.0/24 są zarezerwowane do celów dokumentacyjnych. W konfiguracji produkcyjnej należy je zastąpić adresami przydzielonymi przez operatora oraz autoryzowanym zewnętrznym hostem testowym.

Maska /29 jest jedynie realistycznym przykładem. Nie wolno jej kopiować, jeśli operator dostarcza routowany blok, pojedynczy adres /32 lub inny rozmiar sieci. Właściwą wartość określają dokumentacja operatora, model ARP lub routingu oraz wersja IP używana na interfejsie nadrzędnym.

Dodawanie aliasu do interfejsu fizycznego

W Network > Interfaces adres jest wiązany bezpośrednio z istniejącym interfejsem:

1. Wybrać Add interface > Add alias.
2. W Physical interface wybrać Port2 lub rzeczywisty interfejs nadrzędny.
3. Ustawić IP version na IPv4.
4. W IPv4/Netmask wpisać 203.0.113.10 oraz maskę potwierdzoną przez operatora.
5. Zapisać przyciskiem Save.

Dodatkowy adres pojawi się następnie przy interfejsie nadrzędnym. Jeśli istnieją więcej niż trzy aliasy, SFOS początkowo pokazuje tylko pierwsze trzy. W widocznym obszarze adresów można przewinąć do pozostałych wpisów.

Aliasu nie można niezależnie włączyć ani wyłączyć. Jeśli fizyczny interfejs nadrzędny zostanie wyłączony lub utraci link, jego adresy aliasów również przestaną być dostępne. Z drugiej strony zapisanie aliasu nie tworzy nowego wpisu gatewaya ani osobnej trasy.

Formularz Add alias nie ma własnego pola strefy. Dlatego dla lokalnych usług firewalla nadal istotna jest strefa interfejsu nadrzędnego. Przed dodaniem publicznego aliasu IP należy w Administration > Device access sprawdzić, które usługi są dostępne z WAN, i dla stałych źródeł administracyjnych użyć restrykcyjnego wyjątku Local Service ACL Exception. SSO ani MFA nie uzasadniają szerokiego dostępu do WebAdmin.

Używanie aliasu w regułach i NAT

Powiązany alias i IP Host pełnią różne funkcje:

• Alias sprawia, że adres jest lokalnie obecny na interfejsie fizycznym.
• IP Host umożliwia czytelny wybór tego samego adresu w polach reguł i NAT.

Sam obiekt hosta nie wiąże adresu z interfejsem. Analogicznie sam alias nie publikuje serwera ani nie zezwala na ruch przekazywany. Prawidłowe używanie IP Hosts i usług szczegółowo wyjaśnia granice tych obiektów.

Publikowanie usługi przychodzącej przez DNAT

W tym przykładzie w Hosts and services > IP host tworzony jest obiekt WAN_ALIAS_APP_203.0.113.10 typu IP z adresem 203.0.113.10. Następnie należy utworzyć restrykcyjną regułę DNAT i pasującą regułę firewalla:

• Original source: autoryzowane sieci zewnętrzne lub świadomie Any
• Original destination: WAN_ALIAS_APP_203.0.113.10
• Original service: HTTPS
• Translated destination (DNAT): APP-DMZ_10.20.40.20
• Translated service (PAT): Original
• Inbound interface: Port2 lub faktycznie potwierdzone wejście
• Translated source (SNAT): zwykle Original
• Log firewall traffic: włączone

Reguła firewalla zezwala na tę samą usługę zewnętrzną z WAN do strefy serwera wewnętrznego i jako Destination network wykorzystuje publiczny adres aliasu z Original destination. Źródło, usługę i funkcje ochrony należy ograniczyć tak bardzo, jak to możliwe. Pełny proces obejmujący pozycję reguły, loopback i wzmocnienie zabezpieczeń znajduje się w Publikowanie serwera przez DNAT.

Wysyłanie ruchu przekazywanego przez alias IP

Jeśli tylko konkretny serwer wewnętrzny ma być widoczny na zewnątrz jako 203.0.113.10, należy utworzyć osobną regułę SNAT dokładnie dla tego przepływu. Translated source (SNAT) używa wtedy IP Host adresu aliasu. Źródło, miejsce docelowe, usługę i interfejsy należy ograniczyć tak bardzo, jak pozwala zastosowanie.

Reguła NAT nie zastępuje reguły firewalla. Ponadto reguły NAT są oceniane tylko dla pierwszego pakietu nowego połączenia. Po zmianie trzeba otworzyć nowe połączenie; istniejąca sesja nie potwierdza nowej ścieżki NAT. NAT na Sophos Firewall wyjaśnia przetwarzanie SNAT, DNAT i PAT.

Osobna obsługa ruchu systemowego firewalla

Ruch DNS, uwierzytelniania, poczty lub inny ruch generowany przez sam firewall nie podlega automatycznie regule SNAT przeznaczonej dla przekazywanych klientów. Sophos wyraźnie dokumentuje, że konfiguracje routingu korzystają z interfejsu głównego. Jeśli określony i uzasadniony przepływ ruchu systemowego ma używać aliasu IP jako źródła, wymaga to osobnej konfiguracji CLI.

Przed zmianą zapisać stan początkowy w Device Console:

show advanced-firewall

Poniższy przykład tłumaczy tylko ruch systemowy przez Port2 do pojedynczego celu 198.51.100.25, używając aliasu IP 203.0.113.10:

set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

⚠️ To polecenie zmienia adres źródłowy ruchu firewalla. Nie tworzy trasy i nie jest ogólnym zamiennikiem reguły NAT. Cel, maska /32, interfejs i alias IP muszą odpowiadać rzeczywistemu zastosowaniu. Po zmianie należy przetestować dokładnie objętą nią usługę i ponownie sprawdzić wpis za pomocą show advanced-firewall.

W celu rollbacku dokładnie ten sam wpis usuwa się poleceniem delete:

set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Szersze maski tłumaczą ruch do całej sieci docelowej. Należy ich używać tylko wtedy, gdy taki większy zakres jest zamierzony, udokumentowany i przetestowany.

Planowanie aliasów z różnych podsieci

Sophos zezwala na kilka adresów aliasów z różnych podsieci na tym samym interfejsie fizycznym, ale określa dwa warunki:

• Sophos Firewall musi być default gatewayem dla hostów wewnętrznych.
• Urządzenia upstream pełniące rolę gatewaya dla ruchu firewalla muszą mieć odpowiedni adres w każdej używanej podsieci aliasu.

Alias nie uruchamia więc automatycznie drugiej podsieci end-to-end. Gateway hosta, peerzy, trasa powrotna, ARP lub Neighbor Discovery, reguły firewalla i NAT również muszą być prawidłowe dla tej podsieci.

Do trwałej segmentacji zwykle bardziej zrozumiały jest osobny VLAN lub interfejs fizyczny. Alias obejmujący wiele podsieci lepiej nadaje się do świadomie zaplanowanego przejścia lub architektury operatora, w której obie sieci rzeczywiście korzystają z tej samej ścieżki warstwy 2.

DHCP Server i DHCP Relay nie mogą być skonfigurowane na Interface Alias. Alias nie jest również prawidłowym Dedicated HA link. Takie wymagania należy realizować na obsługiwanym interfejsie fizycznym lub wirtualnym.

Kontrolowana weryfikacja ścieżki danych i ARP

Weryfikacja powinna odpowiadać rzeczywistemu zadaniu, a nie ograniczać się do pingu:

1. W Network > Interfaces sprawdzić interfejs nadrzędny, adres aliasu, maskę i stan linku.
2. Na urządzeniu operatora lub upstream sprawdzić, czy alias IP jest dostępny przez oczekiwany adres MAC lub oczekiwanego neighbora.
3. Z 198.51.100.25 otworzyć nowe połączenie HTTPS do aliasu IP.
4. W Log Viewer sprawdzić oczekiwane Firewall Rule ID, NAT Rule ID, Source, Original destination i przetłumaczony cel.
5. We wbudowanym Packet Capture porównać wejście na Port2 z wyjściem do serwera.
6. Na serwerze wewnętrznym potwierdzić, że połączenie dociera, a odpowiedź wraca przez Sophos Firewall.
7. Negatywnie przetestować celowo niedozwolony port i nieautoryzowane źródło.
8. W HA powtórzyć kontrolowany failover z nowym połączeniem, bez zakładania, że istniejąca sesja będzie kontynuowana bez przerwy.

Ping do aliasu IP jest miarodajny tylko wtedy, gdy Ping został świadomie dozwolony dla strefy nadrzędnej w Device Access. Dla opublikowanej usługi HTTPS lepszym potwierdzeniem sukcesu jest rzeczywisty test TCP i aplikacji. Packet Capture na Sophos Firewall opisuje filtry, porównanie interfejsów i eksport.

Systematyczne zawężanie błędów

Alias jest widoczny, ale niedostępny z zewnątrz

• Potwierdzić, że operator rzeczywiście dostarcza konkretny adres przez Port2.
• Porównać IP, maskę i interfejs nadrzędny z przydziałem operatora.
• Sprawdzić wpis ARP lub neighbora na urządzeniu upstream.
• Analizować Device Access tylko w przypadku dostępu do samego firewalla.
• Dla usług przekazywanych sprawdzić Firewall Rule ID, NAT Rule ID i ścieżkę powrotną serwera.

Po wymianie firewalla router upstream może nadal przechowywać stary adres MAC aliasu IP. Sophos zaleca w takim przypadku wyczyszczenie pamięci podręcznej routera lub jego restart. W praktyce należy najpierw zaktualizować tylko odpowiedni wpis ARP lub neighbora zgodnie z udokumentowaną procedurą urządzenia upstream; pełny restart należy wykonać w oknie serwisowym.

Ruch wychodzący nadal używa adresu głównego

Dla ruchu przekazywanego sprawdzić, czy oczekiwana reguła SNAT pasuje do nowego połączenia. Source, Destination, Service, Inbound interface, Outbound interface i NAT Rule ID muszą się zgadzać.

Dla ruchu systemowego firewalla zwykła reguła SNAT nie jest właściwym dowodem. Należy wtedy sprawdzić konkretny wpis sys-traffic-nat, trasę, cel i rzeczywisty przepływ pakietów. Nie dodawać szerokiego tłumaczenia na podstawie przypuszczeń.

Nie działa tylko druga podsieć wewnętrzna

Sprawdzić, czy Sophos Firewall rzeczywiście jest default gatewayem hostów objętych problemem i czy urządzenie upstream ma odpowiedni adres w tej podsieci. Następnie osobno sprawdzić trasę powrotną, maskę hosta, ARP, regułę firewalla i NAT. Widoczny alias nie potwierdza tych zależności.

Tunel IPsec przez alias jest aktywny, ale nie przesyła ruchu

Najpierw zapisać wersję i build SFOS, model appliance, użycie PPPoE, powiązanie aliasu, IPsec Acceleration i rzeczywistą ścieżkę pakietów. SFOS 22 ma zależne od wersji przypadki szczególne dotyczące aliasów i akceleracji, których nie wolno przenosić na każdy problem z aliasem. Ograniczoną procedurę diagnostyczną opisano w Rozwiązywanie problemów IPsec dla interfejsów alias.

Eksploatacja, urządzenie zastępcze i rollback

Adresy aliasów należy dokumentować razem z przydziałem operatora, DNS, certyfikatami, NAT, regułami firewalla i odpowiedzialną usługą. Przed wymianą firewalla publiczne aliasy i oczekiwana zmiana ARP lub neighbora muszą być częścią weryfikacji.

Rollback:

1. Udokumentować aktywne użycie aliasu i powiązanego IP Host.
2. W kontrolowany sposób usunąć opublikowane usługi z DNS, monitoringu lub load balancingu.
3. Najpierw wyłączyć powiązane reguły firewalla i NAT oraz potwierdzić zatrzymanie planowanego przepływu.
4. Usunąć istniejący wpis sys-traffic-nat dokładnym poleceniem delete.
5. Usunąć alias i obiekt hosta dopiero wtedy, gdy nie pozostaną żadne zależności produkcyjne.
6. Ponownie sprawdzić interfejs nadrzędny, adres główny, gateway i usługi nieobjęte zmianą.
7. W HA powtórzyć tę samą weryfikację po planowanym failoverze.

Alias nie może być używany jako Dedicated HA link. HA na Sophos Firewall wyjaśnia interfejsy, adresy administracyjne peerów i testy failover wymagane w klastrze.

Lista kontrolna

• Przydział operatora, interfejs nadrzędny, wersja IP, adres i maska są potwierdzone.
• Dostępne są backup i niezależne połączenie administracyjne.
• Sprawdzono Device Access i Local Service ACL strefy nadrzędnej.
• Alias i IP Host o tej samej nazwie nie są ze sobą mylone.
• Reguły firewalla i NAT są ograniczone do zamierzonego przepływu.
• Ruch systemowy jest tłumaczony osobno tylko przy uzasadnionej potrzebie.
• Potwierdzono Firewall Rule ID, NAT Rule ID, ARP i oba kierunki.
• Negatywnie przetestowano nieautoryzowane źródło i niedozwoloną usługę.
• Urządzenie zastępcze, failover HA i rollback są udokumentowane.

Często zadawane pytania