AUF DIESER SEITE
Beispiel: Konfigurieren von TCP-Paketsicherheitsprüfungen pro Richtlinie
Beispiel: Deaktivieren der TCP-Paketsicherheitsprüfungen für Services Gateways der SRX-Serie
Beispiel: Festlegen der maximalen Segmentgröße für alle TCP-Sitzungen für Firewalls der SRX-Serie
Verstehen, wie die Beibehaltung eingehender Fragmentierungsmerkmale den Durchsatz verbessern kann
TCP-Sitzungen
Um Daten über TCP in einem Netzwerk zu senden, wird ein Drei-Wege-Handshake-Sitzungsgründungsprozess befolgt. Es gibt einen Prozess zum Starten einer Sitzung und es gibt auch einen Prozess zum Beenden der TCP-Sitzung. Dieses Thema hilft Ihnen, den Prozess bei der Verarbeitung einer TCP-Sitzung zu verstehen.
Grundlegendes zu TCP-Sitzungsprüfungen pro Richtlinie
Standardmäßig sind die Optionen TCP-SYN-Prüfung und Sequenzprüfung für alle TCP-Sitzungen aktiviert. Das Junos-Betriebssystem (Junos OS) führt während TCP-Sitzungen die folgenden Vorgänge aus:
Prüft im ersten Paket einer Sitzung auf SYN-Flags und lehnt alle TCP-Segmente mit Nicht-SYN-Flags ab, die versuchen, eine Sitzung zu initiieren.
Überprüft die TCP-Sequenznummern während der zustandsbehafteten Überprüfung.
Mit der Funktion TCP-Sitzungsprüfung pro Richtlinie können Sie SYN- und Sequenzprüfungen für jede Richtlinie konfigurieren. Derzeit sind die TCP-Optionsflags no-sequence-check und no-syn-check auf globaler Ebene verfügbar, um das Verhalten von Services Gateways zu steuern. Zur Unterstützung richtlinienspezifischer TCP-Optionen stehen die folgenden zwei Optionen zur Verfügung:
sequence-check-required: Der Wert sequence-check-required überschreibt den globalen Wert no-sequence-check.
syn-check-required: Der Wert syn-check-required überschreibt den globalen Wert no-syn-check.
Um richtlinienspezifische TCP-Optionen zu konfigurieren, müssen Sie die entsprechenden globalen Optionen deaktivieren. Andernfalls schlägt die Commit-Prüfung fehl. Wenn globale TCP-Optionen deaktiviert sind und der SYN-Flood-Schutz das erste Paket zulässt, steuern die richtlinienspezifischen TCP-Optionen, ob SYN- und/oder Sequenzprüfungen durchgeführt werden.
Die richtlinienspezifische Option überschreibt das Verhalten des
set security flow tcp-session no-syn-check-in-tunnelCLI-Befehlssyn-check-requirednicht.Das Deaktivieren der globalen SYN-Prüfung verringert die Effektivität des Geräts bei der Abwehr von Paketfluting.
Das Deaktivieren der globalen SYN-Prüfung und das Erzwingen der SYN-Prüfung nach der Richtliniensuche wirkt sich stark auf die Anzahl der Pakete aus, die der Router verarbeiten kann. Dies wiederum führt zu intensiven CPU-Operationen. Wenn Sie die globale SYN-Prüfung deaktivieren und die richtlinienspezifische Erzwingung der SYN-Prüfung aktivieren, sollten Sie sich dieser Leistungsbeeinträchtigung bewusst sein.
Deaktivieren von TCP-Paketsicherheitsprüfungen
Bei einer Firewall der SRX-Serie können Sie Sicherheitsprüfungen für TCP-Pakete deaktivieren, um die Interoperabilität mit Hosts und Geräten mit fehlerhaften TCP-Implementierungen sicherzustellen.
Die no-sequence-check Option deaktiviert TCP-Sequenzprüfungen. Außerdem erhöht sich der Durchsatz.
Der set security flow tcp-session no-sequence-check Befehl deaktiviert die TCP-Sequenzprüfungen für alle TCP-Sitzungen im Standard- oder Hash-basierten Modus.
Beispiel: Konfigurieren von TCP-Paketsicherheitsprüfungen pro Richtlinie
In diesem Beispiel wird gezeigt, wie TCP-Paketsicherheitsprüfungen für jede Richtlinie auf dem Gerät konfiguriert werden.
Anforderungen
Bevor Sie beginnen, müssen Sie die tcp-Optionen deaktivieren, tcp-syn-checkdie tcp-sequence-check auf globaler Ebene konfiguriert sind.
Überblick
Die Optionen SYN und Sequenzprüfung sind standardmäßig für alle TCP-Sitzungen aktiviert. In Umgebungen, in denen große Dateiübertragungen unterstützt werden müssen oder in denen nicht standardmäßige Anwendungen ausgeführt werden, kann es erforderlich sein, Sequenz- und Synchronisierungsprüfungen für jede Richtlinie unterschiedlich zu konfigurieren. In diesem Beispiel konfigurieren Sie die Sequenz- und Synchronisierungsprüfung für Richtlinien pol1.
Konfiguration
Verfahren
Schritt-für-Schritt-Anleitung
So konfigurieren Sie TCP-Paketsicherheitsprüfungen auf Richtlinienebene:
Konfigurieren Sie die Überprüfung auf das TCP-SYN-Bit, bevor Sie eine Sitzung erstellen.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options syn-check-required
Konfigurieren Sie die Überprüfung auf Sequenznummern in TCP-Segmenten während der zustandsbehafteten Überprüfung.
[edit] user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options sequence-check-required
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit] user@host# commit
Verifizierung
Um zu überprüfen, ob die Konfiguration ordnungsgemäß funktioniert, geben Sie den show security policies detail Befehl ein.
Beispiel: Deaktivieren der TCP-Paketsicherheitsprüfungen für Services Gateways der SRX-Serie
In diesem Beispiel wird gezeigt, wie TCP-Paketsicherheitsüberprüfungen auf dem Gerät deaktiviert werden.
Anforderungen
Bevor Sie beginnen, sollten Sie sich mit den Umständen für die Deaktivierung von TCP-Paketsicherheitsüberprüfungen vertraut machen. .
Überblick
Junos OS bietet einen Mechanismus zum Deaktivieren von Sicherheitsprüfungen für TCP-Pakete, um die Interoperabilität mit Hosts und Geräten mit fehlerhaften TCP-Implementierungen sicherzustellen. Bei der No-SYN-Prüfung sucht das Junos-Betriebssystem nicht nach dem TCP-SYN-Paket für die Sitzungserstellung. Die Überprüfung ohne Sequenz deaktiviert die Validierung der TCP-Sequenzprüfung. Erhöht auch den Durchsatz. SYN-Prüfung und Sequenzprüfung sind standardmäßig aktiviert. Der Befehl set security flow deaktiviert TCP-SYN-Prüfungen und TCP-Sequenzprüfungen für alle TCP-Sitzungen und verringert somit die Sicherheit. Dies kann in Szenarien mit Kunden wie großen Übertragungsdateien oder bei Anwendungen, die nicht korrekt mit Standards arbeiten, erforderlich sein.
Konfiguration
Verfahren
Schritt-für-Schritt-Anleitung
Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen hierzu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.
So deaktivieren Sie TCP-Paketsicherheitsprüfungen:
Deaktivieren Sie die Überprüfung des TCP-SYN-Bits, bevor Sie eine Sitzung erstellen.
[edit security flow] user@host# set tcp-session no-syn-check
Deaktivieren Sie die Überprüfung von Sequenznummern in TCP-Segmenten während der zustandsbehafteten Überprüfung.
[edit security flow] user@host# set tcp-session no-sequence-check
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit ] user@host# commit
Verifizierung
Um zu überprüfen, ob die Konfiguration ordnungsgemäß funktioniert, geben Sie den show security flow Befehl ein.
Beispiel: Festlegen der maximalen Segmentgröße für alle TCP-Sitzungen für Firewalls der SRX-Serie
Dieses Beispiel zeigt, wie die maximale Segmentgröße für alle TCP-Sitzungen für Firewalls der SRX-Serie festgelegt wird.
Anforderungen
Bevor Sie beginnen, sollten Sie sich mit den Umständen für das Festlegen der maximalen Segmentgröße vertraut machen.
Überblick
Sie können alle TCP-Sitzungen beenden, indem Sie die maximale TCP-Segmentgröße (TCP-MSS) ändern. Um die Wahrscheinlichkeit einer Fragmentierung zu verringern und um sich vor Paketverlust zu schützen, können Sie tcp-mss verwenden, um einen niedrigeren TCP-MSS-Wert anzugeben. Dies gilt für alle TCP-SYN-Pakete, die die Eingangsschnittstellen des Routers durchlaufen, deren MSS-Wert höher ist als der von Ihnen angegebene.
Wenn das DF-Bit festgelegt ist, wird das Paket nicht fragmentiert, und Junos OS sendet ein ICMP-Fehlertyp 3 Code 4-Paket an den Anwendungsserver (Ziel nicht erreichbar; Fragmentierung erforderlich und DF festgelegt). Diese ICMP-Fehlernachricht enthält die korrekte MTU (wie in tcp-mss definiert), die vom Anwendungsserver verwendet werden soll, der diese Nachricht empfangen und die Paketgröße entsprechend anpassen soll. Dies ist insbesondere bei VPNs erforderlich, da IPsec zusätzlichen Paket-Overhead hat. Daher muss TCP-MSS entsprechend gesenkt werden.
Wenn Sie Firewalls der SRX-Serie im Paketmodus ausführen, verwenden Sie die , set system internet-options tcp-mss um den TCP-MSS-Wert anzupassen. Alle Ports sind von der TCP-MSS-Konfiguration betroffen. Sie können einen bestimmten Port nicht ausschließen. Wenn Sie Firewalls der SRX-Serie im Flow-Modus ausführen, können Sie zwar die set system internet-options tcp-mss verwenden, empfehlen wir, nur die set security flow tcp-mss zu verwenden, um den TCP-MSS-Wert anzupassen. Wenn beide Anweisungen konfiguriert sind, wird der niedrigere der beiden Werte wirksam.
Konfiguration
Verfahren
Schritt-für-Schritt-Anleitung
So konfigurieren Sie die maximale Segmentgröße für alle TCP-Sitzungen:
Legen Sie die maximale TCP-Segmentgröße für alle TCP-Sitzungen fest.
[edit security flow] user@host# set tcp-mss all-tcp mss 1300
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
[edit ] user@host# commit
Befund
Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show security flow Befehl eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.
Der Kürze halber enthält diese show Befehlsausgabe nur die Konfiguration, die für dieses Beispiel relevant ist. Alle anderen Konfigurationen auf dem System wurden durch Auslassungspunkte (...) ersetzt.
[edit]
user@host# show security flow
...
tcp-mss{
all-tcp{
mss 1300;
}
}
...
Verifizierung
Um zu überprüfen, ob die Konfiguration ordnungsgemäß funktioniert, geben Sie den Befehl aus dem show configuration security flow Betriebsmodus ein.
user@host> show configuration security flow
tcp-mss{
all-tcp{
mss 1300;
}
}
TCP Out-of-State Packet Drop-Protokollierung – Übersicht
Wenn in einem paketvermittelten Netzwerk die Nachfrage die verfügbare Kapazität übersteigt, werden die Pakete in die Warteschlange gestellt, um die überschüssigen Pakete aufzubewahren, bis sich die Warteschlange füllt, und dann werden die Pakete verworfen. Wenn TCP in einem solchen Netzwerk arbeitet, ergreift es alle Korrekturmaßnahmen, um eine fehlerfreie End-to-End-Kommunikation aufrechtzuerhalten.
Flow-Module unterstützen bereits das Generieren von RTLOGS für sitzungsbasierte Ereignisse wie Sitzungserstellung und Sitzungsabschluss. Die Firewalls der SRX-Serie unterstützen jetzt die Generierung von RTLOG für paketbasierte Ereignisse wie Paketverlust, ohne dass eine Sitzung vorhanden ist.
Firewalls der SRX-Serie unterstützen die Protokollierung von nicht synchronisierten TCP-Out-of-State-Paketen, die vom Flow-Modul verworfen werden.
Die TCP-Protokollierungsfunktion für Paketverluste außerhalb des Status vermeidet Paketverluste und ermöglicht die Paketwiederherstellung, indem die nicht synchronisierten Pakete für eine fehlerfreie Kommunikation protokolliert werden, und verhindert, dass die Datenbankserver nicht mehr synchron sind. Diese Funktion baut auf der RTLOG-Funktion (Security Log) auf.
Die TCP-Protokollierung von Paketverlusten außerhalb des Status unterstützt das Auffangen von TCP-Paketverwerfungsprotokollen unter den folgenden Bedingungen:
Session ages out– Wenn Cloud-Anwendungen auf langen TCP-Sitzungen ausgeführt werden und diese Anwendungen die TCP-Sitzungen nach Ablauf der Sitzung nicht aktualisieren, werden die TCP-Pakete verworfen. Diese Funktion unterstützt die Protokollierung dieser verworfenen TCP-Pakete.
Unsynchronized first packets due to attacks or asymmetric routes—Wenn Sie Firewalls der SRX-Serie an zwei Standorten bereitstellen und Routing manchmal asymmetrischen Datenverkehr erzwingt, wird das Synchronisationspaket (SYN) an einem Standort angezeigt, die Synchronisationsbestätigungspakete (SYN_ACK) jedoch an einem anderen Standort.
Dies bedeutet, dass die Firewall der SRX-Serie ein TCP-ACK-Paket erkennt, für das kein passender Statustabelleneintrag vorhanden ist. Dies kann daran liegen, dass die Verbindung für einen bestimmten Zeitraum inaktiv war oder die Verbindungstabellen geleert wurden (z. B. aufgrund einer Richtlinieninstallation oder eines Neustarts).
Die SYN_ACK Pakete, die in diesem Fall an einem anderen Standort zu sehen sind, wurden von der Firewall der SRX-Serie zurückgewiesen, aber nicht protokolliert. Diese Funktion unterstützt die Protokollierung der verweigerten SYN_ACK Pakete.
Other out-of-state conditions (like TCP sequence check fail and synchronization packet received in FIN state)—Wenn eine Firewall der SRX-Serie einen Sequenzfehler erkennt, wenn sich das Gerät im TCP-Vier-Wege-Schließzustand befindet, aber SYN-Pakete empfängt, oder wenn ein Drei-Wege-Handshake-Fehler auftritt, verwirft die Firewall der SRX-Serie die TCP-Pakete, und diese verworfenen Pakete werden protokolliert.
Das nicht synchronisierte TCP-Out-of-State-Paketverlustprotokoll ist ein paketbasiertes Protokoll, kein sitzungsbasiertes Protokoll.
Die TCP-Protokollierung von Paketverlusten außerhalb des Zustands ist mit einem Drosselungsmechanismus ausgestattet, um die CPU vor Angriffen zu schützen, und innerhalb jedes Drosselungsintervalls können einige Protokolle verworfen werden.
Es werden nur TCP-Pakete außerhalb des Status protokolliert, die vom Flow-Modul verworfen wurden. TCP-Pakete, die von TCP-Proxy und IDP verworfen werden, werden nicht protokolliert.
- Grundlegendes zur TCP-Protokollierung von Paketverlusten außerhalb des Status
- Unterstützte TCP-Protokollierungsfunktionen für Out-of-State-Protokollierung
Grundlegendes zur TCP-Protokollierung von Paketverlusten außerhalb des Status
Um die Implementierung der TCP-Protokollierung von Paketverlusten außerhalb des Status zu verstehen, bedenken Sie, dass Sie Firewalls der SRX-Serie an zwei Standorten bereitstellen und dass Routing manchmal asymmetrischen Datenverkehr erzwingt, bei dem das SYN-Paket an einem Standort angezeigt wird, das SYN_ACK Paket jedoch an einem anderen Standort. Das SYN_ACK Paket wird in diesem Fall verweigert, aber nicht protokolliert. Die TCP-Protokollierungsfunktion für Paketverluste außerhalb des Status bietet Einblick in diese nicht synchronisierten Paketverluste.
Stellen Sie sich das Szenario vor, in dem Datenbanken im Datencenter ihre TCP-Sockets offen halten, ohne dass Keepalives gesendet werden. Wenn keine Daten übertragen werden, führt die Firewall der SRX-Serie eine Zeitüberschreitung der Sitzungen durch. Obwohl die Datenbanken einige Daten über diesen TCP-Socket senden, ist die Sitzung nicht mehr vorhanden, wenn der Datenverkehr die Firewall der SRX-Serie erreicht, und das Paket wird verworfen, aber nicht protokolliert. Diese verworfenen TCP-Pakete außerhalb des Status werden jetzt von der Firewall der SRX-Serie protokolliert.
Unterstützte TCP-Protokollierungsfunktionen für Out-of-State-Protokollierung
Die TCP-Protokollierung außerhalb des Zustands unterstützt die folgenden Features:
Eine Paketfilterkomponente zum Filtern des Zieldatenverkehrs.
Eine Drosselungskomponente zum Schutz der CPU vor Überlastung durch Protokollmeldungen.
Flexibilität, um die Protokollgenerierungsrate zu ändern.
- Paketfilter-Komponente
- Throttle-Komponente
- Flexibilität bei der Änderung der Protokollgenerierungsrate
Paketfilter-Komponente
Der Protokollierungsfilter nutzt den aktuellen Ablaufverfolgungsfilter. Es bietet verschiedene Möglichkeiten zum Filtern des Datenverkehrs. Sie müssen die Filter so konfigurieren, dass Paketprotokolle generiert werden, da andernfalls keine Protokolle ausgelöst werden.
Diese Filterfunktion verhindert, dass Protokolle unerwartet aktiviert werden. Es werden maximal 64 Filter unterstützt.
Verwenden Sie den set security flow packet-log packet-filter <filter-name> Befehl, um die zugehörigen Filterkomponenten zu aktivieren, die Sie benötigen.
Throttle-Komponente
Die Protokollierung jedes TCP-Out-of-State-Pakets kann das Gerät überlasten, wenn der Datenverkehr stark ist oder wenn ein Angriff stattfindet. Wenn sich die CPU im Leerlauf befindet und Sie so viele Nachrichten wie möglich protokollieren möchten, kann dies zu einer CPU-Überlastung führen.
Mit dem Drosselungsmechanismus können Sie das Drosselungsintervall über die CLI konfigurieren, sodass Sie Ihre CPU vor Überlastung schützen können.
Es wird eine Hashtabelle eingeführt, um Ihre protokollierten Daten zuzuordnen. Der Hash-Schlüssel wird mit der Quell-IP-Adresse, der Ziel-IP-Adresse, dem Quellport und dem Zielport generiert.
Innerhalb jedes Drosselungsintervalls wird nur eine begrenzte Anzahl (mehr als eine) von Nachrichten an RTLOG gesendet. Die verbleibenden Protokollmeldungen werden gedrosselt.
Das standardmäßige Drosselungsintervall beträgt 1 Sekunde. Das Drosselklappenintervall (im Millisekundenbereich) muss als Zweierpotenz oder Null (0, 1, 2, 4, 8, 16 ... 2^N).
Wenn das Drosselungsintervall als 0 konfiguriert ist, ist kein Drosselungsmechanismus beteiligt. Dies eignet sich für Szenarien, in denen der Datenverkehr sehr gering ist und Sie alle Paketverlustprotokolle aufzeichnen möchten.
Die Konfiguration des Drosselungsintervalls als 2^N macht den Drosselklappenmechanismus sperrlos und bietet eine gute Protokollerfassungsleistung.
Flexibilität bei der Änderung der Protokollgenerierungsrate
Basierend auf dem eingestellten Drosselungsintervall kann die Protokollgenerierungsrate geändert und verwaltet werden.
Dies bedeutet, dass innerhalb jedes Intervalls von 32 Millisekunden (ms) eine begrenzte Anzahl von Protokollen generiert und die verbleibenden verworfen werden können. Wir empfehlen, das Intervall wie folgt zu konfigurieren: (0, 1, 2, 4, 8, 16, 32 ... 2^N).
Wenn der Eingabewert nicht an 2^N ausgerichtet ist, wird er während der Flussverarbeitung automatisch an 2^N ausgerichtet. Wenn Sie z. B. ein 10-ms-Intervall konfigurieren, wird es automatisch an ein 8-ms-Intervall angepasst.
Verstehen, wie die Beibehaltung eingehender Fragmentierungsmerkmale den Durchsatz verbessern kann
In diesem Thema werden die Vorteile der Verwendung der Firewall der SRX-Serie behandelt, um die Eigenschaften eingehender Paketfragmente beizubehalten.
Wenn Daten von einem Host an einen anderen gesendet werden, werden sie als eine Reihe von Paketen übertragen. Die Leistung wird verbessert und Netzwerkressourcen werden geschont, wenn Pakete der größten Größe den Pfad vom Quellknoten zum Zielknoten übertragen können, ohne an einer Verbindung im Datenpfad fragmentiert zu werden. Wenn ein Paket in kleinere Pakete fragmentiert werden muss, um eine Verbindung im Pfad zu übertragen, weil das Paket größer ist als das der maximalen Übertragungseinheit (Maximum Transmission Unit, MTU), die für diese Verbindung festgelegt wurde, muss jedes der resultierenden Fragmente zusätzlich zur Nutzlast oder den Daten Paket-Header-Informationen enthalten. Der erhöhte Overhead kann den Durchsatz verringern und die Netzwerkleistung beeinträchtigen. Außerdem müssen die Paketfragmente am Zielknoten wieder zusammengesetzt werden, was zusätzliche Netzwerkressourcen verbraucht.
Andererseits werden Netzwerkressourcen verschwendet, wenn ein Host Pakete sendet, die viel kleiner sind als die Pfad-MTU (Path Maximum Transmission Unit), was zu einem suboptimalen Durchsatz führt. Der MTU-Pfaderkennungsprozess ermittelt die optimale MTU-Größe für Fragmente, die den Datenpfad vom Quellknoten zum Zielknoten für eine Sitzung übertragen. Die optimale Paketgröße ist also die der Pfad-MTU. Eine Fragmentierung tritt auf, wenn die Größe eines Pakets die MTU des Pfads überschreitet.
Wenn Services auf Anwendungsebene auf der Firewall der SRX-Serie konfiguriert sind, müssen Paketfragmente an der Eingangsschnittstelle neu zusammengesetzt werden, bevor die Services angewendet und der Inhalt überprüft werden kann. Diese wieder zusammengesetzten Paketfragmente müssen wieder zerlegt werden, bevor die Daten von der Ausgangsschnittstelle übertragen werden. Normalerweise bestimmt die MTU-Größe der Ausgangsschnittstelle die Größe der Fragmente, die von der Firewall der SRX-Serie an die nächste Verbindung übertragen werden. Es könnte der Fall sein, dass die Ausgangs-MTU-Größe auf der Firewall der SRX-Serie größer ist als die Pfad-MTU, was wiederum zu einer Paketfragmentierung im Datenpfad führen würde, was die Leistung verringert oder Paketverluste verursachen würde. Paketfragmente müssen klein genug sein, um jede Verbindung auf dem Pfad von der Quelle zum Ziel zu übertragen.
Standardmäßig verwendet die Firewall der SRX-Serie die für die Ausgangsschnittstelle konfigurierte MTU-Größe, um die Größe der von ihr übertragenen Paketfragmente zu bestimmen. Wenn Sie jedoch die Funktion zum Beibehalten der Eigenschaften eingehender Fragmente aktivieren, erkennt und speichert die Firewall der SRX-Serie die Größe eingehender Paketfragmente.
Um die Wahrscheinlichkeit einer Paketfragmentierung im Datenpfad zu verringern, verfolgt die Firewall der SRX-Serie die Ausgangs-MTU für diesen Datenstrom und passt sie an. Es identifiziert die maximale Größe aller eingehenden Fragmente. Er verwendet diese Informationen in Verbindung mit der vorhandenen MTU der Ausgangsschnittstelle, um die richtige MTU-Größe für fragmentierte Pakete zu bestimmen, die von der Ausgangsschnittstelle gesendet werden. Die Firewall der SRX-Serie vergleicht die beiden Zahlen. Es nimmt die kleinere Zahl und verwendet sie für die MTU-Größe der Ausgangsschnittstelle.
Konfigurieren Sie das Gerät mit dem set security flow preserve-incoming-frag-size Befehl, um die Funktion zu aktivieren, die die Größe der eingehenden Paketfragmente berücksichtigt.
Tabelle 1 fasst zusammen, wie die Ausgangs-MTU-Größe der SRX-Serie bestimmt wird.
Größe des eingehenden Fragments |
Vorhandene Ausgangs-MTU-Größe |
Endgültige Ausgangs-MTU-Größe |
|---|---|---|
Wenn das größte Fragment |
kleiner als die vorhandene Ausgangs-MTU-Größe |
Es wird die größte eingehende Fragmentgröße verwendet. |
Wenn das größte Fragment |
größer als die vorhandene Ausgangs-MTU-Größe |
vorhandene MTU für die Ausgangsschnittstelle verwendet wird. |
Diese Funktion wird von Firewalls der SRX-Serie unterstützt. Es unterstützt Durchgangsverkehr und Datenverkehr, der einen Tunnel verlässt. Sie gilt sowohl für IPv4- als auch für IPv6-Datenverkehr.
Die folgenden beiden Überlegungen wirken sich auf die Fragmentgröße aus:
Bei Stream-basierten Anwendungen wie Content Security und ALG können die Anwendungen selbst Pakete ändern oder neu zusammensetzen, auch wenn keine Fragmente empfangen wurden. In diesem Fall wird die vorhandene MTU für die Ausgangsschnittstelle verwendet.
Wenn ein Pfad-MTU-Erkennungspaket an eine Sitzung übermittelt wird, wird die Pfad-MTU für diese Sitzung auf den Wert zurückgesetzt, der durch das Pfad-MTU-Paket festgelegt wurde.
Tabelle "Änderungshistorie"
Die Funktionsunterstützung hängt von der Plattform und der Version ab, die Sie verwenden. Verwenden Sie den Feature-Explorer , um festzustellen, ob ein Feature auf Ihrer Plattform unterstützt wird.
set security flow preserve-incoming-frag-size Befehl, um die Funktion zu aktivieren, die die Größe der eingehenden Paketfragmente berücksichtigt.