Kontrollera ARP- och NDP-neighbor-cache på Sophos Firewall

Om en enhet inte kan nås trots korrekt IP-adress behöver felet inte ligga i en brandväggsregel eller routing. I det lokala nätverket behöver Sophos Firewall även rätt MAC-adress för målet. Den här kopplingen lagras i neighbor-cacheminnet.

Under Network > Neighbors (ARP–NDP) går det att kontrollera vilken IP-adress som för närvarande hör till en viss MAC-adress och ett visst interface. Dokumentera först den befintliga posten och jämför den med den faktiska nätverkssituationen. Endast om kopplingen är inaktuell töms det berörda cacheminnet så att kopplingen kan läras in på nytt.

Benämningarna och kommandona i proceduren gäller för SFOS 22.0. Börja diagnostiken i WebAdmin och använd Device Console endast för de kompletterande kontroller som uttryckligen beskrivs nedan.

⚠️ Flush tömmer det valda IPv4- eller IPv6-cacheminnet, inte bara en enskild rad. På en produktionsbrandvägg bör den aktuella posten därför dokumenteras först, testet avgränsas och cacheminnet inte tömmas under en belastningstopp.

Vad ARP, NDP och neighbor-cacheminnet gör

ARP kopplar en IPv4-adress till en MAC-adress i det lokala Layer 2-segmentet. Det innebär en direkt nåbar enhet, vanligtvis i samma VLAN. För IPv6 sköter Neighbor Discovery Protocol (NDP) denna uppgift med ICMPv6. Brandväggen behöver informationen innan den kan skicka ett paket via ett direkt anslutet interface till nästa neighbor.

Dynamiskt inlärda kopplingar ligger som standard kvar i cacheminnet i 600 sekunder. Därefter lärs de in på nytt vid behov. En inaktuell post kan till exempel uppstå efter byte av enhet eller nätverkskort eller efter en VM-förändring. En dubbelt tilldelad IP-adress kan däremot medföra att den synliga MAC-adressen ändras upprepade gånger.

Under Neighbor cache entry timeout kan intervallet för automatisk tömning ändras och tillämpas med Apply. Ett kortare värde tvingar fram tätare ominlärning och löser inte dubbla IP-adresser, felaktiga VLAN eller inaktuella statiska kopplingar. Dokumentera ursprungsvärdet före ändringen. Om testet inte hjälper återställs exakt detta värde, Apply väljs och den verkliga datavägen testas igen.

Neighbor-cacheminnet gäller endast direkt nåbara neighbors i respektive Layer 2-segment. För ett avlägset mål lagrar brandväggen inte målserverns MAC-adress utan MAC-adressen för nästa router.

Det är inte samma sak som Proxy ARP: då besvarar brandväggen ARP-förfrågan för en annan IPv4-måladress i dess ställe på ett gränssnitt. Detta specialfall behandlas separat i Konfigurera och testa Proxy ARP på Sophos Firewall.

Identifiera ARP flux över flera gränssnitt

ARP flux kan uppstå när flera fysiska Ethernet-gränssnitt på Sophos Firewall är anslutna till samma Layer 2-medium eller broadcast domain. Brandväggen kan då svara på en ARP-förfrågan via båda gränssnitten, vilket gör att den frågande enheten ser växlande eller oväntade MAC-mappningar. Två separata VLAN, en felkonfigurerad LAG eller en vanlig duplicerad IP-adress är inte automatiskt ARP flux.

En kort packet capture används endast för att verifiera ARP-beteendet: kontrollera om samma förfrågan når båda de fysiska portarna och om båda brandväggsgränssnitten svarar. En capture visar inte det konfigurerade värdet för arp-flux.

Device Console nås via den lokala konsolen eller SSH. Förutsättningar och SSH-åtkomst beskrivs i Anslut till Sophos Firewall via SSH. Välj Option 4: Device Console efter inloggningen. Kör den auktoritativa förkontrollen för SFOS 22.0 före varje ändring:

show arp-flux

Dokumentera det exakta returnerade värdet, on eller off. Inställningen är global och gäller inte bara ett gränssnitt. Ändra den endast tillfälligt när båda gränssnitten avsiktligt delar samma broadcast domain, en capture bekräftar det problematiska beteendet och det aktuella värdet kräver en ändring. Om on dokumenterades testas det gränssnittsspecifika svarsläget under ett underhållsfönster med:

set arp-flux off

Med off besvarar brandväggen ARP-förfrågningar via motsvarande Ethernet-gränssnitt. Kontrollera sedan nåbarhet, neighbor-poster, den ursprungliga tjänsten och ARP-beteendet med en ny capture över båda vägarna.

Återställ efter testet exakt det värde som dokumenterades med show arp-flux, oavsett testresultat. Om ursprungsvärdet var on körs:

set arp-flux on

Om ursprungsvärdet var off körs i stället:

set arp-flux off

Kör show arp-flux igen för att bekräfta det återställda värdet och upprepa sedan vägtesterna. Använd packet capture endast för att verifiera det resulterande beteendet.

Om det saknas bevis för en gemensam broadcast domain eller om felet är oförändrat med off bör inga fler ARP-inställningar ändras på antaganden. Återgå då till att analysera VLAN, bridge, LAG, switchens MAC-tabell, kablage och duplicerade IP-adresser.

Kontrollera neighbor-cacheminnet först

Öppna Network > Neighbors (ARP–NDP).
Välj IPv4 neighbor cache eller IPv6 neighbor cache under Show.
Sök efter den berörda IP-adressen.
Dokumentera IP-adress, MAC-adress och interface.
Kontrollera under Static neighbor table att det inte finns en fast men felaktig bindning för samma IP-adress.
Jämför MAC-adressen med slutenheten, hypervisorn, switchen eller nästa router.

Interfacet är lika viktigt som MAC-adressen. En korrekt IP-MAC-koppling på fel port tyder ofta på ett problem med VLAN, bridge, LAG eller kablage. Den förväntade MAC-adressen finns till exempel i slutenhetens nätverksinformation, i switchens MAC-tabell eller på den direkt anslutna routern. Om posten saknas helt skickas en riktad ping från brandväggen till den berörda IP-adressen. Kontrollera därefter vyn igen.

För både IPv4 och IPv6 är de två cachevyerna i WebAdmin den dokumenterade kontrollpunkten. De visar både adress och interface och förhindrar att en IPv4-observation av misstag tillämpas på ett IPv6-problem.

Kontrollerad ominlärning av en inaktuell koppling

Att tömma cacheminnet är ett diagnostiksteg, inte en permanent lösning. Det tar inte heller bort en felaktig statisk bindning. Det finns ingen direkt rollback för borttagna dynamiska poster; brandväggen lär in dem på nytt från ny trafik. Om samma felaktiga koppling återkommer finns orsaken fortfarande kvar i nätverket.

Dokumentera aktuell IP-adress, MAC-adress och interface.
Återskapa felet med en enstaka ping eller ett anslutningsförsök.
Vid misstanke om en dubblerad IP-adress eller manipulation ska det aktuella tillståndet och en kort capture sparas först. En omedelbar flush skulle ta bort den här ledtråden.
Välj det berörda IPv4- eller IPv6-cacheminnet under Show.
Klicka på Flush. Det valda cacheminnet töms.
Generera på nytt riktad trafik från den berörda enheten.
Kontrollera vilken MAC-adress och vilket interface som lärdes in på nytt.
Testa den ursprungliga tjänsten igen med samma källa och mål.

För ett kontrollerat test från Device Console kan exempelvis fyra paket skickas till en dokumenterad måladress:

ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4

Adresserna är exempel och ersätts med det faktiska IPv4- eller IPv6-målet. En lyckad ping bekräftar endast grundläggande nåbarhet. Därefter måste den tjänst som ursprungligen hade problem fortfarande testas.

Under den nya inlärningen kan korta fördröjningar uppstå. Att generellt förkorta timeouten kraftigt är sällan den bästa lösningen: brandväggen måste då slå upp neighbors oftare, utan att en dubblerad IP-adress eller felaktig switchport åtgärdas.

Om endast en offentlig IP-adress efter flush fortfarande inte växlar till brandväggens nya MAC-adress finns den inaktuella posten sannolikt hos leverantören eller på en framförliggande router. För detta finns den separata proceduren Åtgärda ARP-problem efter en brandväggsmigrering.

Skapa endast en statisk neighbor för fasta kopplingar

En statisk neighbor binder permanent en IP-adress till en MAC-adress och ett fysiskt interface. Det kan bara finnas en sådan bindning per IP-adress. Brandväggen kontrollerar statiska poster före det dynamiska cacheminnet och tar vid lagring bort dynamiska referenser för samma IP-adress. Om IP-adress, MAC-adress eller port senare inte längre stämmer kan anslutningen sluta fungera trots att slutenheten är korrekt konfigurerad.

Statiska poster passar därför för stabila system, exempelvis en fast ansluten infrastrukturenhet med fast IP-adress. De är oftast olämpliga för DHCP-klienter, mobila enheter, HA- eller VM-förändringar och växlande switchportar.

Visa Static neighbor table under Network > Neighbors (ARP–NDP) och välj Add. Ange sedan följande värden:

IP version: välj IPv4 eller IPv6.
IPv4/IPv6 address: ange enhetens fasta adress.
MAC address: ange den faktiska MAC-adressen för enheten.
Interface: välj det fysiska interface som används för att nå den direkt anslutna enheten.

Ett dokumenterat exempel kan använda 192.0.2.10, 02:00:00:00:00:10 och Port1. Dessa värden är platshållare och måste ersättas helt med den verkliga IP-adressen, MAC-adressen och porten.

Dokumentera före lagringen om Add as a trusted MAC address to prevent a spoofing attempt är markerat. Alternativet bör bara aktiveras när denna skyddsstrategi används medvetet, eftersom ett senare byte av VM, NIC eller port då kan visas som en legitim konflikt. Hur betrodda MAC-poster fungerar tillsammans med dynamiska nätverk, DHCP och virtualisering beskrivs i Kontrollera Spoof Protection och DoS Settings på Sophos Firewall.

Välj Save för att skapa bindningen och testa sedan just den berörda enheten. Vid rollback av testet tas den nya posten bort från Static neighbor table. Generera därefter riktad trafik och kontrollera den dynamiskt inlärda kopplingen. Öppna sedan Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Om en motsvarande betrodd MAC-post som skapades för testet finns kvar tas den bort separat; anta inte att borttagningen av den statiska neighbor-posten även tar bort den. Det bör även dokumenteras vem som anpassar en behållen post vid byte av maskinvara, IP-adress eller port. En statisk bindning utan ett sådant ansvar blir senare lätt en osynlig felorsak.

Kontrollera möjliga försök till neighbor poisoning

En statisk bindning definierar den förväntade kombinationen av IP-adress, MAC-adress och interface. Om samma IP-adress visas med en annan MAC-adress eller om samma IP-MAC-kombination visas på en annan bunden port behandlar brandväggen detta som möjlig manipulation och uppdaterar inte cacheminnet med den avvikande kopplingen.

Under Network > Neighbors (ARP–NDP) kan Log possible neighbor poisoning attempts aktiveras och sparas med Apply. Dokumentera före ett tidsbegränsat test om kryssrutan är markerad och återställ detta synliga tillstånd efteråt. Alternativet underlättar diagnostiken men innebär inte att varje avvikelse omedelbart ska bedömas som en attack. Även en dubblerad IP-adress, ett utbytt nätverkskort, en flyttad VM eller ett portbyte orsakar en konflikt.

Kasserade IPv4-ARP-paket kan visas i Device Console under ett kort test:

drop-packet-capture 'arp'

Vid många interfaces kan utdata begränsas till en fysisk port:

drop-packet-capture interface Port1 'arp'

Port1 är ett exempel och ersätts med det berörda interfacet. Återskapa därefter felet en gång och avsluta den löpande utdatan med Ctrl+C. Filtret visar endast kasserade ARP-paket och är inget permanent loggarkiv. För IPv6 NDP eller en allmän paketanalys används Packet Capture i WebAdmin, där källa, mål, protokoll och interface avgränsas specifikt.

Tolka vanliga felsymtom

Efter byte av enhet eller NIC kan målet fortfarande inte nås: jämför det gamla och det nyinlärda MAC-värdet, töm cacheminnet under kontroll och testa igen.
MAC-adressen ändras upprepade gånger: kontrollera dubblerad IP-adress, DHCP-lease, VM-klon eller HA-beteende. En statisk post skulle bara dölja den egentliga konflikten.
Kopplingen visas på fel interface: kontrollera VLAN, bridge, LAG, switchport och kablage.
En statiskt bunden enhet slutar fungera efter en ändring: jämför IP-adress, MAC-adress och fysisk port med bindningen och anpassa eller ta bort posten medvetet.
Endast IPv6 påverkas: kontrollera IPv6 neighbor cache, Router Advertisements, VLAN och ICMPv6-sökvägen. Ett IPv4-ARP-kommando ger inget belägg för detta.
Paketen når brandväggen men tjänsten fungerar ändå inte: kontrollera brandväggsregel, NAT, routing och returväg separat. Neighbor-cacheminnet bekräftar endast lokal leverans på Layer 2.

Slutkontroll

Berörd IP-adress, förväntad MAC-adress och interface dokumenterade.
IPv4- eller IPv6-cacheminnet kontrollerat före en ändring.
Vid behov exakt det valda cacheminnet tömt och riktad trafik genererad.
Nyinlärd koppling jämförd med slutenhet, switch, hypervisor eller router.
Statisk bindning endast använd vid en permanent stabil kombination av IP-adress, MAC-adress och port.
Poisoning-indikation avgränsad mot dubblerad IP-adress, enhetsbyte och nätverksförändringar.
Den ursprungliga tjänsten testad igen efter Layer 2-kontrollen.

FAQ

Vad är skillnaden mellan ARP- och NDP-cache?

ARP löser IPv4-adresser till MAC-adresser. NDP utför denna neighbor-upplösning för IPv6 med ICMPv6. I Sophos Firewall hanteras båda vyerna under Network > Neighbors (ARP–NDP).

Kan neighbor-cacheminnet tömmas utan avbrott?

Posterna lärs automatiskt in på nytt genom ny trafik, men korta fördröjningar kan uppstå. Eftersom Flush tömmer hela det valda cacheminnet bör steget planeras, dokumenteras och utföras utanför en belastningstopp.

När är en statisk neighbor lämplig?

Endast när IP-adress, MAC-adress och fysiskt interface förblir permanent stabila och bindningen underhålls operativt. Vid DHCP, mobila enheter, VM-förändringar eller växlande portar är dynamisk inlärning oftast robustare.

Betyder en poisoning-varning automatiskt en attack?

Nej. Varningen visar i första hand en avvikelse från den förväntade kopplingen. Förutom en attack kan även dubblerade IP-adresser, byte av enhet eller NIC, flyttade virtuella maskiner och portändringar vara orsaken.