WSA-Verhalten bei MTU-Pfaderkennung mithilfe von WCCP

Einleitung

In diesem Dokument wird ein Problem beschrieben, bei dem der Router Pakete verwirft, wenn Ihre Konfiguration sowohl die Erkennung des Web Cache Communication Protocol (WCCP) als auch der Maximum Transmission Unit (MTU) umfasst. Außerdem wird eine Lösung für das Problem beschrieben.

Hintergrundinformationen

Vorphase

Wenn man sie getrennt betrachtet, sind viele Funktionen hervorragend, um ein bestimmtes Problem zu bewältigen. Manchmal jedoch, wenn Sie zwei oder drei Techniken kombinieren, erzeugt es einige unangenehme Verhalten und Sie müssen eine andere Funktion oder Workaround einführen, damit es richtig funktioniert. Die Verwendung von Spanning Tree und Open Shortest Path First (OSPF) und Layer 2 (L2)-Konvergenz dauert beispielsweise länger (20 s) als OSPF (1 s, wenn das minimale Dead-Intervall verwendet wird), ersetzt Spanning Tree jedoch durch Multiple Spanning Tree (MST) und funktioniert wieder ordnungsgemäß.

Dasselbe Interoperabilitätsverhalten wurde zwischen der WCCP- und der Pfad-MTU-Erkennung beobachtet; viele glauben, dass es sich um das Generic Routing Encapsulation (GRE)-Header-Problem handelt. In diesem Dokument wird jedoch die wahre Ursache erläutert.

Separate Path-MTU-Erkennung und WCCP

MTU-Pfaderkennung

Für jede Leitung gilt ein Grenzwert für die zulässige Größe eines Pakets. Wenn Sie ein größeres Paket als unterstützt senden, wird es verworfen. Eine der Aufgaben der unterwegs eingesetzten L3-Geräte (Router) besteht darin, für die Verarbeitung zu sorgen und große Pakete von einer Leitung in die andere zu zerlegen, um sicherzustellen, dass die End-to-End-Kommunikation für die Funktionen der einzelnen Leitungen transparent ist.

Manchmal werden Endhosts jedoch so konfiguriert, dass ihre Pakete nicht gehackt werden können (z. B. verschlüsselte Dateien, Sprachanrufe). Diese Informationen werden über das Don't Fragment (DF)-Bit innerhalb des IP-Headers übermittelt. Router verwerfen Pakete wie diese, aber der Router versucht, dem End-Host über Internet Control Message Protocol (ICMP)-Nachricht (Typ 3-Ziel nicht erreichbar, Code 4 - Fragmentierung erforderlich, aber DF-Bit festgelegt). Auf diese Weise kann der Host in Zukunft kleinere Pakete senden.

Dies ist das Herzstück der MTU-Pfaderkennung. Sie können große Pakete mit festgelegtem DF-Bit senden, um zu sehen, ob sie gegen Ende gesendet werden oder ob Sie wie zuvor beschrieben einen ICMP-Bericht erhalten. Sobald Sie die maximal verwendbare Paketgröße festgelegt haben, verwenden Sie sie für alle weiteren Kommunikationen. Weitere Informationen finden Sie unter RFC 1191.

Die Web Security Appliance (WSA) verwendet standardmäßig die MTU-Pfaderkennung. Daher ist das DF-Bit für alle generierten Pakete in der Standardkonfiguration festgelegt.

WCCP

Wenn Sie dem Web-Datenverkehr ohne Wissen anderer Sicherheit in Ihrem Netzwerk auferlegen müssen, führen Sie deren Datenverkehr über einen nicht sichtbaren Proxy aus. WCCP ist das Protokoll, das für die Kommunikation zwischen dem abfangenden Gerät (Router/Firewall) und der Web-Cache-Engine/dem Proxy, in diesem Fall WSA, verwendet wird.

Dieses Diagramm veranschaulicht den Datenverkehrsfluss in diesem Szenario:

Es funktioniert wie folgt:

1. Der Client sendet HTTP GET mit der IP-Quelle, seiner IP-Adresse (Client-IP-Adresse) und der IP-Adresse des Zielservers.
   
   
2. Die Firewall oder der Router fängt das HTTP GET ab und leitet es über WCCP GRE oder reines L2 an den Web-Cache/WSA weiter. Die Quelle ist weiterhin die Client-IP-Adresse, und das Ziel ist weiterhin die Webserver-IP-Adresse.
   
   
3. Die WSA überprüft die Anfrage und spiegelt sie, wenn sie legitim ist, auf den Webserver wider. Hierbei ist die Ziel-IP-Adresse die IP-Adresse des Webservers, und die Quell-IP-Adresse kann die WSA oder der Client sein, je nachdem, ob Sie Client-IP-Adressen-Spoofing aktiviert haben. Bei diesem Beispiel spielt es keine Rolle, da der zurückfließende Datenverkehr in beiden Fällen die WSA erreichen muss.
   
   
4. Der zurückfließende Datenverkehr wird an der WSA überprüft.
   
   
5. Die WSA sendet die Antwort an den Client mit der Quell-IP-Adresse, IMMER der Webserver-IP-Adresse (damit der Client nicht verdächtig wird) und der Ziel-Client-IP-Adresse.

Problem

Was passiert, wenn einer der Router im Diagramm den Datenverkehr fragmentieren muss? Die WSA setzt das DF-Bit auf Paket Nr. 5, es muss jedoch fragmentiert werden. Der Router verwirft den Code und teilt dem Sender mit, dass eine Fragmentierung erforderlich ist, aber das DF-Bit festgelegt ist (ICMP-Code Typ 3, Code 4). Schließlich muss RFC 1191 jetzt funktionieren, und der Absender muss seine Paketgröße verringern.

Bei WCCP ist die Quell-IP-Adresse die IP-Adresse des Webservers, sodass dieser ICMP nie an die WSA geht, sondern versucht, zum echten Webserver zu gelangen (denken Sie daran, dieser Router unten hat keine Kenntnis von WCCP). Auf diese Weise wird Ihr Netzwerkdesign manchmal durch die gemeinsame Erkennung von WCCP und MTU-Pfaden unterbrochen.

Lösung

Es gibt vier Möglichkeiten, dieses Problem zu lösen:

• Ermitteln Sie die tatsächliche MTU, und verwenden Sie dann etherconfig auf der WSA, um die MTU der Schnittstelle zu verringern. Denken Sie daran, dass der TCP-Header 60 und die IP-Adresse 20 ist. Wenn Sie ICMP verwenden, werden dem IP-Header 8 Byte hinzugefügt.
  
  
• Deaktivieren der MTU-Pfaderkennung (Befehl pathmtudiscovery CLI WSA). Daraus ergibt sich eine TCP-MSS von 536, was zu Leistungsproblemen führen kann.
  
  
• Ändern des Netzwerks, sodass keine L3-Fragmentierung zwischen WSA und Clients vorhanden ist
  
  
• Verwenden Sie den Befehl ip tcp mss-adjust 1360 (oder eine andere berechnete Zahl) auf jedem Cisco-Router, der an den entsprechenden Schnittstellen verwendet wird.

Zusätzliche Hinweise

Während dieses Problem untersucht wurde, wurde festgestellt, dass das Problem für die nächsten vier bis fünf Stunden gelöst wird, wenn Sie den Proxy für einige Minuten explizit auf den Client setzen und ihn dann entfernen. Dies liegt daran, dass der MTU-Pfaderkennungsmechanismus zwischen der WSA und dem Client im expliziten Modus funktioniert. Sobald die WSA die Pfad-MTU erkennt, speichert sie diese zusammen mit der erkannten TCP-MSS in der internen Tabelle als Referenz. Anscheinend wird diese Tabelle alle vier bis fünf Stunden aktualisiert, was dazu führt, dass die Lösung nach so viel Zeit nicht mehr funktioniert.