Vervang de Sophos Firewall Route Precedence veilig

De Route Precedence van de Sophos Firewall bepaalt de volgorde waarin met verschillende routetypen rekening wordt gehouden bij het selecteren van de route. Dit klinkt als een kleine aanpassing, maar kan direct gevolgen hebben voor het productieve verkeer. Dit is met name relevant wanneer Statische routes, SD-WAN-beleidsroutes en VPN-routes elkaar overlappen.

In het artikel wordt uitgelegd wanneer een wijziging zinvol is, wanneer u eerst andere oorzaken moet controleren en hoe u de wijziging goed kunt documenteren met behulp van de Device Console, deze kunt testen en indien nodig ongedaan kunt maken. Als je eerst een normale SD-WAN-route wilt plannen of testen, past Sophos Firewall SD-WAN-route instellen en testen.

Wanneer Route Precedence belangrijk is

Route Precedence wordt belangrijk wanneer meerdere routeringsmechanismen theoretisch op dezelfde bestemming passen. De firewall moet dan beslissen welk type routering als eerste wordt geëvalueerd.

Typische situaties:

• Een intern doelnetwerk kan worden bereikt via een statische route en daarnaast via een SD-WAN-beleidsroute.
• Een routegebaseerde IPsec VPN maakt gebruik van XFRM-interfaces en wordt tegelijkertijd beïnvloed door SD-WAN-regels.
• Een op beleid gebaseerd speciaal geval IPsec werkt met handmatige IPsec-routes.
• Een oudere migratie heeft SD-WAN-routes of een eerdere Route Precedence behouden.
• Door het systeem gegenereerd verkeer of antwoordpakketten nemen een onverwachte route na een SD-WAN-wijziging.
• Na een firmware-upgrade of migratie gedragen bestaande routes zich anders dan verwacht.

Voor speciale gevallen van IPsec is Route Precedence niet automatisch de beste oplossing. Vaak moet u eerst begrijpen of er sprake is van een klassiek routeringsprobleem, een IPsec Route, een SD-WAN-regel, NAT of een firewallregel.

Vereisten

• Sophos Firewall in Gateway-modus.
• Toegang tot de Device Console, bijvoorbeeld via SSH.
• Actuele documentatie van getroffen statische routes, SD-WAN-beleidsroutes en VPN-verbindingen.
• Onderhoudsvenster of op zijn minst een terugvalpad wanneer productief verkeer kan worden beïnvloed.
• Toegang tot Log Viewer en, indien nodig, Packet Capture.

Als consoletoegang nog niet is ingesteld, legt Verbind Sophos Firewall via SSH uit hoe u toegang krijgt tot de Device Console. SSH mag alleen worden toegestaan ​​vanaf vertrouwde netwerken.

⚠️ Belangrijk: Een wijziging aan de Route Precedence heeft een mondiaal effect. Het is niet slechts één tunnel of route die wordt beïnvloed, maar de volgorde van de routeringstypen op de firewall. Daarom mag u nooit meerdere routerings-, NAT- en SD-WAN-wijzigingen tegelijkertijd aanbrengen.

Standaardvolgorde

De huidige documentatie beschrijft de volgende standaardvolgorde:

1. Statisch
2. SD-WAN
3. VPN

De waarden in de Device Console zijn:

• static
• sdwan_policyroute
• vpn

Belangrijk: de categorie static is breder dan de naam doet vermoeden. Sophos rekent hier direct verbonden netwerken, routes uit ipsec_route, unicast-routes, dynamische routes en SSL VPN-verbindingen toe. Dit is vooral relevant wanneer remote access-verkeer, statische routes, dynamische routing en SD-WAN-regels samen worden beoordeeld.

Ook belangrijk: direct verbonden netwerken worden in deze context behandeld als statische routes. Als sdwan_policyroute vóór static staat en een SD-WAN-route met een zeer brede bestemming zoals Any werkt, kan intern verkeer plotseling richting de WAN-gateway gaan. Dit is precies waarom de static vóór de sdwan_policyroute in veel omgevingen het veilige startpunt is.

Controleer bij gemigreerde firewalls de actuele uitvoer extra bewust. Sophos kan Route Precedence uit een eerdere versie behouden, en gemigreerde SD-WAN-routes kunnen nog steeds aan oude firewallregels gekoppeld zijn. In dat geval is niet de standaard in de huidige documentatie bepalend, maar wat system route_precedence show op de betreffende firewall weergeeft.

Welke volgorde is correct?

Er is niet één juiste volgorde voor elk ontwerp. De Route Precedence moet passen bij het routingmodel.

• Normaal LAN, DMZ, VLAN, externe toegang en SD-WAN internetpaden: static sdwan_policyroute vpn Direct verbonden netwerken en statische routes mogen niet worden overschreven door brede SD-WAN-routes.
• Policy-based IPsec overlapt met statische of SD-WAN-routes: vpn static sdwan_policyroute kan helpen in passende VPN-routeringsgevallen. Als een statische of lokale route verkeer naar een andere zone dan WAN stuurt, is een gerichte ipsec_route vaak schoner dan een globale precedence-wijziging. Controleer daarna NAT, firewallregels en retourpad.
• L2TP Remote Access of andere gedocumenteerde VPN-uitzonderingen: Sophos vereist in sommige scenario’s vpn als eerste. Dat is geen algemene standaard, maar een gerichte afwijking voor een gecontroleerde use case.
• Routegebaseerde IPsec of WAN failover wordt bewust via SD-WAN gestuurd: De volgorde hangt af van het ontwerp, vaak met SD-WAN vóór een ander type routing. Test XFRM-interface, SD-WAN-criteria, gatewaystatus, NAT en Route Precedence samen.
• MTA, speciale routing of individuele Sophos how-to-scenario’s: De volgorde moet passen bij het geteste scenario. Kopieer niet blindelings een voorbeeld; controleer altijd lokale netwerken en retourroutes.

Als een Sophos-voorbeeld een andere volgorde laat zien, is dat niet automatisch een nieuwe standaard. Veel voorbeelden lossen een concreet, bijzonder probleem op. Wat telt voor een productieve firewall is welke bron- en doelnetwerken daadwerkelijk met elkaar concurreren.

Limiet vóór wijziging

Route Precedence mag niet de eerste reactie zijn wanneer een doelnetwerk niet kan worden bereikt. Eerst moet u de getroffen pakketstroom beperken.

Controleer:

1. Om welke bron en bestemming gaat het?
2. Om welke zone en welk grensvlak gaat het?
3. Is er een geschikte statische route?
4. Is er een beleidstraject SD-WAN dat breder aansluit dan gepland?
5. Zijn er gemigreerde SD-WAN-routes uit een oudere SFOS-versie?
6. Is er sprake van een VPN-route of een XFRM-interface?
7. Is NAT of MASQ van toepassing?
8. Wordt er voldaan aan de verwachte firewallregel in de Log Viewer?
9. Toont Packet Capture het verwachte invoer- en uitvoerpad?

Sophos Firewall testregel met Log Viewer en Packet Capture en Sophos Firewall gebruiken Packet Capture in WebAdmin hulp bij het praktijkexamen. Voor NAT-vragen is NAT begrijpen op Sophos Firewall geschikt.

Bekijk huidige Route Precedence

De opdrachten worden uitgevoerd in de Device Console, niet in de Advanced Shell.

Toon huidige bestelling:

system route_precedence show

De uitvoer moet vóór eventuele wijzigingen worden gedocumenteerd. Het beste is om ook de datum, reden, getroffen netwerken en verwacht gedrag te noteren. Als een rollback nodig is, moet deze exacte volgorde opnieuw worden ingesteld.

In de WebAdmin ziet u ook de huidige Route Precedence onder:

Routing > SD-WAN routes

Daar wordt het weergegeven in het routeadviesgedeelte. De bestelling wordt gewijzigd via de Device Console.

Route Precedence wijzigen

De syntaxis is:

system route_precedence set [sdwan_policyroute] [static] [vpn]

De volgorde van de drie waarden bepaalt de prioriteit. In een typisch voorbeeld worden statische routes vóór SD-WAN-beleidsroutes en VPN-routes geplaatst:

system route_precedence set static sdwan_policyroute vpn

Als deze bestelling al actief is, ligt het probleem waarschijnlijk niet bij Route Precedence. Controleer dan specifiek het opzoeken van routes, SD-WAN-beleidsroutes, IPsec-configuratie, NAT, firewallregels en retourroutes.

In een ander voorbeeld worden SD-WAN-beleidsroutes vóór statische routes geplaatst:

system route_precedence set sdwan_policyroute static vpn

Dit kan bewust zijn in bepaalde SD-WAN-ontwerpen, maar is riskant wanneer brede SD-WAN-regels Any of grote netwerkbereiken gebruiken. In zulke gevallen kunnen beheertoegang, interne netwerken of retourpakketten onverwacht via SD-WAN worden gerouteerd. Het artikel Sophos Firewall SD-WAN routing voor reply packets en system traffic legt deze interacties gedetailleerder uit.

Voor speciale gevallen op basis van beleid IPsec kan vpn in de eerste plaats ook nodig zijn:

system route_precedence set vpn static sdwan_policyroute

Doe dit alleen als de VPN-routes in de concrete pakketstroom echt voorrang moeten krijgen. Sophos geeft aan dat route_precedence VPN-routes niet voor elk bestemmingspad boven statische routes laat winnen. Als een statische of lokale route naar een andere zone dan WAN wijst, controleer dan bij policy-based VPN’s met traffic selectors eerder ipsec_route. Bij route-based IPsec met XFRM-interfaces is een nette SD-WAN- of statische route meestal beter dan vpn globaal vooraan te zetten.

Testwijziging

Controleer na het aanpassen eerst de nieuwe bestelling:

system route_precedence show

Test vervolgens specifiek het getroffen verkeer. Een groene VPN-status of een bestaande route is niet voldoende bewijs.

Controleer:

• Verbinding met het doelnetwerk met ping, TCP-test of applicatietest.
• Filter Log Viewer op bron, bestemming en firewallregel.
• Voer Packet Capture uit op de invoer- en uitvoerinterface.
• Controleer de routezoekopdracht of de getroffen SD-WAN-regel.
• Controleer de NAT-regel en vertaalde bron-IP.
• Controleer het retourpad van het externe station.
• Test beheertoegang tot WebAdmin en SSH vanuit relevante beheerdersnetwerken.

Als er sprake is van meerdere locaties, moet u niet slechts één testklant controleren. Het is beter om minimaal één client per relevant netwerk, een serverdoel en een externe toegang of VPN-test te hebben of deze paden door de wijziging worden beïnvloed.

Terugdraaien

Een rollback bestaat niet uit een geadviseerde standaardwaarde, maar uit de eerder gedocumenteerde volgorde.

Voorbeeld:

system route_precedence set static sdwan_policyroute vpn

of:

system route_precedence set sdwan_policyroute static vpn

Controleer opnieuw na het terugdraaien:

system route_precedence show

Herhaal vervolgens dezelfde tests als na de wijziging. Als hierdoor de oorspronkelijke fout terugkeert, is dat een sterke indicatie dat het inderdaad om de Route Precedence gaat. Als er niets verandert, ligt de oorzaak waarschijnlijk ergens anders.

Veelvoorkomende fouten

SD-WAN-regel is te breed

Als een SD-WAN-beleidsroute overeenkomt met zeer brede bronnen of bestemmingen, kan deze meer verkeer genereren dan gepland. Dit is vooral gevaarlijk als SD-WAN voorrang krijgt boven static. Beheertoegang of interne doelnetwerken kunnen dan onverwachts via een WAN-route lopen.

Typisch patroon:

• Route Precedence staat op sdwan_policyroute static vpn.
• Een SD-WAN-route gebruikt Any als bestemming.
• Door het systeem gegenereerd verkeer of antwoordpakketten worden ook geëvalueerd via SD-WAN.

De toegang tot WebAdmin of SSH vanuit een intern subnet kan dan verloren gaan, hoewel de firewall nog wel bereikbaar is vanuit andere netwerken.

VPN-status wordt verward met routering

Een actieve IPsec-tunnel bewijst alleen dat er over de tunnel is onderhandeld. Het bewijst niet dat de firewall het verkeer naar de tunnel leidt, dat NAT correct is of dat het externe station de weg terug weet.

Bij policy-based IPsec is het vooral belangrijk of statische, lokale of SD-WAN-routes ook overeenkomen met de externe subnetten. vpn static sdwan_policyroute kan in sommige gevallen helpen, maar vervangt niet de controle van zone, traffic selectors en een mogelijke ipsec_route. Voor route-based IPsec moeten eerst de XFRM-interface, route, SD-WAN-route en firewallregels worden gecontroleerd.

NAT wordt over het hoofd gezien

Routing bepaalt waar een pakket naartoe wordt gestuurd. NAT beslist of het bron- of bestemmingsadres wordt gewijzigd. Als een route correct is, maar de retourroute niet werkt, is er vaak sprake van NAT of de retourroute.

Meerdere wijzigingen tegelijk

Als Route Precedence-, SD-WAN-regels, NAT, firewallregels en VPN-parameters tegelijkertijd worden gewijzigd, kan het effect nauwelijks duidelijk worden toegeschreven. Het is beter om een ​​verandering aan te brengen, dan te testen en dan de volgende verandering door te voeren.

Controlelijst

• Huidige Route Precedence gedocumenteerd met system route_precedence show.
• Getroffen bronnen, bestemmingen, netwerken en diensten vermeld.
• Statische routes, SD-WAN beleidsroutes en VPN routes gecontroleerd.
• Er wordt rekening gehouden met direct verbonden netwerken en interne beheerpaden.
• Brede SD-WAN-routes geïdentificeerd met Any.
• NAT- en firewallregels gecontroleerd.
• Onderhoudsvenster of terugvalpad gedefinieerd.
• Wisselset met exacte volgorde.
• Na wijziging Log Viewer, Packet Capture en applicatietest uitgevoerd.
• Beheertoegang vanaf beheerdersnetwerken aangevinkt.
• Terugdraaiorder gedocumenteerd.

Veelgestelde vragen