@@ Zeile 5: / Zeile 5: @@
 {{var	| display
 		| UTM Fehleranalyse tcpdump
-		|  }}
+		| UTM error analysis tcpdump }}
 {{var	| head
 		| Securepoint UTM Fehleranalyse mit tcpdump
-		|  }}
+		| Securepoint UTM error analysis with tcpdump }}
 {{var	| Einleitung
 		| Einleitung
-		|  }}
+		| Introduction }}
 {{var	| Einleitung--desc
 		| Falls eine TCP/IP-Verbindung mal nicht funktioniert, bietet die Firewall einige Möglichkeiten den Fehlern auf die Spur zu kommen. Konkret gibt es drei Level der Analyse, die immer tiefer in das System hinabsteigen. Das oberste Level ist über das Webinterface erreichbar, die unteren Level benötigen eine Textkonsole, entweder über SSH oder lokal am Gerät.
-		|  }}
+		| If a TCP/IP connection does not work, the firewall offers several ways to track down the errors. Specifically, there are three levels of analysis that descend deeper and deeper into the system. The top level can be accessed via the web interface, the lower levels require a text console, either via SSH or locally on the device. }}
 {{var	| Die Level der Fehleranalyse
 		| Die Level der Fehleranalyse
-		|  }}
+		| The levels of error analysis }}
 {{var	| Level 1: Livelog
 		| Level 1: Livelog
-		|  }}
+		| Level 1: Livelog }}
 {{var	| Livelog--desc
 		| Unter {{Menu-UTM||Log}} ist das Livelog zu finden.
@@ Zeile 37: / Zeile 37: @@
 #Wenn ein Paket angenommen wird, dann liegt der Fehler vermutlich in Richtung Zielhost.
 #Ist kein Paket im Livelog sichtbar, dann kommt vermutlich auch keins an der Firewall an. Der Fehler ist hier vermutlich in Richtung Quellhost zu suchen.
-		|  }}
+		| The live log can be found under {{Menu-UTM||Log}}.
+In addition to application messages, the Livelog also displays messages from the packet filter. By default, however, you can only see if the default policy rejects packets for which there is no suitable firewall rule. However, logging can be configured for each firewall rule so that an entry also appears if this rule takes effect. <br>
+This results in three options for troubleshooting: <br>
+#The packet you are looking for appears and is discarded (DROP)
+#The packet you are looking for appears and is accepted (ACCEPT)
+#The packet you are looking for does not appear
+<br>This allows the cause of the fault to be localized: <br>
+#If a packet is discarded, the appropriate FW rule is missing, it has not been created correctly or is not yet effective (rules have not yet been updated)
+#If a packet is accepted, then the error is probably in the direction of the destination host.
+#If no packet is visible in the live log, then presumably none is arriving at the firewall. The error here is probably in the direction of the source host. }}
 {{var	| Level 2: CLI
 		| Level 2: CLI
-		|  }}
+		| Level 2: CLI }}
 {{var	| CLI--desc
 		| Das CLI (Command Line Interface) stellt die Schnittstelle zum Firewall-Server dar, welche zum einen vom Webinterface genutzt wird, zum anderen auch auf der Konsole zur manuellen Konfiguration der Firewall genutzt werden kann. Für die Fehlersuche bei Verbindungsproblemen ist das CLI allerdings nur von begrenztem Nutzen.
 Das CLI kann über das Webinterface oder über eine Textkonsole erreicht werden. Dazu ist ein Benutzer mit Administrationsrechten notwendig.
-		|  }}
+		| The CLI (Command Line Interface) is the interface to the firewall server, which is used by the web interface and can also be used on the console for manual configuration of the firewall. However, the CLI is only of limited use for troubleshooting connection problems.
+The CLI can be accessed via the web interface or via a text console. This requires a user with administration rights. }}
 {{var	| Level 3: Linux-Shell
 		| Level 3: Linux-Shell
-		|  }}
+		| Level 3: Linux-Shell }}
 {{var	| Linux-Shell--desc
 		| Die Linux-Shell greift auf das zugrundeliegende Betriebssystem zurück. Man erhält Zugriff auf viele Systemparameter, die über das Webinterface oder das CLI nicht zugänglich sind - wenn auch zumeist nur lesend. Mit dem Paketsniffer tcpdump steht auf der linux-Shell ein sehr leistungsfähiges Werkzeug zur Trafficanalyse zur Verfügung.
 Die Linux-Shell erreicht man ausschließlich mithilfe eines Benutzers der root-Berechtigungen hat.
-		|  }}
+		| The Linux shell accesses the underlying operating system. It provides access to many system parameters that are not accessible via the web interface or the CLI - albeit mostly read-only. With the packet sniffer tcpdump, a very powerful tool for traffic analysis is available on the linux shell.
+The Linux shell can only be accessed with the help of a user who has root authorization. }}
 {{var	| Tcpdump auf der root-Konsole
 		| Tcpdump auf der root-Konsole
-		|  }}
+		| Tcpdump on the root console }}
 {{var	| Voraussetzungen
 		| Voraussetzungen
-		|  }}
+		| Requirements }}
 {{var	| Voraussetzungen--desc
 		| Die Voraussetzungen zur Verwendung von tcpdump sind Folgende:
 *Ein User „root“ in der Gruppe Administrator
 *Ein SSH-Client (z. B. PuTTY) oder eine lokale Konsole auf der Firewall
-		|  }}
+		| The requirements for using tcpdump are as follows:
+*A "root" user in the administrator group
+*An SSH client (e.g. PuTTY) or a local console on the firewall }}
 {{var	| Parameter zur Steuerung und Filterung
 		| Parameter zur Steuerung und Filterung
-		|  }}
+		| Parameters for control and filtering }}
 {{var	| Parameter zur Steuerung und Filterung--desc
 		| Die Verwendung von tcpdump ohne Parameter würde einfach JEDES tcp/ip-Paket auf der Konsole
@@ Zeile 74: / Zeile 92: @@
 '''''-i''''' definiert das Interface, an dem ein- oder ausgehende Pakete angezeigt werden sollen.<br>Beispiel:
-		|  }}
+		| Using tcpdump without parameters would simply display EVERY tcp/ip packet on the console. It is therefore necessary to specify a search pattern using appropriate filter parameters.
+'''''-i''''' defines the interface on which incoming or outgoing packets are to be displayed.<br>Example: }}
 {{var	| proto--desc
 		| '''''proto''''' definiert die Protokollnummer auf Transportebene.<br>Beispiele:
-		|  }}
+		| '''''proto''''' defines the protocol number at transport level.<br>Examples: }}
 {{var	| zeigt
 		| zeigt
-		|  }}
+		| shows }}
 {{var	| Pakete
 		| Pakete
-		|  }}
+		| packets }}
 {{var	| port--desc
 		| '''''port''''' definiert tcp- oder udp-ports.<br>Beispiel:
-		|  }}
+		| '''''port''''' defines tcp or udp ports.<br>Example: }}
 {{var	| host--desc
 		| '''''host''''' definiert einen bestimmten Host mit seiner IP als Quelle oder Ziel.<br>Beispiel:
-		|  }}
+		| '''''host''''' defines a specific host with its IP as the source or destination.<br>Example: }}
 {{var	| net--desc
 		| '''''net''''' definiert ein Netzwerk (Quelle oder Ziel)<br>Beispiel:
-		|  }}
+		| '''''net''''' defines a network (source or destination)<br>Example: }}
 {{var	| Verknüpfung--desc
 		| Darüber hinaus lassen sich Filterparameter mit logischen Operatoren verknüpfen. So können folgendermaßen alle ICMP-Pakete für Host 10.0.0.10 angezeigt werden:
-		|  }}
+		| Filter parameters can also be linked to logical operators. In this way, all ICMP packets for host 10.0.0.10 can be displayed: }}
 {{var	| Weitere Steuerungsparameter--desc
 		| Weitere Steuerungsparameter sind beispielsweise:
@@ Zeile 103: / Zeile 123: @@
 '''''-w''''' leitet die Ausgabe in eine Textdatei um. Diese kann dann mit einem Analysetool, z.B. wireshark, weiter untersucht werden. Als Wert wird der Pfad der Textdatei angegeben, z.B. /var/tcpdump.txt
-		|  }}
+		| Further control parameters are for example:
+'''''-n''''' prevents tcpdump from attempting to perform a reverse lookup on IP addresses in order to display host names.
+'''''-s''''' defines the length up to which a packet is recorded. With the value 0, the entire packet is recorded.
+'''''-w''''' redirects the output to a text file. This can then be further examined with an analysis tool, e.g. wireshark. The path of the text file is specified as the value, e.g. /var/tcpdump.txt }}
 {{var	| Die Trafficanalyse
 		| Die Trafficanalyse
-		|  }}
+		| The traffic analysis }}
 {{var	| Trafficanalyse--desc
 		| In unserem Beispiel haben wir zwei Netzwerke der Zentrale und eines Filialstandortes einer Firma, deren Gateways diese Netze mittels eines IPSec-Tunnels miteinander verbinden. Die Zentrale hat das interne Netzwerk 10.0.0.0/24 und die externe Adresse 198.51.100.75. Die Filiale hat das interne Netzwerk 10.4.0.0/24 und die externe Adresse 198.51.100.4. Der Host 10.0.0.10 versucht, den Host 10.4.0.10 zu erreichen, was aber misslingt.
-		|  }}
+		| In our example, we have two networks of the head office and a branch location of a company whose gateways connect these networks with each other via an IPSec tunnel. The head office has the internal network 10.0.0.0/24 and the external address 198.51.100.75. The branch office has the internal network 10.4.0.0/24 and the external address 198.51.100.4. The host 10.0.0.10 tries to reach the host 10.4.0.10, but fails. }}
 {{var	| Initiator-Seite: Intern
 		| Initiator-Seite: Intern
-		|  }}
+		| Initiator site: Internal }}
 {{var	| Initiator-Seite: Intern proto--desc
 		| Wir beginnen unsere Analyse am internen Interface des Gateways der Zentrale. Dazu melden wir uns per ssh als User „root“ dort an und führen folgendes Kommando aus:
-		|  }}
+		| We start our analysis on the internal interface of the gateway of the control center. To do this, we log in there via ssh as user "root" and execute the following command: }}
 {{var	| Initiator-Seite: Intern net--desc
 		| Der Parameter ''proto 1'' bezieht sich auf die Protokollnummer 1 des ICMP-Protokolls auf Transportebene. Alternativ können wir auch nach Paketen suchen, die für das entfernte Subnetz bestimmt sind:
-		|  }}
+		| The parameter ''proto 1'' refers to the protocol number 1 of the ICMP protocol at transport level. Alternatively, we can also search for packets destined for the remote subnet: }}
 {{var	| Initiator-Seite: Intern ping--desc
 		| Versuchen wir jetzt zu ''pingen'', zeigt sich folgendes Ergebnis:
-		|  }}
+		| If we now try to ''ping'', we get the following result: }}
 {{var	| Initiator-Seite: Intern ergebnis--desc
 		| Wir sehen das die Anfragen am internen Interface der zentralen Firewall ankommen. Eine Antwort bleibt allerdings aus.
-		|  }}
+		| We see that the requests arrive at the internal interface of the central firewall. However, there is no response. }}
 {{var	| Initiator-Seite: Extern
 		| Initiator-Seite: Extern
-		|  }}
+		| Initiator site: External  }}
 {{var	| Initiator-Seite: Extern proto--desc
 		| Zur weiteren Verfolgung muss das ausgehende Interface der zentralen Firewall betrachtet werden. Allerdings ergibt sich hier ein Problem: Da wir an dieser Stelle den Transport der übertragenen Daten nur in verschlüsselter Form betrachten können, bleibt uns das ICMP-Paket im Klartext verborgen - und das sollte auch so sein. Wir können allerdings versuchen, eingehendes Klartext- und ausgehendes verschlüsseltes Paket miteinander in Beziehung zu setzen. Wir starten dazu tcpdump mit folgenden Parametern:
-		|  }}
+		| The outgoing interface of the central firewall must be viewed for further tracking. However, there is a problem here: as we can only view the transport of the transmitted data in encrypted form at this point, the ICMP packet remains hidden from us in plain text - and that is how it should be. However, we can try to correlate incoming plain text and outgoing encrypted packets. To do this, we start tcpdump with the following parameters: }}
 {{var	| Initiator-Seite: Extern net--desc
 		| Wir suchen an einer beliebigen Schnittstelle nach ICMP-Paketen oder nach verschlüsselten Paketen. Das hierzu von IPSec verwendete Protokoll ESP hat auf der Transportebene die Protokollnummer 50. Gibt es mehrere IPSec-Verbindungen auf dem Gateway, kann alternativ auch nach Paketen für das entfernte Subnetz oder das entfernte Gateway gesucht werden:
-		|  }}
+		| We search for ICMP packets or encrypted packets at any interface. The ESP protocol used by IPSec for this purpose has the protocol number 50 at the transport level. If there are several IPSec connections on the gateway, it is also possible to search for packets for the remote subnet or the remote gateway: }}
 {{var	| Wir erhalten folgendes Ergebnis:
 		| Wir erhalten folgendes Ergebnis:
-		|  }}
+		| We get the following result: }}
 {{var	| Alternativ Ergebnis--desc
 		| Wir sehen vier ICMP Echo Request-Pakete mit aufeinanderfolgenden Sequenznummern, denen jeweils direkt ein ESP-Paket folgt. Diese ESP-Pakete haben ebenfalls aufeinanderfolgende Sequenznummern. Daraus folgt, dass auf Seiten der zentralen Firewall alle Datenpakete für das entfernte Subnetz verschlüsselt und an das entfernte Gateway geschickt werden.
 Möglicherweise bekommen wir allerdings folgendes Ergebnis:
-		|  }}
+		| We see four ICMP echo request packets with consecutive sequence numbers, each directly followed by an ESP packet. These ESP packets also have consecutive sequence numbers. This means that on the central firewall side, all data packets for the remote subnet are encrypted and sent to the remote gateway.
+However, we may get the following result: }}
 {{var	| Initiator-Seite: Extern Fazit--desc
 		| Wir sehen jedes Paket zwei Mal, erkennbar an der gleichen Sequenznummer. Die zweite Version des Pakets hat allerdings die IP des externen Interfaces als Quelle. Es erfolgte also ein HideNAT über die externe Schnittstelle. In diesem Falle haben wir wahrscheinlich vergessen, innerhalb der Portfilterregel vom eigenen in das entfernte Subnetz die HideNAT-Ausnahme zu setzen oder die Option „Kein NAT für IPSec-Verbindungen“ in den impliziten Regeln zu aktivieren. Infolgedessen wird das Paket, anstatt verschlüsselt in den IPSec-Tunnel zu gehen, geNATtet und in Richtung Default Gateway geschickt.
-		|  }}
+		| We see each packet twice, recognizable by the same sequence number. However, the second version of the packet has the IP of the external interface as its source. A HideNAT was therefore performed via the external interface. In this case, we have probably forgotten to set the HideNAT exception within the port filter rule from our own subnet to the remote subnet or to activate the "No NAT for IPSec connections" option in the implicit rules. As a result, instead of going encrypted into the IPSec tunnel, the packet is NATed and sent towards the default gateway. }}
 {{var	| Responder-Seite: Extern
 		| Responder-Seite: Extern
-		|  }}
+		| Responder site: External }}
 {{var	| Responder-Seite: Extern--desc
 		| Gehen wir davon aus, dass auf dem Gateway der Zentrale alles funktioniert, müssen wir weiter auf dem Gateway der Filiale suchen. Zunächst vergewissern wir uns, dass die verschlüsselten Daten auch an der Gegenstelle ankommen. Das diese von der Zentrale aus abgeschickt werden, heißt noch lange nicht, dass sie auch ankommen! Deshalb führen wir auf der SSH-Konsole auf der Filiale folgendes Kommando aus:
-		|  }}
+		| If we assume that everything is working on the gateway at the head office, we need to look further on the gateway at the branch office. First, we make sure that the encrypted data also arrives at the remote station. The fact that it is sent from the head office does not necessarily mean that it arrives! We therefore execute the following command on the SSH console at the branch office: }}
 {{var	| Das Ergebnis ist folgende Ausgabe:
 		| Das Ergebnis ist folgende Ausgabe:
-		|  }}
+		| The result is the following output: }}
 {{var	| Responder-Seite: Intern
 		| Responder-Seite: Intern
-		|  }}
+		| Responder site: Internal }}
 {{var	| Responder-Seite: Intern proto cmd--desc
 		| Wir können also sicher sein, dass die verschlüsselten Pakete auch am Gateway der Filiale ankommen! Die letzte Etappe ist nun die interne Schnittstelle des Filial-Gateways. Hier schauen wir, ob das ICMP-Paket auch ins interne Netz Richtung Zielhost geschickt wird:
-		|  }}
+		| We can therefore be sure that the encrypted packets also arrive at the store gateway! The last stage is now the internal interface of the store gateway. Here we check whether the ICMP packet is also sent to the internal network in the direction of the target host: }}
 {{var	| Responder-Seite: Intern proto Ausgabe--desc
 		| Ist auch auf dem Gateway der Filiale in Bezug auf Portfilter-Regeln alles korrekt konfiguriert, sollte sich folgende Ausgabe ergeben:
-		|  }}
+		| If everything is also configured correctly on the branch gateway with regard to port filter rules, you should see the following output: }}
 {{var	| Responder-Seite: Intern Zwischenfazit--desc
-		| Daraus können wir eindeutig ersehen, dass der Zielhost zumindestens online und physikalisch erreichbar ist. Warum können wir uns da so sicher sein? Das wird deutlich, wenn wir uns die Ausgabe anschauen, die wir erhalten, wenn wir anstatt des Protokolls ICMP einmal nach Paketen des Zielhosts suchen:
+		| Daraus können wir eindeutig ersehen, dass der Zielhost zu mindestens online und physikalisch erreichbar ist. Warum können wir uns da so sicher sein? Das wird deutlich, wenn wir uns die Ausgabe anschauen, die wir erhalten, wenn wir anstatt des Protokolls ICMP einmal nach Paketen des Zielhosts suchen:
+		| From this we can clearly see that the target host is at least online and physically accessible. Why can we be so sure of this? This becomes clear when we look at the output that we receive when we search for packets from the target host instead of the ICMP protocol: }}
 {{var	| Responder-Seite: Intern Fazit interner Ping--desc
-		| Wir sehen hier, dass vor unseren Pings vom Gateway ein ARP Request ins interne Netz gesendet wird, mit dem die MAC-Adresse des Zielhosts ermittelt werden soll. Darauf erfolgt eine Antwort des Zielhosts, in der er diese mitteilt. Erst dann können IP-Pakete an den Zielhost übermittelt werden. Die Ergebnisse von ARP Requests werden in der Neighbour table, auch ARP-Cache genannt, zwischengespeichert, so dass nicht für jedes IP-Paket ein neuer ARP Request durchgeführt werden muss. Diesen können wir uns mit folgendem Kommando anschauen:
+		| Wir sehen hier, dass vor unseren Pings vom Gateway ein ARP Request ins interne Netz gesendet wird, mit dem die MAC-Adresse des Zielhosts ermittelt werden soll. Darauf erfolgt eine Antwort des Zielhosts, in der er diese mitteilt. Erst dann können IP-Pakete an den Zielhost übermittelt werden. Die Ergebnisse von ARP Requests werden in der Neighbor table, auch ARP-Cache genannt, zwischengespeichert, so dass nicht für jedes IP-Paket ein neuer ARP Request durchgeführt werden muss. Diesen können wir uns mit folgendem Kommando anschauen:
-		|  }}
+		| We can see here that before our pings, the gateway sends an ARP request to the internal network to determine the MAC address of the target host. This is followed by a response from the target host in which it communicates this. Only then can IP packets be transmitted to the target host. The results of ARP requests are temporarily stored in the neighbor table, also known as the ARP cache, so that a new ARP request does not have to be made for every IP packet. We can view this with the following command: }}
-		|  }}
 {{var	| Ausgabe Eintrag zu Zielhost--desc
 		| Wir finden in der Ausgabe unter anderem einen Eintrag, der zu unserem Zielhost gehört:
-		|  }}
+		| Among other things, we find an entry in the output that belongs to our target host: }}
 {{var	| Zielhost online und physikalisch erreichbar--desc
 		| Das beweist eindeutig, dass der Zielhost online und physikalisch erreichbar ist. Wäre er das nicht, würde in der Neighbour table folgender Eintrag stehen:
-		|  }}
+		| This clearly proves that the target host is online and physically accessible. If it were not, the Neighbor table would contain the following entry: }}
 {{var	| Responder-Seite: Intern Fazit--desc
 		| Sofern das Gateway zu mindestens versucht, ein Paket an den Zielhost zuzustellen, liegt der Fehler nicht mehr innerhalb der Tunnel- oder Firewall-Konfiguration, sondern eindeutig am Zielhost. Entweder sehen wir keine IP-Pakete, aber einen Eintrag in die Neighbour table, der uns anzeigt, dass der Zielhost physikalisch nicht erreichbar ist. Oder wir sehen ein IP-Paket und können daraus schließen, dass der Zielhost zwar physikalisch erreichbar ist, aber auf die Verbindungsanfrage aus irgendwelchen Gründen nicht antwortet.
-		|  }}
+		| If the gateway at least attempts to deliver a packet to the target host, the error is no longer within the tunnel or firewall configuration, but clearly at the target host. Either we do not see any IP packets, but an entry in the Neighbor table, which indicates that the target host is physically unreachable. Or we see an IP packet and can conclude from this that the target host is physically reachable but is not responding to the connection request for some reason. }}
 {{var	| Mögliche Fehlerquellen auf dem Zielhost
 		| Mögliche Fehlerquellen auf dem Zielhost
-		|  }}
+		| Possible sources of error on the target host }}
 {{var	| Mögliche Fehlerquellen auf dem Zielhost--desc
 		| Nachdem feststeht, dass der Fehler nur auf dem Zielhost liegen kann, müsste dieser auch dort gefunden werden. Wir können den Fehler aber auch bereits auf dem Gateway auf Responder-Seite weiter eingrenzen, wenn wir betrachten, ob und welche Pakete vom Zielhost zurückkommen:
-		|  }}
+		| Once it has been established that the error can only be on the target host, it should also be found there. However, we can also narrow down the error further on the gateway on the responder side if we look at whether and which packets come back from the target host: }}
-{{var	| Nurnoch NextGen UTM--desc
+{{var	| Nur noch NextGen UTM--desc
 		| Sind nun ausschließlich die von der NextGen UTM ausgehenden Ping sichtbar, dann ist anzunehmen, dass der Zielhost aufgrund einer aktiven lokalen Firewall nicht antwortet:
-		|  }}
+		| If only the outgoing pings from the NextGen UTM are visible, then it can be assumed that the target host is not responding due to an active local firewall: }}
 {{var	| falsch gesetzte Subnetzmaske--desc
 		| Bei folgendem Fehlerbild kann von einer falsch gesetzten Subnetzmaske in der Netzwerkkonfiguration des Zielhosts ausgegangen werden:
-		|  }}
+		| If the following error occurs, an incorrectly set subnet mask in the network configuration of the target host can be assumed: }}
 {{var	| Bestätigung und falsch gesetztes Default Gateway--desc
 		| Der Zielhost versucht, mit einer ARP-Anfrage die MAC-Adresse des Quellhosts zu ermitteln, als wäre dieser im gleichen Subnetz. Das weist eindeutig auf eine fehlerhafte Subnetzmaske hin. Selbst ein falsch gesetztes Default Gateway lässt sich so herausfinden:
-		|  }}
+		| The target host attempts to determine the MAC address of the source host with an ARP request as if it were in the same subnet. This clearly indicates an incorrect subnet mask. Even an incorrectly set default gateway can be detected in this way: }}
 {{var	| Mögliche Fehlerquellen auf dem Zielhost-Fazit--desc
 		| Hier versucht der Zielhost, die MAC-Adresse eines anderen Hosts im gleichen Subnetz zu finden. Da diese Versuche reproduzierbar immer jeweils nach einem ICMP Echo Request-Paket zu sehen sind, ist anzunehmen, dass er versucht, an diesen Host die Antwort zu schicken.
-		|  }}
+		| Here, the target host attempts to find the MAC address of another host in the same subnet. As these attempts can always be seen reproducibly after an ICMP echo request packet, it can be assumed that it is trying to send the response to this host. }}
 {{var	| Weitere Diagnosemöglichkeiten bei tcp-Verbindungen
 		| Weitere Diagnosemöglichkeiten bei tcp-Verbindungen
-		|  }}
+		| Further diagnostic options for tcp connections }}
 {{var	| Weitere Diagnosemöglichkeiten bei tcp-Verbindungen--desc
 		| Über die reine Erreichbarkeit eines Hosts hinaus lassen sich noch weitere Aspekte einer Verbindung untersuchen, wie zum Beispiel der korrekte Aufbau des TCP 3-Wege-Handshakes. Ist in der Antwort auf das initiale Paket (SYN-Flag) das RST-Flag gesetzt, dann wird der Zielhost zwar erreicht, der entsprechende Dienst ist aber nicht erreichbar:
-		|  }}
+		| In addition to the mere accessibility of a host, other aspects of a connection can be examined, such as the correct establishment of the TCP 3-way handshake. If the RST flag is set in the response to the initial packet (SYN flag), the target host is reached, but the corresponding service is not accessible: }}
 {{var	| tiefergehende Analysen--desc
 		| Noch viel tiefergehende Analysen des Datenstroms können erfolgen, wenn dieser komplett mitgeschnitten und in einem Analysetool wie Wireshark untersucht wird:
-		|  }}
+		| Even more in-depth analyses of the data stream can be carried out if it is recorded in its entirety and examined in an analysis tool such as Wireshark: }}

Aktuelle Version vom 6. März 2024, 08:38 Uhr