Konfigurera och testa Proxy ARP på Sophos Firewall

Proxy ARP behövs på en Sophos Firewall endast när en enhet i det direkt anslutna IPv4-segmentet söker efter en extra måladress via ARP och brandväggen ska svara i adressens ställe med sin egen MAC-adress. Detta kan exempelvis inträffa med en extra publik IP-adress som sedan vidarebefordras till en intern server via DNAT.

Den avgörande punkten är att Proxy ARP endast löser grannupplösningen före den egentliga IP-datavägen. Det skapar ingen brandväggsregel, NAT-regel eller returväg. Därför bekräftas först med en ARP-capture att just detta svar saknas. Först därefter läggs en enda Proxy ARP-post till och testas tillsammans med den verkliga tjänsten.

⚠️ Aktivera inte Proxy ARP i förebyggande syfte för ett helt publikt adressintervall. Dokumentera före ändringen leverantörens tilldelning, gränssnittet, det ursprungliga ARP-tillståndet, säkerhetskopian, en oberoende administrationsanslutning och rollback. En felaktig eller dubbelt använd måladress kan dra trafik till fel brandvägg.

Proxy ARP i åtta steg

Kontrollera med leverantören eller upstream-teamet om den extra IPv4-adressen söks via ARP i WAN-segmentet eller routas som ett prefix till brandväggen.
Uteslut att adressen redan används som alias, på en annan enhet eller i en befintlig konfiguration.
Gör en ARP-capture på det förväntade inkommande gränssnittet under en ny anslutning.
Fortsätt endast om ARP-förfrågan för måladressen kommer fram och brandväggens nödvändiga svar bevisligen saknas.
Lägg i Device Console till en post för exakt en IPv4-adress med set proxy-arp add.
Konfigurera eller kontrollera brandväggsregeln, DNAT eller routen samt returvägen separat.
Kontrollera ARP-svaret, Firewall Rule ID, NAT Rule ID och den verkliga tjänsten med en ny anslutning.
Upprepa samma test efter en HA-failover och vid rollback, och ta bort posten specifikt med set proxy-arp del.

Skilj mellan Proxy ARP, alias och routing

Vad Proxy ARP faktiskt gör

Innan en IPv4-enhet kan skicka ett paket till en granne i samma Layer 2-segment behöver den grannens MAC-adress. Därför skickar den en ARP-förfrågan. Med Proxy ARP besvarar Sophos Firewall en sådan förfrågan för en annan mål-IP-adress med MAC-adressen för det valda gränssnittet.

Upstream-enheten skickar då efterföljande Ethernet-ramar till brandväggen. Först därefter avgör routing, NAT och brandväggsregler vad som händer med IP-paketet. Ett lyckat ARP-svar bevisar därför ännu inte att en publicerad tjänst fungerar.

Det av Sophos dokumenterade kommandot för Device Console gäller ARP och därmed IPv4. För IPv6 sköter Neighbor Discovery grannupplösningen. Något Proxy NDP-förfarande kan inte härledas från detta kommando.

Vilken variant som passar leverantörens tilldelning

Alias-IP: Den extra adressen binds lokalt till ett fysiskt brandväggsgränssnitt. Det passar när brandväggen själv ska äga adressen eller använda den specifikt för NAT eller systemtrafik. Hela proceduren finns i Konfigurera en alias-IP på Sophos Firewall.
Proxy ARP: Brandväggen svarar på ARP-förfrågan för en vidarebefordrad eller översatt IPv4-adress. Kommandot skapar inte adressen som en vanlig gränssnittsadress.
Routat prefix: Upstream-enheten routar ett helt nät till WAN-adressen eller till en överenskommen next hop. Då frågar den normalt inte efter varje måladress i prefixet via ARP i WAN-segmentet. En manuell Proxy ARP-post vore fel åtgärd i det fallet.
Statisk granne: Den kopplar en fast MAC-adress till en direkt nåbar granne. Det är den omvända riktningen och ersätter inte Proxy ARP. Skillnaden förklaras i Kontrollera ARP- och NDP-granncachen.

Inte heller en DNAT-regel innebär automatiskt att man behöver manuell Proxy ARP. Testa först den befintliga datavägen. CLI-posten är motiverad endast om leverantörsdesignen och en capture verkligen bekräftar att ARP-svaret saknas.

Exempel och utbytbara värden

Exemplet använder en direkt ansluten publik IPv4-tilldelning. En HTTPS-tjänst ska vara nåbar via den extra adressen 203.0.113.10:

WAN-gränssnitt: Port2
brandväggens WAN-adress: 203.0.113.9/29
leverantörsgateway: 203.0.113.14
extra publik mål-IP-adress: 203.0.113.10
extern testvärd: 198.51.100.25
intern server: 10.20.40.20
tjänst: HTTPS

203.0.113.0/24 och 198.51.100.0/24 är dokumentationsnät. De fungerar inte som produktionsadresser och måste ersättas helt med leverantörens verkliga tilldelning och en auktoriserad extern testvärd. Port2 är också bara ett exempel; använd exakt det gränssnitt där ARP-förfrågan bevisligen kommer in.

Masken /29 tas inte med i Proxy ARP-kommandot. Den förklarar endast exempelnätet. Själva posten gäller medvetet bara 203.0.113.10. Svara för ett helt intervall först när ägarskap, användning och syntax för varje adress är entydigt dokumenterade och har kontrollerats på den build som används.

Kontrollera leverantörsvägen och ARP före ändringen

Före CLI-ingreppet måste tre möjliga orsaker skiljas åt:

Ingen ARP-förfrågan når brandväggen: Då måste leverantörsväg, VLAN, switchport eller antagandet om tilldelningen hanteras före Proxy ARP-steget.
Förfrågan kommer fram och en enhet svarar redan: Då får inget andra svar skapas. Fastställ först ägaren till den synliga MAC-adressen.
Förfrågan kommer fram, men ingen svarar: Endast detta resultat stämmer med att ett Proxy ARP-svar saknas på brandväggen.

Öppna Option 4: Device Console för inspelningen via SSH eller lokal konsol. Åtkomsten och skillnaden mellan Device Console och Advanced Shell förklaras i Anslut till Sophos Firewall via SSH.

Följande BPF-filter är endast läsande och visar enbart ARP-trafik för exempeladressen:

tcpdump 'arp and host 203.0.113.10'

Starta därefter en ny anslutning till 203.0.113.10 från den auktoriserade externa testvägen. Om upstream-enheten fortfarande har en cachepost ska endast den posten uppdateras eller tillåtas löpa ut enligt routerns eller leverantörens dokumenterade förfarande. Att tömma alla ARP-cachar eller starta om routern är oproportionerligt för den första diagnosen.

Gränssnitt, mål-IP och tidpunkt i capture måste stämma med testet. En ARP-förfrågan i ett annat VLAN eller på ett annat gränssnitt löses inte av en post på Port2.

Lägg till en enskild Proxy ARP-post

Om förkontrollen är entydig läggs exakt den bekräftade adressen till i Device Console:

set proxy-arp add interface Port2 dest_ip 203.0.113.10

De fasta delarna är set proxy-arp add interface och dest_ip. Ersätt Port2 och 203.0.113.10 med det verkliga gränssnittet och den individuellt bekräftade IPv4-adressen.

Sophos dokumenterar även dst_iprange, men publicerar inget fullständigt, testat intervallexempel på den aktuella hjälpsidan. Därför gissas inget format här. För publika intervall är en enskild adress dessutom en säkrare pilot: den begränsar påverkan och kan testas entydigt både positivt och negativt.

Generera omedelbart efter kommandot en ny ARP-förfrågan och upprepa capture. Det förväntade resultatet är ett svar med MAC-adressen för avsett brandväggsgränssnitt. Om en annan MAC-adress svarar eller om flera svar visas stoppas utrullningen och adresskonflikten reds först ut.

Implementera brandväggsregel, NAT och returväg separat

Proxy ARP drar Ethernet-ramen till brandväggen. Den efterföljande IP-datavägen behöver fortfarande en egen, tekniskt lämplig konfiguration.

För exemplet med den interna HTTPS-servern omfattar detta:

en strikt begränsad DNAT-regel från 203.0.113.10:443 till 10.20.40.20:443;
en lämplig brandväggsregel från den auktoriserade WAN-källan till serverzonen;
logging under acceptanstestet;
en returväg från servern via Sophos Firewall;
vid behov loopback, men endast som ett separat planerat internt användningsfall.

Publicera en server med DNAT går igenom regelposition, Original Destination, målzon, loopback och skyddsfunktioner. Begreppen SNAT, DNAT, MASQ och PAT förklaras i NAT på Sophos Firewall.

Om den extra publika adressen ska routas utan DNAT till ett system längre ned i nätet behöver brandväggen i stället en entydig route och lämpliga regler. Ett överlappande nät får inte döljas med en gissad statisk route eller ett Proxy ARP-intervall. Leverantörsprefix, intern adressering och returväg måste först fastställas som en sammanhängande routingdesign.

Testa ARP och den verkliga tjänsten

Acceptanstestet består av en Layer 2-kontroll och en IP-/applikationskontroll:

Generera en ny ARP-förfrågan för 203.0.113.10.
Bekräfta i capture förfrågan på Port2 och exakt ett svar med brandväggens förväntade MAC-adress.
Öppna en ny HTTPS-anslutning från testvärden 198.51.100.25.
Kontrollera förväntad Firewall Rule ID och NAT Rule ID i Log viewer.
Jämför inkommande trafik på Port2 med utgående trafik till servern i Built-in Packet Capture.
Kontrollera på servern att anslutningen kommer fram och att svaret går tillbaka via brandväggen.
Gör negativa tester med en otillåten port och en obehörig källa.
Om HA används, testa en ny anslutning och en ny ARP-cykel efter en kontrollerad failover.

Framgång är bevisad först när både ARP-svaret och den verkliga tjänsten stämmer. Ping räcker inte: ICMP kan avsiktligt behandlas på annat sätt än HTTPS i Device Access eller brandväggsregeln. Filter, Status, Reason, Rule ID och gränssnittsjämförelse förklaras i Packet Capture på Sophos Firewall; den fullständiga regelkontrollen finns i Testa brandväggsregler systematiskt.

Avgränsa problem systematiskt

Ingen ARP-förfrågan kommer fram

Kontrollera leverantörstilldelning, upstream-routing, VLAN, switchport och faktiskt inkommande gränssnitt. En lokal Proxy ARP-post kan inte besvara en förfrågan som aldrig når gränssnittet. För ett routat prefix är det till och med förväntat att ingen ARP-förfrågan för den enskilda mål-IP-adressen kommer; då ska route och next hop kontrolleras i stället för Proxy ARP.

ARP-förfrågan kommer fram, men inget svar går ut

Jämför mål-IP och gränssnitt i kommandot med capture. Uteslut sedan att gränssnittet har ändrats, att adressen har skrivits fel eller att testet har utförts från ett annat Layer 2-segment. Lägg inte till ett bredare IP-intervall för att skenbart reparera ett oklart enskilt test.

Om den dokumenterade posten på det bekräftade gränssnittet fortfarande inte svarar ska firmwareversion, en kort capture och den exakta topologin sparas för Sophos Support. Odokumenterade ingrepp i ARP- eller kernelparametrar via Advanced Shell är inte ett säkert standardsteg.

Flera MAC-adresser svarar

Testet stoppas. Vanliga orsaker är en duplicerad IP-adress, en fortfarande aktiv gammal enhet, ett alias på en andra brandvägg eller ytterligare en Proxy ARP-post. Fastställ först ägaren till varje MAC-adress och lös adresskonflikten. En brandväggsregel kan inte korrigera konkurrerande ARP-svar.

ARP stämmer, men tjänsten är fortfarande onåbar

Då har Proxy ARP redan utfört sin uppgift. Kontrollera därefter Firewall Rule ID, NAT Rule ID, regelordning, målzon, tjänst, servergateway och returväg. En gammal session får inte återanvändas för den nya anslutningen.

Efter byte eller HA-failover är adressen kortvarigt onåbar

Kontrollera ARP och den verkliga tjänsten igen på den nod som var aktiv vid tidpunkten för händelsen. Upstream-enheten kan fortfarande behålla en gammal MAC-mappning. Uppdatera först endast den berörda posten kontrollerat; hela förfarandet för gamla leverantörs- eller routercachar beskrivs i Åtgärda ARP-problem efter en brandväggsmigrering.

Ingen avbrottsfri fortsättning av befintliga anslutningar utlovas. Det avgörande är en ny ARP-förfrågan, en ny applikationssession och loggarna från den nod som faktiskt behandlar trafiken.

Rollback och drift

Dokumentera före borttagningen vilken publicerad adress och vilken tjänst som är beroende av posten. Ta under underhållsfönstret bort samma enskilda värde med del:

set proxy-arp del interface Port2 dest_ip 203.0.113.10

Generera därefter en ny ARP-förfrågan. Brandväggen ska inte längre svara för denna manuella post, förutsatt att inget alias, ingen HA-peer eller någon annan legitim mekanism hanterar samma adress. Beroende testregler och tillfällig NAT-konfiguration återställs till det dokumenterade ursprungstillståndet.

Posten hör hemma i driftdokumentationen eftersom den, till skillnad från en vanlig gränssnittsadress, förklarar varför brandväggen svarar för den extra IP-adressen. Efter ombyggnad av gränssnitt, utbytesenhet, restore, firmwarebyte eller HA-test ska måladress, gränssnitt, ARP-svar och verklig tjänst kontrolleras på nytt.

Checklista

Leverantörstilldelning och ARP-modell i stället för routingmodell har bekräftats.
Mål-IP-adressen tillhör bevisligen den egna miljön och används inte dubbelt.
ARP-förfrågan kommer in på det dokumenterade gränssnittet.
Det saknade svaret före ändringen har bekräftats med capture.
Endast en pilotadress har lagts in med dest_ip.
Brandväggsregel, NAT eller route och returväg har kontrollerats separat.
Förväntad MAC-adress, Firewall Rule ID och NAT Rule ID har bekräftats.
Obehörig källa och otillåten port har testats negativt.
HA-failover eller utbytesväg har testats med en ny anslutning.
Exakt del-kommando och ursprungstillstånd har dokumenterats.

FAQ

Behöver varje DNAT-regel en manuell Proxy ARP-post?

Nej. DNAT och Proxy ARP är separata funktioner. Manuell Proxy ARP läggs endast till när upstream-enheten använder ARP för den extra IPv4-adressen i det direkt anslutna segmentet och brandväggens nödvändiga svar bevisligen saknas.

Vad är skillnaden mellan en alias-IP och Proxy ARP?

En alias-IP binder adressen till ett fysiskt brandväggsgränssnitt. Proxy ARP låter endast brandväggen svara på en ARP-förfrågan för en IPv4-adress. Vilken variant som passar avgörs av leverantörs-, routing-, NAT- och systemtrafikdesignen.

Fungerar kommandot även för IPv6?

Nej. Det dokumenterade kommandot gäller ARP och därmed IPv4. IPv6 använder Neighbor Discovery. Utan ett separat dokumenterat och testat SFOS-förfarande får Proxy ARP inte överföras till IPv6.