Hoppa till innehållet
Avanet

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.

⚠️ 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.

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.

Kontrollera neighbor-cacheminnet först

  1. Öppna Network > Neighbors (ARP–NDP).
  2. Välj IPv4 neighbor cache eller IPv6 neighbor cache under Show.
  3. Sök efter den berörda IP-adressen.
  4. Dokumentera IP-adress, MAC-adress och interface.
  5. Kontrollera under Static neighbor table att det inte finns en fast men felaktig bindning för samma IP-adress.
  6. 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 IPv4 kan den aktuella ARP-tabellen även visas i Device Console. Efter inloggning via SSH eller konsolen öppnas Option 4: Device Console, där följande körs:

system diagnostics utilities arp show

Kommandot läser endast av tillståndet. Det är särskilt användbart om WebAdmin inte kan nås eller om kopplingen snabbt behöver kontrolleras under ett test. För IPv6 är vyn IPv6 neighbor cache i WebAdmin fortfarande den tydliga kontrollpunkten. Åtkomsten beskrivs i Anslut till Sophos Firewall via SSH.

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. Om samma felaktiga koppling återkommer finns orsaken fortfarande kvar i nätverket.

  1. Dokumentera aktuell IP-adress, MAC-adress och interface.
  2. Återskapa felet med en enstaka ping eller ett anslutningsförsök.
  3. 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.
  4. Välj det berörda IPv4- eller IPv6-cacheminnet under Show.
  5. Klicka på Flush. Det valda cacheminnet töms.
  6. Generera på nytt riktad trafik från den berörda enheten.
  7. Kontrollera vilken MAC-adress och vilket interface som lärdes in på nytt.
  8. 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.

Alternativet Add as a trusted MAC address to prevent a spoofing attempt lägger även till IP-MAC-kopplingen i listan över betrodda MAC-adresser. Det 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 dessa bindningar fungerar tillsammans med dynamiska nätverk, DHCP och virtualisering beskrivs i Kontrollera Spoof Protection och DoS Settings på Sophos Firewall.

Efter lagring testas just den bundna enheten. Det bör även dokumenteras vem som anpassar posten 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. 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.