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.
Med IPv4 använder en enhet en ARP-förfrågan för att fråga efter MAC-adressen som hör till en IP-adress. Svaret innehåller den koppling som brandväggen använder för att uppdatera sitt neighbor-cacheminne. Redan inlärda IP-MAC-kopplingar återanvänds för att minska broadcasttrafiken; för IPv6 utför NDP motsvarande grannupplösning.
Dynamiska neighbor-poster lärs in och uppdateras löpande. Den dokumenterade standardtidsgränsen för ARP- och NDP-förfrågningar är 600 sekunder (10 minuter). Detta garanterar inte att varje enskild post försvinner efter exakt 600 sekunder: cacheminnena finns kvar tills de töms automatiskt eller manuellt. Därefter kan brandväggen lära in aktuella kopplingar på nytt. En inaktuell post kan till exempel uppstå efter byte av enhet, nätverkskort eller VM. 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.
För XML-automation: XML-referensen för SFOS 22.0 och 23.0 beskriver parametern ARPCacheEntryTimeOut under ARPConfiguration som ett intervall för cachetömning: dokumenterat standardvärde 2 minuter, intervall 1–500; i exemplet anges Minutes. Detta är referensvärden, inte belägg för ett aktuellt körningsvärde eller för att det rör sig om samma inställning som i UI-hjälpen, där 600 sekunder anges för ARP- och NDP-förfrågningar. Denna IPv4-ARP-entitet belägger inte heller någon generell konfiguration av alla IPv6-NDP-egenskaper. Använd inget av dessa dokumentationsvärden som ett automatiskt återställnings- eller justeringsvärde: det avgörande är det aktuella värde som registreras före en ändring och som återställs exakt när ändringen återtas; därefter kontrolleras den ursprungliga tjänsten på nytt.
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.
Gränsdragning för XML-API: Get Dynamic Neighbour Entries läser poster för kontroll; Flush All Dynamic Entries tar bort dynamiska cacheposter, inte en enskild statisk post. Referensen för SFOS 22.0 och 23.0 anger det valfria skalära IPFamily med IPv4 och IPv6, men inget standardvärde. Det går inte att härleda om en utelämnad parameter väljer en av familjerna, båda eller någon annan omfattning. Ingen av de två versionerna innehåller någon förfrågningspayload; parametertabellen ger därför ingen körbar operationsförfrågan. Använd den befintliga GUI-proceduren för kontroll och tömning med ett uttryckligt val av IP-familj. Varningen gäller fortfarande: Flush tömmer hela det valda cacheminnet.
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. Vid en förfrågan på den aktuella porten kontrollerar brandväggen först den statiska neighbor-tabellen och tar vid lagring bort dynamiska referenser för samma IP-adress. Om en statisk post saknas kontrollerar den neighbor-cacheminnena och lägger till MAC-adressen vid behov. För ett statiskt bundet IP-MAC-par svarar brandväggen inte på någon annan port. 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 lägger 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 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.
Gränsdragning mot Add/Edit-API
Add/Edit-referensen för statiska neighbor-poster i SFOS 22.0 och 23.0 beskriver ett separat API-kontrakt, inte timeout-entiteten ARPConfiguration som förklaras ovan. Den kräver neighname för den sparade respektive valda neighbor-identiteten; neighid är däremot valfritt. Båda ska skiljas från IPAddress, MACAddress och Interface. GUI-värdena för IP, MAC och fysisk port ger varken denna identitet eller en körbar JSON- eller XML-förfrågan. Referensen beskriver åtgärden som JSON men visar inget exempel som säkert klargör formatet eller identitetskopplingen; härled därför ingen identifierare från GUI-värdena.
Även adressuppgifterna är motsägelsefulla: det obligatoriska IPFamily tillåter IPv4 och IPv6, medan IPAddress begränsas till IPADDRESS med högst 15 tecken och IPv4-präglade adressklasser. Det går inte att härleda någon tillförlitlig IPv6-kodning från detta; det motbevisar inte heller IPv6-stödet i GUI-proceduren som beskrivs ovan. För det valfria AddAsATrustedMACAddress anger referensen endast Enable. Det belägger varken ett Disable-värde eller effekten av att utelämna parametern. Valet av betrodd MAC-adress förblir ett medvetet beslut, och en kvarvarande betrodd MAC-post tas bort separat enligt beskrivningen ovan. Så länge identiteten, förfrågningsformatet och IPv6-adresschemat är oklara för den specifika SFOS-versionen används det befintliga GUI:t för att skapa eller redigera poster i stället för en API-förfrågan baserad på gissningar.
Delete Static ARP Entry är en separat åtgärd: referensen för SFOS 22.0 och 23.0 kräver IPAddress för att identifiera posten, inte Add/Edit-kontraktet med neighname och neighid. Begränsningen till IPADDRESS, högst 15 tecken och IPv4-präglade adressklasser fastställer ingen tillförlitlig representation för IPv6-borttagning. Ingen av de två versionerna innehåller något exempel på en borttagningsförfrågan eller någon statustabell; inget förfrågningsformat, ingen borttagningspayload och inget resultatkontrakt härleds. Använd det befintliga GUI:t för att välja och ta bort endast den avsedda sparade statiska posten i stället för att gissa en API-förfrågan för borttagning. Fortsätt att kontrollera och separat ta bort en eventuell motsvarande kvarvarande betrodd MAC-post enligt beskrivningen ovan; kaskadborttagning är inte garanterad.
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.
En bindning per IP-adress betyder inte att en MAC-adress bara får höra till en IP-adress. I IPv4-ARP-exemplet är IP1 och IP2 båda bundna till MAC1 och port A. Om varje IP-adress visas med MAC1 på port A är det inte ett försök till neighbor poisoning. Det avgörande är att varje IP-MAC-portkombination stämmer med sin egen statiska bindning.
I samma exempel klassificeras inte heller IP3 med MAC1, utan någon statisk ARP-post för IP3, som ett försök till neighbor poisoning. Att dela MAC-adress skapar alltså inte i sig en konflikt med bindningarna för IP1 eller IP2. Dessa exempel förklarar kontrollen av statiska ARP-bindningar; de är inget allmänt godkännande av trafikens säkerhet.
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.