Rozwiązywanie problemów z ARP po migracji Sophos Firewall
Po migracji zapory może się zdarzyć, że nowa Sophos Firewall jest zasadniczo online, ale pojedyncze publiczne adresy IP lub adresy IP aliasów są nadal niedostępne. Jest to szczególnie typowe po przejściu z innego producenta na Sophos Firewall lub po migracji z XG na sprzęt XGS. Adresy IP pozostają takie same, ale adres MAC na interfejsie WAN się zmienia.
Jeśli router, urządzenie CPE dostawcy lub przełącznik nadal mają stare wpisy ARP w pamięci podręcznej, wysyłają pakiety do poprzedniego adresu MAC. Wygląda to wtedy tak, jakby tylko określone adresy IP aliasów, cele DNAT lub testy ping nie działały. Dla ogólnego planowania migracji przydatny jest również artykuł Jaka jest różnica między zaporą XG a XGS?.
Typowe objawy
Problemy z ARP po zmianie pojawiają się zazwyczaj bezpośrednio po przełączeniu lub po przywróceniu na nowym sprzęcie.
Typowe wskazówki:
- Interfejs WAN Sophos Firewall jest online.
- Główny adres IP działa, ale pojedyncze adresy IP aliasów nie.
- Ping na określone publiczne adresy IP nie powodzi się, inne adresy IP na tym samym interfejsie reagują.
- Reguły DNAT lub WAF wydają się poprawnie skonfigurowane, ale nie docierają do wewnętrznego serwera.
- Usługa jest dostępna wewnętrznie, ale zewnętrznie tylko na określonych publicznych adresach IP jest zakłócona.
- Po pewnym czasie zaczyna działać, ponieważ pamięć podręczna ARP automatycznie wygasa.
Ważne jest rozróżnienie: nie każdy problem z dostępnością po migracji jest problemem z ARP. Należy również sprawdzić reguły zapory, reguły NAT, strefy, konfigurację aliasów, routing dostawcy i trasy zwrotne.
Dlaczego ARP może przeszkadzać po migracji
ARP rozwiązuje adresy IPv4 na adresy MAC. W lokalnym segmencie warstwy 2 urządzenie pyta: Jaki adres MAC należy do tego adresu IP? Odpowiedź jest przechowywana w pamięci podręcznej ARP, aby nie każde pakiet musiał wywoływać nowe zapytanie ARP.
Podczas migracji zapory adres IP często pozostaje taki sam, ale adres MAC się zmienia. To właśnie może być problematyczne:
- Router dostawcy zna publiczny adres IP jeszcze ze starym adresem MAC.
- Przełącznik lub router przed zaporą przechowuje przestarzałe wpisy ARP.
- Alias-IP został poprawnie skonfigurowany na nowej zaporze, ale sąsiad nadal wysyła do starego sprzętu.
- Tylko część adresów IP została już nauczona na nowo, dlatego niektóre adresy działają, a inne nie.
W przypadku pojedynczych adresów IP aliasów jest to szczególnie irytujące, ponieważ podstawowe połączenie wydaje się działać. Szybko można wtedy szukać w NAT, regułach zapory lub routingu, chociaż błąd powstaje już wcześniej na warstwie 2.
Sprawdzenie przed użyciem polecenia CLI
Zanim aktywnie wywołasz ARP, podstawowa konfiguracja powinna być poprawna. W przeciwnym razie ping ARP tylko ukryje inny problem.
Sprawdź:
- W Network > Interfaces sprawdź, czy dotknięty adres IP lub adres IP aliasu znajduje się na właściwym interfejsie.
- Sprawdź strefę interfejsu, na przykład
WAN. - Sprawdź bramę, maskę podsieci i logikę sieci aliasów.
- W Rules and policies > NAT rules sprawdź, czy reguła DNAT wskazuje na właściwy publiczny adres IP.
- W Rules and policies > Firewall rules sprawdź, czy istnieje odpowiednia reguła dla ruchu.
- W Log Viewer sprawdź, czy pakiety w ogóle docierają do zapory.
- W razie potrzeby użyj Sophos Firewall Packet Capture w WebAdmin, aby sprawdzić, czy przychodzące pakiety są widoczne na interfejsie WAN.
Jeśli w Packet Capture nie pojawiają się żadne pakiety dla dotkniętego publicznego adresu IP, problem prawdopodobnie leży przed zaporą: router dostawcy, przełącznik przed zaporą, pamięć podręczna ARP lub routing u dostawcy. Jeśli pakiety docierają, ale są odrzucane, najpierw należy sprawdzić NAT, reguły zapory i strefy. Dla logiki interfejsów i stref pomocne jest Konfigurowanie stref i interfejsów Sophos Firewall.
Wykonanie pingu ARP przez Device Console
Sophos Firewall może wywołać ping ARP z określonym źródłowym adresem IP i interfejsem przez Device Console. Jest to przydatne, gdy po migracji aktywnie chce się ogłosić w sieci adres IP aliasu.
Ważne: Polecenie powinno być wykonane tylko wtedy, gdy wiadomo, jaki adres IP źródłowy, jaki interfejs i jaki cel w lokalnym segmencie są używane. Nieprawidłowe wartości nie pomogą i mogą zafałszować analizę. Przed zmianami w produkcyjnej migracji powinno być dostępne aktualne Backup Sophos Firewall.
Polecenie jest wykonywane w Device Console, a nie w Advanced Shell:
system diagnostics utilities arp ping source <alias-ip> interface <interface> <target-ip>
Przykład:
system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1
W tym przykładzie 198.51.100.21 to dotknięty adres IP aliasu na Port2. 198.51.100.1 to osiągalny cel w tym samym segmencie warstwy 2, zazwyczaj brama upstream lub urządzenie CPE dostawcy. Dzięki temu zapora generuje ruch ARP z właściwym źródłowym adresem IP przez właściwy interfejs.
Jeśli SSH nie jest jeszcze skonfigurowane, artykuł Łączenie się z Sophos Firewall przez SSH opisuje, jak uzyskać dostęp do Device Console. Przy migracjach SSH nie powinno być na stałe szeroko dostępne z WAN. Lepszy jest tymczasowy, ograniczony dostęp administracyjny z zaufanej sieci.
Zalecany przebieg
1. Zbieranie dotkniętych adresów IP
Najpierw dokumentuje się, które adresy IP działają, a które nie. W przypadku adresów IP aliasów warto bezpośrednio porównać listę z konfiguracją interfejsu.
Zanotuj:
- Interfejs, na przykład
Port2 - Główny adres IP i adresy IP aliasów
- Brama upstream lub urządzenie CPE dostawcy
- Dotknięte reguły NAT lub WAF
- Wynik ping, testu portu i Packet Capture
2. Ograniczenie problemu z ARP
Z zewnętrznego systemu testowego sprawdź dotknięty publiczny adres IP. Równocześnie na Sophos Firewall uruchom Packet Capture na interfejsie WAN.
Interpretacja:
- Żadne pakiety nie docierają do interfejsu WAN: Sprawdź upstream, ARP, routing dostawcy lub urządzenie przed zaporą.
- Pakiety docierają, ale są odrzucane: Sprawdź regułę zapory, NAT, strefę lub usługę.
- Pakiety docierają i idą dalej wewnętrznie, brak odpowiedzi: Sprawdź trasę zwrotną, wewnętrzny serwer, SNAT lub zaporę serwera.
- Tylko adres IP aliasu jest dotknięty, główny adres IP działa: Skoncentruj się na pamięci podręcznej ARP lub konfiguracji aliasu.
3. Wykonanie pingu ARP dla każdego dotkniętego adresu IP aliasu
Dla każdego dotkniętego adresu IP aliasu wykonaj ping ARP z odpowiednim źródłowym adresem IP i właściwym interfejsem. Następnie nie zmieniaj od razu wielu innych rzeczy, ale najpierw przetestuj, czy zachowanie się zmienia.
Przykład z zastępczymi wartościami:
system diagnostics utilities arp ping source <dotknięty-alias-ip> interface <wan-interface> <upstream-gateway>
Jeśli dotkniętych jest wiele adresów IP aliasów, polecenie jest wykonywane osobno dla każdego adresu. To sprawia, że test jest zrozumiały i zapobiega sytuacji, w której na końcu nie wiadomo, która czynność pomogła.
4. Walidacja dostępności
Po pingu ARP należy powtórzyć ten sam test:
- Ping lub test portu TCP z zewnątrz.
- Packet Capture na interfejsie WAN.
- Filtruj w Log Viewer na dotknięty adres docelowy.
- Sprawdź reguły NAT i zapory, jeśli pakiety teraz docierają.
Jeśli upstream poprawnie nauczy się informacji ARP, pakiety dla adresu IP aliasu powinny teraz docierać do nowej zapory. Czy opublikowana usługa działa, zależy dodatkowo od NAT, reguł zapory, wewnętrznego serwera i trasy zwrotnej.
Jeśli ping ARP nie pomaga
Jeśli ping ARP nie przynosi poprawy, nie należy próbować dowolnych innych poleceń. Wtedy sensowne jest strukturalne ograniczenie problemu.
Dalsze kontrole:
- Urządzenie upstream może nadal przechowywać przestarzałe wpisy ARP.
- Dostawca musi ponownie załadować pamięć podręczną ARP lub urządzenie CPE.
- Adres IP aliasu znajduje się na niewłaściwym interfejsie lub w niewłaściwej sieci.
- Publiczny adres IP jest routowany przez dostawcę zamiast być bezpośrednio nauczonym w lokalnym segmencie przez ARP.
- Reguła DNAT wskazuje na niewłaściwy publiczny adres.
- Reguła zapory nie pozwala na ruch.
- Wewnętrzny serwer odpowiada przez inną bramę.
- Przy HA lub zmianie sprzętu oczekiwano niewłaściwego adresu MAC.
Ponowne uruchomienie urządzenia CPE dostawcy lub routera przed zaporą może wyczyścić pamięci podręczne ARP, ale nie powinno być pierwszym krokiem. W środowiskach produkcyjnych lepiej jest najpierw zebrać dowody za pomocą Packet Capture i Log Viewer.
Celowe zaangażowanie dostawcy lub upstream
Jeśli na interfejsie WAN nie pojawiają się pakiety dla dotkniętego publicznego adresu IP, zapytanie do dostawcy lub odpowiedzialnych za upstream powinno być jak najbardziej konkretne. Ogólne zgłoszenie typu “zapora jest niedostępna” często prowadzi do niepotrzebnych pętli. Lepiej jest krótki dowód techniczny, który pokazuje, który adres IP jest dotknięty i co zostało sprawdzone na Sophos Firewall.
Przydatne informacje:
- Dotknięty publiczny adres IP lub adres IP aliasu: Dostawca może celowo sprawdzić wpis ARP lub routing.
- Interfejs WAN i nowy adres MAC: Pokazuje, jakie przypisanie jest oczekiwane po migracji.
- Brama upstream lub adres CPE: Ogranicza, które urządzenie sąsiednie musi nauczyć się adresu.
- Czas testu pingu ARP: Ułatwia porównanie z logami dostawcy lub stanem CPE.
- Wynik Packet Capture: Dowodzi, czy pakiety w ogóle docierają do Sophos Firewall.
- Sprawdzone reguły DNAT i zapory: Zapobiega, aby przypadek został przedwcześnie uznany za lokalny problem z regułami. Adres MAC interfejsu WAN można udokumentować w interfejsie WebAdmin pod Network > Interfaces. Jeśli dostawca musi wyczyścić pamięć podręczną ARP lub ponownie załadować urządzenie CPE, powinno to być związane z konkretnym adresem IP lub dotkniętym interfejsem. Ogólny restart wszystkich zaangażowanych urządzeń ma sens tylko wtedy, gdy odpowiedzialność, okno konserwacyjne i wpływ są jasne.
Lista kontrolna
- Udokumentowane dotknięte główne i aliasowe adresy IP.
- Sprawdzone interfejs, strefa, brama i konfiguracja aliasu.
- Sprawdzone reguły NAT i zapory dla dotkniętego adresu IP.
- Packet Capture pokazuje, czy pakiety docierają do interfejsu WAN.
- Ping ARP wykonany tylko z poprawnym źródłowym adresem IP, interfejsem i adresem docelowym.
- Zewnętrzna dostępność testowana ponownie po każdej zmianie.
- W razie potrzeby skontaktowano się z dostawcą lub odpowiedzialnymi za upstream z konkretnym adresem IP, adresem MAC, czasem testu i obserwacją Packet Capture.