Konfigurera och testa ett alias-IP på Sophos Firewall

Ett alias-IP binder en extra IPv4- eller IPv6-adress till ett befintligt fysiskt interface på Sophos Firewall. Det är praktiskt när en leverantör tillhandahåller flera publika adresser över samma WAN-anslutning eller när ett internt interface behöver betjäna ett andra subnät under en migrering.

Den viktiga skillnaden är att ett alias inte är en andra internetanslutning, en egen zon eller en separat gatewayväg. Adressen använder samma fysiska huvudinterface. Routing, brandväggsregler, NAT och Device Access måste därför fortfarande passa den befintliga interfacedesignen.

⚠️ Dokumentera en aktuell backup, en oberoende administrativ anslutning, leverantörens tilldelning, det ursprungliga ARP-läget och planerade brandväggs- och NAT-regler innan ett publikt alias-IP läggs till. En extra adress publicerar inte en server i sig, men den kan göra lokala brandväggstjänster åtkomliga enligt Device Access-reglerna för huvudzonens interface.

Exemplet använder IPv4 på ett WAN-interface. SFOS stöder även IPv6-alias när IP-versionen matchar huvudinterfacet. IPv6 Neighbor Discovery och NAT66 ingår dock inte i detta konkreta exempel.

Alias-IP i åtta steg

1. Bekräfta att leverantören eller det interna nätverket faktiskt tillhandahåller den extra adressen över samma fysiska interface.
2. Dokumentera huvudinterface, IP-version, adress, subnätmask och användningsområde.
3. Kontrollera Device Access, befintliga regler och en oberoende hanteringsväg.
4. Bind adressen till huvudinterfacet under Network > Interfaces > Add interface > Add alias.
5. Skapa vid behov ett tydligt namngivet IP Host med exakt denna adress för regler och NAT.
6. Konfigurera DNAT eller SNAT endast för det avsedda flödet; hantera systemtrafik separat.
7. Verifiera leverantörsvägen, ARP, Firewall Rule ID, NAT Rule ID och båda riktningarna med en ny anslutning.
8. Testa ersättningsutrustning, HA-failover och rollback i ett underhållsfönster med samma flöde.

När ett alias-IP passar

Ett alias-IP passar när flera adresser ska använda samma fysiska Layer 2- och gatewayväg. Vanliga fall är:

• flera publika IPv4-adresser på en statisk WAN-anslutning;
• en egen publik adress för DNAT, WAF eller en e-posttjänst;
• en fast källadress för utvald vidarebefordrad trafik;
• ett andra internt subnät på samma fysiska segment under en kontrollerad migrering;
• flera leverantörsadresser i samma subnät, där separata WAN-interface skulle orsaka ARP-problem.

Flera WAN-interface i samma subnät är ingen ren ersättning. Sophos varnar för att gateways kan bli oåtkomliga på grund av ARP-problem och anger alias eller LAG som lämpliga interfaceformer. Zoner och interface på Sophos Firewall förklarar grundvalet mellan fysiska portar, VLAN, LAG, bridge och XFRM.

Ett alias passar inte när det krävs en andra anslutning, egen gateway, oberoende länkstatus, annan säkerhetszon eller verklig failover. Då behövs en separat design för interface, VLAN, LAG, WAN eller routing.

Om brandväggen inte ska äga en extra IPv4-adress lokalt utan endast besvara ARP-förfrågan för adressen i dess ställe i ett direkt anslutet segment är det en annan design. Konfigurera Proxy ARP på Sophos Firewall förklarar beslutet och det strikt avgränsade CLI- och testförfarandet.

Exempel och värden som ska ersättas

Exemplet publicerar en intern HTTPS-tjänst via en andra publik adress:

• Huvudinterface: Port2
• Huvudzon: WAN
• Huvudadress: 203.0.113.9/29
• Leverantörsgateway: 203.0.113.14
• Alias-IP: 203.0.113.10/29
• Aliashostobjekt: WAN_ALIAS_APP_203.0.113.10
• Intern server: APP-DMZ_10.20.40.20
• Server-IP: 10.20.40.20
• Tjänst: HTTPS
• Extern testhost: 198.51.100.25

203.0.113.0/24 och 198.51.100.0/24 är reserverade för dokumentation. I produktionskonfigurationen ska de ersättas med de adresser som leverantören har tilldelat och en auktoriserad extern testhost.

Masken /29 är bara ett realistiskt exempel. Den får inte kopieras om leverantören tillhandahåller ett routat block, en enskild /32-adress eller en annan nätstorlek. Leverantörsdokumentationen, ARP- eller routingmodellen och IP-versionen på huvudinterfacet avgör rätt värde.

Lägg till aliaset på det fysiska interfacet

Under Network > Interfaces binds adressen direkt till det befintliga interfacet:

1. Välj Add interface > Add alias.
2. Under Physical interface, välj Port2 eller det faktiska huvudinterfacet.
3. Ställ in IP version på IPv4.
4. Under IPv4/Netmask, ange 203.0.113.10 och den mask som leverantören har bekräftat.
5. Spara med Save.

Den extra adressen visas sedan vid huvudinterfacet. Om fler än tre alias finns visar SFOS till en början bara de tre första. Bläddra i det synliga adressområdet för att se övriga poster.

Ett alias kan inte aktiveras eller inaktiveras oberoende. Om det fysiska huvudinterfacet inaktiveras eller tappar länken blir även dess aliasadresser oåtkomliga. Omvänt skapar ett sparat alias ingen ny gatewaypost eller separat route.

Formuläret Add alias har inget separat zonfält. Därför förblir zonen för huvudinterfacet relevant för lokala brandväggstjänster. Kontrollera under Administration > Device access vilka tjänster som kan nås från WAN innan ett publikt alias-IP läggs till, och använd en snäv Local Service ACL Exception för fasta hanteringskällor. SSO eller MFA motiverar inte bred WebAdmin-åtkomst.

Använd aliaset i regler och NAT

Det bundna aliaset och ett IP Host har olika funktioner:

• Aliaset gör adressen lokalt tillgänglig på det fysiska interfacet.
• IP Host gör samma adress tydligt valbar i regel- och NAT-fält.

Ett hostobjekt ensamt binder ingen adress till interfacet. Omvänt publicerar ett alias ensamt ingen server och tillåter ingen vidarebefordrad trafik. Använd IP Hosts och tjänster korrekt förklarar objektgränserna i detalj.

Publicera en inkommande tjänst med DNAT

För exemplet skapas objektet WAN_ALIAS_APP_203.0.113.10 under Hosts and services > IP host som typen IP med adressen 203.0.113.10. Därefter skapas en snäv DNAT-regel och en matchande brandväggsregel:

• Original source: auktoriserade externa nätverk eller medvetet Any
• Original destination: WAN_ALIAS_APP_203.0.113.10
• Original service: HTTPS
• Translated destination (DNAT): APP-DMZ_10.20.40.20
• Translated service (PAT): Original
• Inbound interface: Port2 eller den faktiskt bekräftade ingången
• Translated source (SNAT): normalt Original
• Log firewall traffic: aktiverat

Brandväggsregeln tillåter samma externa tjänst från WAN till den interna serverns zon och använder den publika aliasadressen från Original destination som Destination network. Håll källa, tjänst och skyddsfunktioner så snäva som möjligt. Den fullständiga konfigurationen med regelposition, loopback och härdning finns i Publicera en server med DNAT.

Skicka vidarebefordrad trafik via alias-IP

Om endast en viss intern server ska visas externt som 203.0.113.10 skapas en separat SNAT-regel för exakt detta flöde. Translated source (SNAT) använder då IP Host för aliasadressen. Håll källa, destination, tjänst och interface så snäva som användningsfallet tillåter.

NAT-regeln ersätter ingen brandväggsregel. NAT-regler utvärderas dessutom bara för det första paketet i en ny anslutning. Öppna därför en ny anslutning efter en ändring; en befintlig session bevisar inte den nya NAT-vägen. NAT på Sophos Firewall förklarar hur SNAT, DNAT och PAT behandlas.

Hantera brandväggens systemtrafik separat

DNS-, autentiserings-, e-post- eller annan trafik som brandväggen själv genererar följer inte automatiskt en SNAT-regel för vidarebefordrade klienter. Sophos dokumenterar uttryckligen att routingkonfigurationer använder huvudinterfacet. Om ett specifikt och motiverat systemtrafikflöde ska använda alias-IP som källa krävs en separat CLI-konfiguration.

Registrera ursprungsläget i Device Console före ändringen:

show advanced-firewall

Följande exempel översätter endast systemtrafik via Port2 till den enskilda destinationen 198.51.100.25 med alias-IP 203.0.113.10:

set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

⚠️ Kommandot ändrar källadressen för brandväggstrafik. Det skapar ingen route och är ingen generell ersättning för en NAT-regel. Destination, /32-nätmask, interface och alias-IP måste passa den verkliga tillämpningen. Testa exakt den berörda tjänsten efter ändringen och kontrollera posten igen med show advanced-firewall.

För rollback tas exakt samma post bort med delete:

set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Bredare nätmasker översätter trafik till ett helt destinationsnät. Använd dem endast när det större omfånget är avsiktligt, dokumenterat och testat.

Planera alias från olika subnät

Sophos tillåter flera aliasadresser från olika subnät på samma fysiska interface, men anger två villkor:

• Sophos Firewall måste vara default gateway för interna hosts.
• Upstreamenheter som fungerar som gateway för brandväggstrafik måste ha en lämplig adress i varje aliassubnät som används.

Ett alias gör alltså inte automatiskt ett andra subnät funktionellt end-to-end. Hostgateway, peers, returroute, ARP eller Neighbor Discovery, brandväggsregler och NAT måste också vara korrekta för subnätet.

För permanent segmentering är ett separat VLAN eller fysiskt interface oftast tydligare. Ett alias med flera subnät passar bättre för en medvetet planerad övergång eller en leverantörsarkitektur där båda näten faktiskt delar samma Layer 2-väg.

DHCP Server och DHCP Relay kan inte konfigureras på ett Interface Alias. Ett alias är inte heller en giltig Dedicated HA link. Sådana krav hör hemma på ett fysiskt eller virtuellt interface som stöds.

Validera dataväg och ARP

Valideringen ska följa den verkliga uppgiften och inte bara en ping:

1. Kontrollera huvudinterface, aliasadress, mask och länkstatus under Network > Interfaces.
2. Kontrollera på leverantörens eller upstreamenheten att alias-IP kan nås via den förväntade MAC-adressen eller neighbor.
3. Öppna en ny HTTPS-anslutning från 198.51.100.25 till alias-IP.
4. Kontrollera förväntad Firewall Rule ID, NAT Rule ID, Source, Original destination och översatt destination i Log Viewer.
5. Jämför ingången på Port2 med utgången till servern i den inbyggda Packet Capture.
6. Bekräfta på den interna servern att anslutningen kommer fram och att svaret går tillbaka via Sophos Firewall.
7. Negativtesta en medvetet otillåten port och en obehörig källa.
8. Upprepa ett kontrollerat failover-test i HA med en ny anslutning utan att förutsätta att en befintlig session fortsätter utan avbrott.

En ping till alias-IP är meningsfull endast om Ping avsiktligt är tillåtet för huvudzonens interface under Device Access. För en publicerad HTTPS-tjänst är ett verkligt TCP- och applikationstest ett bättre framgångsbevis. Packet Capture på Sophos Firewall förklarar filter, interfacejämförelse och export.

Avgränsa fel systematiskt

Aliaset syns men kan inte nås utifrån

• Bekräfta att leverantören faktiskt tillhandahåller den specifika adressen via Port2.
• Jämför IP, mask och huvudinterface med leverantörens tilldelning.
• Kontrollera ARP- eller neighbor-posten på upstreamenheten.
• Undersök Device Access endast för åtkomst till själva brandväggen.
• Kontrollera Firewall Rule ID, NAT Rule ID och serverns returväg för vidarebefordrade tjänster.

Efter att en brandvägg har ersatts kan upstreamroutern fortfarande ha den gamla MAC-adressen lagrad för alias-IP. Sophos anger då att routerns cache ska tömmas eller routern startas om. Uppdatera i praktiken först endast den berörda ARP- eller neighbor-posten enligt upstreamenhetens dokumenterade procedur; en fullständig omstart hör hemma i ett underhållsfönster.

Utgående trafik använder fortfarande huvudadressen

Kontrollera för vidarebefordrad trafik om den förväntade SNAT-regeln matchar en ny anslutning. Source, Destination, Service, Inbound interface, Outbound interface och NAT Rule ID måste stämma överens.

För brandväggens systemtrafik är en vanlig SNAT-regel inte rätt bevis. Kontrollera då den specifika sys-traffic-nat-posten, routen, destinationen och det faktiska paketflödet. Lägg inte till en bred översättning baserat på misstanke.

Endast det andra interna subnätet fungerar inte

Kontrollera om Sophos Firewall verkligen är default gateway för berörda hosts och om upstreamenheten har en lämplig adress i detta subnät. Kontrollera därefter returroute, hostmask, ARP, brandväggsregel och NAT separat. Ett synligt alias bevisar inte dessa beroenden.

En IPsec-tunnel via ett alias är aktiv men transporterar ingen trafik

Registrera först SFOS-version, build, appliance-modell, PPPoE-användning, aliasbindning, IPsec Acceleration och den faktiska paketvägen. SFOS 22 har versionsspecifika alias- och accelerationsfall som inte får tillämpas på alla aliasproblem. Den avgränsade diagnosvägen finns i IPsec-felsökning för aliasinterface.

Drift, ersättningsutrustning och rollback

Dokumentera aliasadresser tillsammans med leverantörstilldelning, DNS, certifikat, NAT, brandväggsregler och ansvarig tjänst. Inför ett brandväggsbyte måste särskilt publika alias och den förväntade ARP- eller neighbor-ändringen ingå i valideringen.

För rollback:

1. Dokumentera aktiva användningar av aliaset och tillhörande IP Host.
2. Ta kontrollerat bort publicerade tjänster från DNS, övervakning eller load balancing.
3. Inaktivera först tillhörande brandväggs- och NAT-regler och bekräfta att det planerade flödet upphör.
4. Ta bort en befintlig sys-traffic-nat-post med det exakta kommandot delete.
5. Ta bort alias och hostobjekt först när inga produktionsberoenden återstår.
6. Kontrollera huvudinterface, huvudadress, gateway och opåverkade tjänster igen.
7. Upprepa samma validering i HA efter ett planerat failover.

Ett alias kan inte användas som Dedicated HA link. HA på Sophos Firewall förklarar nödvändiga interface, peeradministrationsadresser och failover-tester för ett kluster.

Checklista

• Leverantörstilldelning, huvudinterface, IP-version, adress och mask är bekräftade.
• En backup och oberoende administrativ anslutning finns tillgängliga.
• Device Access och Local Service ACL för huvudzonens interface har kontrollerats.
• Aliaset och IP Host med samma namn blandas inte ihop.
• Brandväggs- och NAT-reglerna är begränsade till det avsedda flödet.
• Systemtrafik översätts separat endast när det finns ett motiverat behov.
• Firewall Rule ID, NAT Rule ID, ARP och båda riktningarna är bekräftade.
• En obehörig källa och en otillåten tjänst har negativtestats.
• Ersättningsutrustning, HA-failover och rollback är dokumenterade.

Vanliga frågor