Früher habe ich eine einfache Netzwerkarchitektur aus zwei Hauptgründen implementiert.

• Sie sind einfach zu debuggen/fehlersuchen.
• Ingenieure, die nach mir kamen, können sie leicht verstehen und verwalten.

Mit diesen Regeln im Hinterkopf implementiere ich normalerweise Inline-Firewalls, was bedeutet, dass der Datenverkehr durch eine Firewall geleitet wird, die “im Pfad” platziert ist:

Manchmal sind die Dinge kompliziert, und wir müssen “off-path” Firewalls implementieren, wobei der Datenverkehr teilweise durch die Firewall geleitet wird:

Es gibt viele Gründe, warum wir das tun wollen.

• Wir möchten eine neue Firewall testen.
• Wir haben nicht genug Budget für eine große Firewall, um den gesamten Datenverkehr zu verwalten.
• Wir müssen einige latenzempfindliche Datenverkehr ausschließen.

In 99% der Szenarien ist eine Inline-Firewall in Ordnung; lassen Sie uns untersuchen, wie man mit den verbleibenden 1% umgeht.

Lokale Internetverbindung

Voraussetzung #1: Wir müssen die lokale Internetverbindung verwenden, wenn verfügbar, und MPLS verwenden, wenn nicht.

Die Lösung dieser Anforderung ist einfach: Wir müssen eine bedingte statische Standardroute implementieren. Die Firewall wird nur verwendet, wenn die Internetverbindung über sie funktioniert.

Je nach Firewall-Modell können wir native Funktionen und dynamisches Routing verwenden, um die Konfiguration zu erreichen. Für diesen Beitrag möchten wir jedoch die Anforderung nur auf dem L3-Switch lösen.

Netzwerktechniker sind es gewohnt, einen ICMP-Test durchzuführen, der 8.8.8.8 erreicht, um die Internetverbindung zu testen. Ich habe sogar offizielle Dokumente gelesen, die das vorschlagen, aber das ist eine schlechte Praxis, weil Google Rate Limits anwendet:

Wir möchten zwei DNS-Proben implementieren, die mindestens zwei verschiedene DNS-OpenDNS-Server verwenden.

ip sla 1
 dns www.cisco.com name-server 208.67.222.222 source-ip 192.168.1.1
 timeout 5000
 frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
 dns www.google.com name-server 208.67.220.220 source-ip 192.168.1.1
 timeout 5000
 frequency 10
ip sla schedule 2 life forever start-time now
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability

DNS-Anbieter können Anfragen mit ungewöhnlichen Datensatztypen, übermäßigen doppelten Abfragen, übermäßigen DNS-Datensätzen oder solchen, die von bösartigen Client-IPs gesendet werden, mit Entropie zu unseren Nameserver-Anfragen hinzufügen. Da wir eine Frequenz von 10 s verwenden, können wir davon ausgehen, dass es sicher ist.

Wir müssen auch die obigen Proben mit dem OR-logischen Operator koppeln

track 3 list boolean or
 object 1
 object 2
 delay down 12 up 30

Um Flapping zu vermeiden, haben wir eine Verzögerung vor dem Ändern des Zustands eingeführt.

Schließlich haben wir die Standard-Statikroute konfiguriert, die mit der Sonde verbunden ist.

ip route 0.0.0.0 0.0.0.0 192.168.1.254 track 3

Mit dieser Konfiguration wird der Datenverkehr zum Internet durch die Firewall geleitet, wenn die Internetverbindung über die Firewall selbst funktioniert. Andernfalls wird die Standardroute von MPLS verwendet.

Es sollte besonders auf die Konvergenzzeit geachtet werden, insbesondere wenn die lokale Internetverbindung ausfällt.

Off-Path-Firewall-Filterung

Voraussetzung #2: Wir müssen einige Netzwerkgespräche selektiv filtern. Wir dürfen nichts an die Firewall weiterleiten, weil sie nicht über ausreichende Bandbreite oder Rechenressourcen verfügt.

Die Lösung dieser Anforderung erfordert PBR oder Policy-Based Routing. Wir verwenden PBR, wenn wir eine Ausnahme zum normalen Routing machen müssen. Wir möchten basierend auf Protokoll, Quell-/Ziel-IP und Port Netzwerkflüsse auswählen, die durch die Firewall geroutet werden sollen. Die Firewall ist “on-a-stick” konfiguriert, was bedeutet, dass eine einzelne Schnittstelle verwendet wird, um den erlaubten Netzwerkverkehr zu empfangen und zu übertragen.

Wir müssen den Netzwerkverkehr, der gefiltert werden soll, mithilfe einer ACL definieren.

ip access-list extended FILTERED
 permit ip 192.168.20.0 0.0.0.255 any
 permit ip any 192.168.20.0 0.0.0.255

Wir müssen sowohl den Ein- als auch den Ausgangsverkehr abgleichen. Eine Routenkarte leitet den Verkehr durch die Firewall.

route-map FILTERED permit 10
 match ip address FILTERED
 set ip next-hop verify-availability 192.168.1.254

In einer Firewall-Konfiguration ohne hohe Verfügbarkeit können wir das bedingte PBR implementieren:

route-map FILTERED permit 10
 match ip address FILTERED
 set ip next-hop verify-availability 192.168.1.254 1 track 11

Schließlich müssen wir die Routenkarte auf jede L3-Schnittstelle anwenden, wobei die Schnittstelle ausgeschlossen ist, auf der die Firewall platziert ist:

Schnittstelle Ethernet0/1
 ip policy route-map GEFILTERT
Schnittstelle Ethernet0/2
 ip policy route-map GEFILTERT

Mit dieser Konfiguration wird der eingehende Datenverkehr, der der ACL entspricht, an die Firewall weitergeleitet.

Schlussfolgerungen

Auch hier sollte dieses Design nicht verwendet werden, es sei denn, es liegen spezifische Anforderungen vor. Dennoch funktioniert es gut. Automatisierungswerkzeuge sollten in Betracht gezogen werden, um große Umgebungen ordnungsgemäß zu verwalten. Je mehr menschliche Abhängigkeit besteht, desto mehr Fehler (und Ausfälle) wird es geben.