Rozwiązywanie problemów z ARP po migracji Sophos Firewall

Po wymianie zapory nowa Sophos Firewall może być online, podczas gdy pojedyncze publiczne aliasy IP pozostają niedostępne. Często router upstream nadal kojarzy te adresy z adresem MAC interfejsu WAN starego urządzenia. Pakiety w ogóle nie docierają wtedy do nowej zapory, mimo że alias, DNAT i reguła zapory wyglądają na skonfigurowane poprawnie.

Ten przewodnik pokazuje, jak zawęzić przyczynę tego problemu z IPv4 za pomocą kontroli interfejsu, Packet Capture i wpisów ARP urządzenia upstream. Pamięć podręczną ARP należy aktualizować lub wywołać ARP Ping w Device Console dopiero wtedy, gdy potwierdzono przyczynę w warstwie 2. W ogólnym planowaniu migracji sprzętu pomocny jest również artykuł Porównanie Sophos XG i XGS.

Kiedy rzeczywiście należy podejrzewać ARP

Taki problem pojawia się zazwyczaj bezpośrednio po wymianie urządzenia, przywróceniu konfiguracji lub zmianie producenta. Publiczny adres IP pozostaje ten sam, ale zmienia się adres MAC interfejsu WAN.

Wyraźne sygnały to:

• Główny adres IP interfejsu WAN działa, ale jeden lub kilka aliasów IP nie.
• Zewnętrzny test nie dociera do opublikowanej usługi pod określonym publicznym adresem IP.
• W Packet Capture nie pojawiają się pakiety przychodzące dla danego adresu IP.
• Usługa zaczyna działać po wygaśnięciu pamięci podręcznej urządzenia upstream, bez dalszych zmian na zaporze.
• Router upstream nadal wskazuje adres MAC starego urządzenia dla publicznego adresu IP.

ARP nie jest automatycznie przyczyną problemu. Jeśli pakiety docierają do interfejsu WAN, w następnej kolejności należy sprawdzić DNAT, regułę zapory, strefę, serwer wewnętrzny lub trasę zwrotną. Ta procedura nie dotyczy również IPv6, gdzie za wykrywanie sąsiadów odpowiada Neighbor Discovery.

Jeśli natomiast trzeba sprawdzić lokalną pamięć podręczną ARP lub NDP Sophos Firewall, należy skorzystać z instrukcji Sprawdzanie pamięci podręcznej sąsiadów ARP i NDP. Wyjaśnia ona również, kiedy opróżnienie pamięci ma sens, a kiedy problem nadal leży po stronie operatora lub urządzenia upstream.

Dlaczego aliasy IP mogą przestać działać po wymianie urządzenia

ARP przypisuje adres IPv4 do adresu MAC w lokalnym segmencie warstwy 2. Router zapisuje to przypisanie w pamięci podręcznej ARP. Po wymianie urządzenia upstream powinien nauczyć się adresu MAC interfejsu WAN nowej zapory. Jeśli nie nastąpi to dla aliasu IP, router nadal wysyła pakiety do starego urządzenia.

Wyjaśnia to, dlaczego główny adres IP może działać, choć alias IP jest niedostępny: upstream przechowuje osobny wpis dla każdego adresu IP. Jedno przypisanie może być już aktualne, a inne nadal wskazywać stary adres MAC.

Najpierw trzeba jednak ustalić, w jaki sposób dostawca udostępnia publiczne adresy:

• Sieć bezpośrednio połączona: Upstream rozwiązuje główny adres IP i aliasy IP za pomocą ARP. Po wymianie sprzętu stare wpisy są wiarygodną przyczyną problemu.
• Routowany blok publiczny: Dostawca routuje blok do głównego adresu IP interfejsu WAN. W takim przypadku nie trzeba oczekiwać osobnego wpisu ARP dla każdego publicznego adresu IP; ważniejsze są trasa po stronie dostawcy oraz lokalna konfiguracja aliasów i NAT.

Diagnostyka przed ingerencją

Najpierw należy ustalić, w którym miejscu kończy się przepływ pakietów. Pozwala to uniknąć jednoczesnego zmieniania ARP, NAT i reguł zapory.

1. W Network > Interfaces sprawdź fizyczny interfejs WAN oraz odpowiednie adresy. Alias IP przypisuje się do właściwego interfejsu fizycznego przez Add interface > Add alias; wersja IP, adres i maska podsieci muszą odpowiadać projektowi sieci.
2. Jeśli aliasy pochodzą z innej podsieci, sprawdź, czy urządzenie upstream w tej podsieci jest osiągalne jako brama zapory. Kilka oddzielnych interfejsów WAN w tej samej podsieci nie jest poprawnym rozwiązaniem i samo może powodować problemy z ARP; zależnie od projektu należy użyć interfejsów alias lub LAG.
3. Przetestuj ten sam publiczny adres IP i tę samą usługę z rzeczywiście zewnętrznego systemu. Sam ping nie wystarcza, ponieważ ICMP może być blokowany; warto dodatkowo wykonać test znanego portu TCP.
4. Uruchom przechwytywanie na interfejsie WAN w Diagnostics > Packet capture. Do analizy warstwy 2 filtruj według interfejsu oraz Ethernet type: ARP; następnie dla usługi filtruj według docelowego adresu IP i protokołu.
5. Dopiero gdy pakiety IP docierają, wyszukaj w Log viewer docelowy adres IP, usługę oraz Firewall Rule ID i NAT Rule ID. Sam ARP analizuje się za pomocą Packet Capture, a nie zwykłego logu reguły zapory.

Artykuł Korzystanie z Packet Capture na Sophos Firewall dokładniej opisuje ten widok. Przy kontroli interfejsu, strefy i przypisania aliasu pomocny jest artykuł Konfigurowanie stref i interfejsów Sophos Firewall.

Wynik obserwacji wyznacza dalszy kierunek:

• Brak pakietów na WAN: Sprawdź ARP urządzenia upstream, routing dostawcy, CPE lub przełącznik przed zaporą.
• Pakiety docierają i są odrzucane: Sprawdź regułę zapory, DNAT, strefę i usługę.
• Pakiety są przekazywane do sieci wewnętrznej, ale nie ma odpowiedzi: Sprawdź trasę zwrotną, serwer wewnętrzny, SNAT i zaporę serwera.
• Problem dotyczy tylko aliasu IP: Porównaj konfigurację aliasu i wpis upstream dokładnie dla tego adresu IP.

Celowa aktualizacja przypisania ARP

Czyszczenie pamięci podręcznej urządzenia upstream

Najlepiej usunąć błędny wpis na urządzeniu, które go przechowuje. Jeśli zarządzasz routerem upstream lub urządzeniem CPE dostawcy, usuń wpis ARP tylko dla danego adresu IP. Następnie upstream musi nauczyć się nowego adresu MAC interfejsu WAN.

Jeśli nie da się usunąć pojedynczego wpisu, pamięć podręczną może odświeżyć również restart odpowiedniego routera. Należy go wykonać w oknie serwisowym, ponieważ przerwie także inne połączenia. W przypadku urządzeń dostawcy lepiej przekazać mu konkretny adres IP, stary i nowy adres MAC oraz właściwe CPE, zamiast bez potrzeby restartować cały tor połączenia.

Wywołanie ARP Ping przez Device Console

Sophos Firewall udostępnia diagnostykę ARP w Device Console. ARP Ping z właściwym Source IP i interfejsem WAN może wywołać aktualizację na bezpośrednio połączonym urządzeniu upstream.

Po zalogowaniu przez konsolę lub SSH otwórz Option 4: Device Console i wykonaj polecenie z rzeczywistymi wartościami:

system diagnostics utilities arp ping source <alias-ip> interface <wan-interface> <upstream-gateway>

Przykład z adresami dokumentacyjnymi:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

W tym przykładzie 198.51.100.21 jest odpowiednim aliasem IP na Port2, a 198.51.100.1 to bezpośrednio osiągalne urządzenie upstream w tym samym segmencie warstwy 2. Source IP, interfejs i cel muszą do siebie pasować. Jeśli problem dotyczy kilku aliasów IP, każdy adres testuje się osobno, aby można było jednoznacznie ocenić rezultat.

Polecenie nie zastąpi poprawienia błędnej konfiguracji aliasu ani statycznego wpisu ARP u dostawcy. Jeśli dostawca routuje adresy, zamiast rozwiązywać je lokalnie przez ARP, ARP Ping także nie jest właściwym rozwiązaniem. Bezpieczny dostęp do Device Console opisuje artykuł Łączenie się z Sophos Firewall przez SSH.

Weryfikacja dostępności po korekcie

Po wykonaniu dokładnie jednej czynności należy powtórzyć ten sam test. Dzięki temu wiadomo, co faktycznie usunęło problem.

1. Sprawdź na urządzeniu upstream, czy dany adres IP wskazuje teraz nowy adres MAC interfejsu WAN.
2. Powtórz zewnętrzny ping lub test portu TCP z tym samym źródłem i celem.
3. Sprawdź w Packet Capture, czy pakiety docierają teraz do interfejsu WAN.
4. Jeśli pakiety docierają, skontroluj Firewall Rule ID i NAT Rule ID w Log Viewer.
5. Przetestuj opublikowaną usługę aż do serwera wewnętrznego i w kierunku zwrotnym.

Zaktualizowany wpis ARP potwierdza jedynie, że upstream może wysyłać pakiety do nowej zapory. Działanie usługi nadal zależy od DNAT, reguły zapory, celu wewnętrznego i trasy zwrotnej. Pełną ścieżkę reguł dla publikacji serwera opisuje artykuł Publikowanie serwera przez DNAT.

Jeśli problem nadal występuje

Jeśli adres IP pozostaje niedostępny mimo aktualnego wpisu ARP, nie należy wykonywać kolejnych przypadkowych poleceń powłoki. Trzeba zmienić hipotezę i szukać innej przyczyny.

Typowe alternatywy to:

• Alias IP jest przypisany do niewłaściwego interfejsu fizycznego lub używa błędnej maski podsieci.
• Dostawca routuje publiczny blok inaczej, niż zakładano.
• Statyczny wpis ARP lub MAC na urządzeniu upstream zastępuje dynamiczne uczenie.
• Przełącznik przed zaporą przechowuje stare przypisanie MAC lub używa Port Security.
• Reguła DNAT wskazuje inny publiczny adres IP.
• Reguła zapory nie zezwala na odpowiednie źródło, usługę lub strefę.
• Serwer wewnętrzny odpowiada przez inną bramę.
• W środowisku HA oczekiwany jest niewłaściwy wirtualny lub fizyczny adres MAC.

Regularnie powracającego problemu z ARP nie należy również obchodzić okresowo uruchamianym własnym poleceniem. W takim przypadku dostawca, administrator CPE, osoba odpowiedzialna za projekt warstwy 2 oraz w razie potrzeby Sophos Support muszą wyjaśnić przyczynę.

Celowe zaangażowanie dostawcy lub administratora upstream

Jeśli przechwytywanie na WAN nie pokazuje pakietów dla danego adresu IP, dostawca potrzebuje precyzyjnego wyniku diagnostyki, a nie ogólnego zgłoszenia, że zapora jest niedostępna.

Przygotuj następujące informacje:

• odpowiedni główny adres IP lub alias IP,
• interfejs WAN i nowy adres MAC,
• bramę upstream lub CPE,
• czas zewnętrznego testu i wykonania ARP Ping,
• wynik Packet Capture,
• oczekiwany sposób udostępnienia adresów: sieć bezpośrednio połączona lub blok routowany,
• wynik dla głównego adresu IP i pozostałych aliasów IP.

Na tej podstawie dostawca może sprawdzić konkretny wpis ARP, statyczne przypisanie lub trasę do publicznego bloku. Poufne dane konfiguracyjne lub pełne pliki Packet Capture należy przekazywać wyłącznie uzgodnionym kanałem wsparcia.

Krótka lista kontrolna

• Udokumentowano główny adres IP, aliasy IP i sposób ich udostępnienia.
• Sprawdzono interfejs fizyczny, wersję IP i maskę podsieci.
• Wykonano zewnętrzny test TCP i Packet Capture dla tych samych celów.
• W diagnostyce rozdzielono ruch ARP od ruchu IP.
• Celowo usunięto wpis upstream lub wykonano ARP Ping z poprawnymi parametrami.
• Potwierdzono nowe przypisanie MAC na urządzeniu upstream.
• Następnie sprawdzono DNAT, Firewall Rule ID, NAT Rule ID i trasę zwrotną.
• Przyczynę i działanie zapisano w zgłoszeniu zmiany lub protokole migracji.

FAQ