Sprawdzanie cache sąsiadów ARP i NDP w Sophos Firewall
Jeśli urządzenie jest nieosiągalne mimo poprawnego adresu IP, przyczyną nie musi być błędna reguła firewalla ani trasa. W sieci lokalnej Sophos Firewall potrzebuje również właściwego adresu MAC celu. To powiązanie przechowuje w cache sąsiadów.
W sekcji Network > Neighbors (ARP–NDP) można sprawdzić, jaki adres IP jest obecnie powiązany z określonym adresem MAC i interfejsem. Najpierw należy udokumentować istniejący wpis i porównać go z rzeczywistym stanem sieci. Dopiero gdy powiązanie jest nieaktualne, opróżnia się odpowiednią pamięć cache i pozwala firewallowi ponownie nauczyć się właściwego powiązania.
Nazwy i polecenia w tej procedurze odnoszą się do SFOS 22.0. Diagnostykę należy rozpocząć w WebAdmin, a Device Console używać tylko do dodatkowych kontroli wyraźnie opisanych poniżej.
⚠️ Flush opróżnia wybraną pamięć cache IPv4 lub IPv6, a nie tylko pojedynczy wiersz. Na produkcyjnym firewallu należy więc najpierw zachować bieżący wpis, ograniczyć zakres testu i nie opróżniać pamięci cache w czasie szczytowego obciążenia.
Jak działają ARP, NDP i cache sąsiadów
ARP przypisuje adres IPv4 do adresu MAC w lokalnym segmencie Layer 2. Chodzi o bezpośrednio osiągalne urządzenie, zazwyczaj w tym samym VLAN-ie. W przypadku IPv6 tę funkcję realizuje Neighbor Discovery Protocol (NDP) za pomocą ICMPv6. Firewall potrzebuje tych informacji, zanim wyśle pakiet przez bezpośrednio podłączony interfejs do następnego sąsiada.
Dynamicznie nauczone powiązania pozostają domyślnie w pamięci cache przez 600 sekund. Następnie w razie potrzeby są uczone ponownie. Nieaktualny wpis może powstać na przykład po wymianie urządzenia lub karty sieciowej albo po zmianie maszyny wirtualnej. Z kolei zduplikowany adres IP może powodować powtarzające się zmiany widocznego adresu MAC.
W polu Neighbor cache entry timeout można zmienić interwał automatycznego czyszczenia i zatwierdzić go przyciskiem Apply. Krótsza wartość wymusza częstsze ponowne uczenie i nie naprawia zduplikowanych adresów IP, błędnych sieci VLAN ani nieaktualnych powiązań statycznych. Przed zmianą należy zapisać wartość początkową. Jeśli test nie przyniesie korzyści, trzeba ponownie wpisać dokładnie tę wartość, kliknąć Apply i przetestować rzeczywistą ścieżkę danych.
Cache sąsiadów dotyczy wyłącznie bezpośrednio osiągalnych urządzeń w danym segmencie Layer 2. Dla odległego celu firewall nie zapisuje adresu MAC serwera docelowego, lecz adres MAC następnego routera.
To nie jest to samo co Proxy ARP: w takim przypadku zapora odpowiada na interfejsie w imieniu innego adresu docelowego na dotyczące go zapytanie ARP IPv4. Ten szczególny przypadek opisano osobno w artykule Konfiguracja i testowanie Proxy ARP na Sophos Firewall.
Rozpoznawanie ARP flux na wielu interfejsach
ARP flux może wystąpić, gdy wiele fizycznych interfejsów Ethernet Sophos Firewall jest podłączonych do tego samego medium warstwy 2 lub tej samej broadcast domain. Zapora może wtedy odpowiedzieć na jedno żądanie ARP przez oba interfejsy, a urządzenie wysyłające żądanie widzi zmienne lub nieoczekiwane powiązania MAC. Dwa oddzielne VLAN-y, nieprawidłowo skonfigurowany LAG lub zwykły zduplikowany adres IP nie oznaczają automatycznie ARP flux.
Krótki packet capture służy wyłącznie do sprawdzenia zachowania ARP: należy ustalić, czy to samo żądanie dociera do obu portów fizycznych i czy odpowiadają oba interfejsy zapory. Capture nie pokazuje skonfigurowanej wartości arp-flux.
Do Device Console można uzyskać dostęp przez konsolę lokalną lub SSH. Wymagania i dostęp przez SSH opisano w artykule Łączenie z Sophos Firewall przez SSH. Po zalogowaniu należy wybrać Option 4: Device Console. Przed jakąkolwiek zmianą trzeba wykonać miarodajną kontrolę wstępną dla SFOS 22.0:
show arp-flux
Należy zapisać dokładną zwróconą wartość: on albo off. Ustawienie jest globalne, a nie przypisane do pojedynczego interfejsu. Można je zmienić tylko tymczasowo, gdy oba interfejsy celowo współdzielą tę samą broadcast domain, capture potwierdza problematyczne zachowanie, a bieżąca wartość wymaga zmiany. Jeśli zapisano on, w oknie serwisowym testuje się tryb odpowiedzi właściwy dla interfejsu poleceniem:
set arp-flux off
Przy off zapora odpowiada na żądania ARP przez odpowiedni interfejs Ethernet. Następnie obiema ścieżkami sprawdza się osiągalność, wpisy sąsiadów, pierwotną usługę oraz zachowanie ARP w nowym capture.
Po teście, niezależnie od wyniku, należy przywrócić dokładnie wartość zapisaną z show arp-flux. Jeśli wartością początkową było on, wykonuje się:
set arp-flux on
Jeśli wartością początkową było off, zamiast tego wykonuje się:
set arp-flux off
Należy ponownie wykonać show arp-flux, aby potwierdzić przywróconą wartość, a następnie powtórzyć testy ścieżek. Packet capture służy wyłącznie do sprawdzenia wynikającego z ustawienia zachowania.
Jeśli nie ma dowodu na wspólną broadcast domain lub problem pozostaje bez zmian przy off, nie należy zmieniać kolejnych ustawień ARP na podstawie przypuszczeń. Trzeba wrócić do analizy VLAN-u, bridge, LAG-u, tablicy MAC switcha, okablowania i zduplikowanych adresów IP.
Najpierw sprawdź cache sąsiadów
- Otworzyć Network > Neighbors (ARP–NDP).
- W polu Show wybrać IPv4 neighbor cache albo IPv6 neighbor cache.
- Wyszukać odpowiedni adres IP.
- Zanotować adres IP, adres MAC i interfejs.
- W Static neighbor table wykluczyć istnienie stałego, lecz błędnego powiązania dla tego samego adresu IP.
- Porównać adres MAC z urządzeniem końcowym, hiperwizorem, switchem lub następnym routerem.
Interfejs jest równie ważny jak adres MAC. Prawidłowe powiązanie IP-MAC widoczne na niewłaściwym porcie często wskazuje na problem z VLAN-em, bridge, LAG-em lub okablowaniem. Oczekiwany adres MAC można znaleźć na przykład w informacjach sieciowych urządzenia końcowego, w tablicy MAC switcha albo na bezpośrednio połączonym routerze. Jeśli wpisu w ogóle nie ma, należy wysłać z firewalla ukierunkowany ping do odpowiedniego adresu IP, a następnie ponownie sprawdzić widok.
Dla IPv4 i IPv6 udokumentowanym punktem kontroli są dwa widoki pamięci cache w WebAdmin. Pokazują interfejs obok adresu i zapobiegają omyłkowemu odnoszeniu obserwacji IPv4 do problemu IPv6.
Kontrolowane ponowne uczenie nieaktualnego powiązania
Opróżnienie pamięci cache jest krokiem diagnostycznym, a nie trwałą naprawą. Nie usuwa również błędnego statycznego powiązania. Usuniętych wpisów dynamicznych nie można bezpośrednio przywrócić; firewall uczy się ich ponownie z nowego ruchu. Jeśli to samo nieprawidłowe powiązanie pojawia się ponownie, przyczyna nadal znajduje się w sieci.
- Udokumentować bieżący adres IP, adres MAC i interfejs.
- Odtworzyć błąd za pomocą pojedynczego pingu lub próby połączenia.
- Przy podejrzeniu zduplikowanego adresu IP lub manipulacji najpierw zachować aktualny stan i krótki capture. Natychmiastowy flush usunąłby tę wskazówkę.
- W polu Show wybrać odpowiednią pamięć cache IPv4 lub IPv6.
- Kliknąć Flush. Spowoduje to opróżnienie wybranej pamięci cache.
- Ponownie wygenerować ukierunkowany ruch z odpowiedniego urządzenia.
- Sprawdzić, jaki adres MAC i interfejs zostały nauczone ponownie.
- Ponownie przetestować pierwotną usługę z tym samym źródłem i celem.
W kontrolowanym teście z Device Console można na przykład wysłać cztery pakiety do udokumentowanego adresu docelowego:
ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4
Adresy są przykładami i należy je zastąpić rzeczywistym celem IPv4 lub IPv6. Udany ping potwierdza jedynie podstawową osiągalność; następnie nadal trzeba przetestować usługę, która pierwotnie nie działała.
Podczas ponownego uczenia mogą wystąpić krótkie opóźnienia. Znaczne skrócenie timeoutu dla wszystkich wpisów rzadko jest najlepszym rozwiązaniem: firewall musi wtedy częściej ponownie rozwiązywać sąsiadów, ale nie usuwa to zduplikowanego adresu IP ani błędnego portu switcha.
Jeśli po wykonaniu flush tylko publiczny adres IP nadal nie przechodzi na nowy adres MAC firewalla, nieaktualny wpis prawdopodobnie znajduje się u operatora lub na routerze przed firewallem. Osobną procedurę opisano w artykule Rozwiązywanie problemów ARP po migracji firewalla.
Statyczny wpis sąsiada tylko dla stałych powiązań
Statyczny wpis sąsiada trwale wiąże adres IP z adresem MAC i fizycznym interfejsem. Dla jednego adresu IP może istnieć tylko jedno takie powiązanie. Firewall sprawdza wpisy statyczne przed dynamiczną pamięcią cache, a podczas zapisywania usuwa dynamiczne odwołania do tego samego adresu IP. Jeśli później adres IP, adres MAC lub port przestanie się zgadzać, połączenie może przestać działać mimo poprawnej konfiguracji urządzenia końcowego.
Statyczne wpisy są więc odpowiednie dla stabilnych systemów, takich jak podłączone na stałe urządzenie infrastruktury ze stałym adresem IP. Zazwyczaj nie nadają się dla klientów DHCP, urządzeń mobilnych, zmian HA lub VM ani zmiennych portów switcha.
W sekcji Network > Neighbors (ARP–NDP) wyświetlić Static neighbor table i wybrać Add. Następnie ustawić następujące wartości:
- IP version: wybrać IPv4 lub IPv6.
- IPv4/IPv6 address: wpisać stały adres urządzenia.
- MAC address: wpisać rzeczywisty adres MAC tego urządzenia.
- Interface: wybrać fizyczny interfejs, przez który sąsiad jest osiągalny.
Udokumentowany przykład może używać wartości 192.0.2.10, 02:00:00:00:00:10 i Port1. Są to wartości zastępcze, które trzeba w całości zamienić na rzeczywisty adres IP, adres MAC i port.
Przed zapisaniem należy odnotować, czy wybrano opcję Add as a trusted MAC address to prevent a spoofing attempt. Należy ją włączyć tylko wtedy, gdy ta strategia ochrony jest stosowana świadomie, ponieważ późniejsza zmiana VM, NIC lub portu może zostać pokazana jako uzasadniony konflikt. Współdziałanie zaufanych wpisów MAC z sieciami dynamicznymi, DHCP i wirtualizacją opisano w artykule Sprawdzanie Spoof Protection i DoS Settings w Sophos Firewall.
Kliknąć Save, aby utworzyć powiązanie, a następnie przetestować dokładnie to urządzenie. Podczas wycofywania testu usunąć nowy wpis z Static neighbor table, wygenerować ukierunkowany ruch i sprawdzić dynamicznie nauczone powiązanie. Następnie otworzyć Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Jeśli pozostał tam odpowiedni zaufany wpis MAC utworzony na potrzeby tego testu, trzeba usunąć go osobno; nie należy zakładać, że usunięcie statycznego wpisu sąsiada usuwa również ten wpis. Trzeba też udokumentować, kto dostosuje zachowany wpis po zmianie sprzętu, adresu IP lub portu. Statyczne powiązanie bez przypisanej odpowiedzialności łatwo staje się później niewidoczną przyczyną błędu.
Sprawdzanie możliwych prób neighbor poisoning
Statyczne powiązanie definiuje oczekiwaną kombinację adresu IP, adresu MAC i interfejsu. Jeśli ten sam adres IP pojawi się z innym adresem MAC albo ta sama kombinacja IP-MAC zostanie wykryta na innym powiązanym porcie, firewall traktuje to jako możliwą manipulację i nie aktualizuje pamięci cache odmiennym powiązaniem.
W sekcji Network > Neighbors (ARP–NDP) można włączyć Log possible neighbor poisoning attempts i zapisać ustawienie przyciskiem Apply. Przed testem ograniczonym w czasie należy zapisać, czy pole wyboru jest zaznaczone, a po teście przywrócić ten widoczny stan. Opcja pomaga w diagnostyce, ale nie oznacza, że każde odchylenie należy od razu uznać za atak. Konflikt może również spowodować zduplikowany adres IP, wymieniona karta sieciowa, przeniesiona maszyna wirtualna lub zmiana portu.
Odrzucone pakiety IPv4 ARP można wyświetlić w Device Console podczas krótkiego testu:
drop-packet-capture 'arp'
Przy wielu interfejsach można ograniczyć wyjście do jednego fizycznego portu:
drop-packet-capture interface Port1 'arp'
Port1 jest przykładem i należy go zastąpić odpowiednim interfejsem. Następnie jednokrotnie odtworzyć błąd i zakończyć bieżące wyjście za pomocą Ctrl+C. Filtr pokazuje wyłącznie odrzucone pakiety ARP i nie jest trwałym archiwum logów. Dla IPv6 NDP lub ogólnej analizy pakietów należy użyć Packet Capture w WebAdmin i precyzyjnie ograniczyć źródło, cel, protokół oraz interfejs.
Interpretacja typowych objawów
- Po wymianie urządzenia lub NIC cel pozostaje nieosiągalny: porównać stary i ponownie nauczony adres MAC, opróżnić pamięć cache w kontrolowany sposób i ponowić test.
- Adres MAC zmienia się wielokrotnie: sprawdzić zduplikowany adres IP, dzierżawę DHCP, klon VM lub zachowanie HA. Statyczny wpis jedynie ukryłby rzeczywisty konflikt.
- Powiązanie pojawia się na niewłaściwym interfejsie: sprawdzić VLAN, bridge, LAG, port switcha i okablowanie.
- Statycznie powiązane urządzenie przestaje działać po przebudowie: porównać adres IP, adres MAC i fizyczny port z powiązaniem, a następnie świadomie dostosować lub usunąć wpis.
- Problem dotyczy tylko IPv6: sprawdzić IPv6 neighbor cache, Router Advertisements, VLAN i ścieżkę ICMPv6. Polecenie IPv4 ARP nie stanowi tutaj dowodu.
- Pakiety docierają do firewalla, ale usługa nadal nie działa: osobno sprawdzić regułę firewalla, NAT, routing i ścieżkę powrotną. Cache sąsiadów potwierdza jedynie lokalne dostarczenie w Layer 2.
Kontrola końcowa
- Udokumentowano odpowiedni adres IP, oczekiwany adres MAC i interfejs.
- Cache IPv4 lub IPv6 sprawdzono przed wprowadzeniem zmiany.
- W razie potrzeby opróżniono dokładnie wybraną pamięć cache i wygenerowano ukierunkowany ruch.
- Ponownie nauczone powiązanie porównano z urządzeniem końcowym, switchem, hiperwizorem lub routerem.
- Statycznego powiązania użyto tylko przy trwale stabilnej kombinacji adresu IP, adresu MAC i portu.
- Odróżniono ostrzeżenie o poisoning od zduplikowanego adresu IP, wymiany urządzenia i zmian sieciowych.
- Po sprawdzeniu Layer 2 ponownie przetestowano pierwotną usługę.