Deep Dive: Analyse von Transitverkehr auf Switches und Routern

Bei der Analyse von Verbindungsproblemen ist es oftmals hilfreich zu wissen, ob bestimmte Daten ein bestimmtes Netzwerkgerät passieren. Wenn es um eine Firewall geht, ist es einfach diese Information in den Logs abzurufen. Ausserdem ermöglichen viele Firewall-Produkte die Aufzeichnung des Datenverkehrs, der dann mit einem Tool wie Wireshark analysiert werden kann.

Bei einem Router oder einem Switch ist die Situation eine andere. Im Falle von Juniper und Arista ist das Programm «tcpdump»auf dem Gerät verfügbar. Es erfasst jedoch nicht den Datenstrom, der das Gerät gerade durchläuft, sondern nur jene Daten, die an die Control Plane gerichtet sind oder von ihr ausgehen. Das können zum Beispiel Pakete von einem Routing-Protokoll sein. Es gibt jedoch mehrere andere Möglichkeiten zu überprüfen, ob bestimmte Daten durch einen Router oder einen Switch laufen.

Die erste Möglichkeit ist eine Zugriffskontrollliste (ACL) mit einem Zähler. Jedes Paket, welches das Gerät passiert und mit der Kontrollliste übereinstimmt, wird gezählt. Die folgenden zwei Beispiele für Junos und EOS zeigen, wie geprüft werden kann, ob Pakete mit der Ziel-IP-Adresse 10.100.35.2 und dem TCP-Zielport 22 über eine bestimmte Schnittstelle in das Gerät gelangen.

set firewall family inet filter TCP-22-MON interface-specific
set firewall family inet filter TCP-22-MON term TCP-22 from destination-address 10.100.35.2/32
set firewall family inet filter TCP-22-MON term TCP-22 from protocol tcp
set firewall family inet filter TCP-22-MON term TCP-22 from destination-port 22
set firewall family inet filter TCP-22-MON term TCP-22 then count TCP-22
set firewall family inet filter TCP-22-MON term TCP-22 then accept
set firewall family inet filter TCP-22-MON term ACCEPT then accept
 
 
set interfaces ge-0/0/0 unit 0 family inet filter input TCP-22-MON
set interfaces ge-0/0/1 unit 0 family inet filter input TCP-22-MON
set interfaces ge-0/0/2 unit 0 family inet filter input TCP-22-MON
set interfaces ge-0/0/4 unit 0 family inet filter input TCP-22-MON

Achtung

Der letzte Begriff mit der Bezeichnung ACCEPT ist wichtig. Ohne ACCEPT würde der gesamte Verkehr abgelehnt, der nicht dem Filter entspricht.

Mit der Anweisung «interface-specific» kann Junos für jede Schnittstelle, auf die der Filter angewendet wird, einen eigenen Zähler erzeugen. Mit «show firewall» können die Zähler dann inspiziert werden.

Junos Verification

umb@mx1> show firewall   
 
Filter: __default_bpdu_filter__                               
 
Filter: TCP-22-MON-ge-0/0/0.0-i                               
Counters:
Name                                                Bytes              Packets
TCP-22-ge-0/0/0.0-i                                  8193                   88
 
Filter: TCP-22-MON-ge-0/0/1.0-i                               
Counters:
Name                                                Bytes              Packets
TCP-22-ge-0/0/1.0-i                                     0                    0
 
Filter: TCP-22-MON-ge-0/0/2.0-i                               
Counters:
Name                                                Bytes              Packets
TCP-22-ge-0/0/2.0-i                                     0                    0
 
Filter: TCP-22-MON-ge-0/0/4.0-i                               
Counters:
Name                                                Bytes              Packets
TCP-22-ge-0/0/4.0-i                                     0                    0
 
umb@mx1>

Auf Aristas EOS sieht die gleiche ACL wie folgt aus:

Arista EOS-Konfiguration

ip access-list TCP-22-MON
counters per-entry
permit tcp any host 10.100.35.2 eq 22
permit ip any any
 
 
interface ethernet 1
ip access-group TCP-22-MON in

Natürlich gibt es auch für EOS einen «show»-Befehl, um die Zähler anzuzeigen.

Arista EOS Verifizierung

show ip access-list TCP-22-MON

Wenn die ACL-Methode nicht ausreicht, beispielsweise weil Header-Felder inspiziert werden müssen, ist die Port-Spiegelung eine Option. Dies erfordert ein Erfassungsgerät, das direkt mit dem Netzwerkgerät verbunden ist. Das ist allerdings oft nicht praktikabel. Glücklicherweise gibt es aber auch die Möglichkeit, eine Remote-Spiegelung durchzuführen. Dabei wird der Datenverkehr nicht auf einen lokalen Port gespiegelt, sondern auf einen GRE-Tunnel. Der Tunnel kann so konfiguriert werden, dass das entfernte Tunnelende die IP-Adresse des Erfassungsgeräts ist. Als Erfassungsgerät kann ein Notebook mit Wireshark eingesetzt werden - vorausgesetzt, es ist genügend Bandbreite verfügbar. Diese Methode wird auch ERSPAN genannt.

Das folgende Beispiel zeigt, wie man einen Juniper MX-Router so konfiguriert, dass er den SSH-Verkehr, der über die Schnittstelle ge-0/0/0 läuft, in einen GRE-Tunnel spiegelt. Die IP-Adresse auf der Tunnelschnittstelle gr-0/0/0.0 muss eingestellt werden, aber es spielt keine Rolle, welche IP-Adresse verwendet wird. Die Ziel-IP-Adresse des Tunnels ist der Ort, an dem Ihr Analysator lauscht.

Junos Remote-Port-Spiegelung

# tunnel services are needed for GRE
set chassis fpc 0 pic 0 tunnel-services
 
# GRE tunnel interface
set interfaces gr-0/0/0 unit 0 tunnel source 10.100.100.3
set interfaces gr-0/0/0 unit 0 tunnel destination 10.100.100.1
set interfaces gr-0/0/0 unit 0 family inet address 10.99.99.1/30
 
# mirroring
set forwarding-options port-mirroring input rate 1
set forwarding-options port-mirroring input run-length 1
set forwarding-options port-mirroring family inet output interface gr-0/0/0.0
 
# firewall filter to match SSH traffic
# the ACCEPT term is needed to not drop all other traffic
set firewall family inet filter MIRROR-SSH term SSH-CLIENT from protocol tcp
set firewall family inet filter MIRROR-SSH term SSH-CLIENT from destination-port 22
set firewall family inet filter MIRROR-SSH term SSH-CLIENT then port-mirror
set firewall family inet filter MIRROR-SSH term SSH-CLIENT then accept
set firewall family inet filter MIRROR-SSH term SSH-SERVER from protocol tcp
set firewall family inet filter MIRROR-SSH term SSH-SERVER from source-port 22
set firewall family inet filter MIRROR-SSH term SSH-SERVER then port-mirror
set firewall family inet filter MIRROR-SSH term SSH-SERVER then accept
set firewall family inet filter MIRROR-SSH term ACCEPT then accept
 
# apply the filter on an interface in both directions
set interfaces ge-0/0/0 unit 0 family inet filter input MIRROR-SSH
set interfaces ge-0/0/0 unit 0 family inet filter output MIRROR-SSH

Auf einem Arista-Switch erreichen wir das Gleiche mit den untenstehenden wenigen Konfigurationszeilen. Beachten Sie, dass IP-Routing aktiviert sein muss, damit dies funktioniert.

Arista Remote-Port-Spiegelung

ip access-list SSH
permit tcp any any eq 22
permit tcp any eq 22 any
 
monitor session 1 source Ethernet1 rx ip access-group SSH
monitor session 1 destination tunnel mode gre source 10.100.100.3 destination 10.100.100.1

Weitere Details und Optionen für Remote Port Mirroring auf Arista EOS sind in diesem umfassenden Artikel auf EOS Central: https://eos.arista.com/advanced-mirroring-features/#Mirroring_To_GRE zu finden (Login erforderlich).

Arista EOS bietet eine weitere nützliche Option für Ad-hoc-Debugging: die Verwendung von tcpdump - verfügbar direkt auf dem Switch. Natürlich gelten die zu Beginn des Artikels erwähnten Einschränkungen weiterhin, und tcpdump auf dem Switch kann nur Datenverkehr der Control Plane erfassen. Allerdings gibt es eine besondere Lösungsvariante: Das Ziel einer Überwachungssitzung kann nämlich nicht nur eine Schnittstelle oder ein Tunnel sein; das Ziel lässt sich auch auf «CPU» setzen. Damit kann das lokale tcpdump-Programm auf dem Switch verwendet werden, um den Datenverkehr zu analysieren. Selbstverständlich ist dies nur bei geringem Verkehrsaufkommen sinnvoll.

Arista Mirroring zur CPU

monitor session 1 destination CPU
 
tcpdump monitor 1

Mit diesen Techniken lassen sich Probleme viel schneller beheben, als wenn man Serveradministratoren an beiden Enden einer Verbindung bitten muss, Paketaufzeichnungen vorzunehmen, oder zum Rechenzentrum zu fahren, um ein Notebook mit Wireshark an einen Mirror-Port anzuschliessen.