NAT-Client und -Server und Port schließen

483
croraf

Nehmen wir an, ich habe einen Client und einen Server. Client ist hinter NAT und Server ist öffentlich.

Der Client möchte eine Sitzung mit dem Server haben.

Nehmen wir an, der Client ist auf 192.168.1.1, NAT auf 192.168.1.2 privaten IP-Adressen. Und NAT auf 50.0.0.1 und Server auf 50.0.0.2 öffentlichen IP-Adressen.

Der Client sendet das UDP / IP-Paket (hoffentlich ähnelt es mit TCP / IP) an den Server. Dieses Paket hat seine Quell-IP 192.168.1.1 und den Quellport sagen wir 1000 (zufällig ausgewählt), hat auch den Zielport 50.0.0.2 und den Zielport 2000, da dies die Portanwendung ist, die auf dem Server ausgeführt wird.

Das TCP / IP-Paket kommt bei NAT an, wodurch die Quell-IP in 50.0.0.1 geändert wird. Angenommen, 5000 (zufällig ausgewählt) und der Port wird an den Server geleitet.

Der Server sendet das Antwortpaket mit der Ziel-IP 50.0.0.1 und dem Port 5000.

Das NAT ändert die Ziel-IP des Pakets in 192.168.1.1 und den Zielport in 1000.

  1. Kann der Server jetzt viele UDP / IP-Pakete an dieselbe IP 50.0.0.1 und denselben Port 5000 senden, und alle Pakete werden an den Port 1000 des Clients 192.168.1.1 weitergeleitet?

  2. Wenn ja, wie lange wird dieser Port 5000 auf der öffentlichen Seite von NAT die Pakete an den genannten Client weiterleiten?

  3. Nur die Pakete mit der Quell-IP 50.0.0.2 und dem Quellport 2000 werden an den Client weitergeleitet?

0
Fragen Sie nach den Unterschieden zwischen TCP und UDP in Bezug auf NAT? UDP macht NAT sehr unterschiedlich zu TCP, da TCP Informationen über die virtuelle Verbindung enthält, die für UDP nicht vorhanden ist. Daher können Sie nicht erkennen, dass ein bestimmtes Paket Teil eines vorhandenen Flusses ist. Frank Thomas vor 6 Jahren 1
@FrankThomas TCP enthält KEINE Informationen über die virtuelle Verbindung - und dies würde zumindest teilweise das dynamische Routing unterbrechen, das von allen sehr großen ISPs verwendet wird. https://www.techrepublic.com/article/exploring-the-anatomy-of-a-data-packet/ zeigt den Inhalt eines UDP- und TCP-Headers und erläutert, wie TCP eine zuverlässige Verbindung aushandelt (unter Verwendung von Bestätigungen und Paketsequenzen. keine virtuellen Leitungsinformationen) davidgo vor 6 Jahren 2
@FrankThomas nicht zu verteidigen, was Frank sagt, da er sagt, dass UDP NAT macht, was absoluter Unsinn ist, aber in Bezug auf virtuelle Verbindungen, wo er sagt, dass TCP Informationen über virtuelle Verbindungen enthält, und Sie sagen, dass dies nicht der Fall ist. Dies besagt, dass es https://en.wikipedia.org/wiki/Virtual_circuit sagt: "Es ist möglich, TCP als virtuelle Verbindung zu verwenden, da TCP eine Segmentnummerierung enthält, die eine Neuordnung auf der Empfängerseite ermöglicht, um eine Lieferung außerhalb der Reihenfolge zu ermöglichen . " barlop vor 6 Jahren 0
@barlop Was meinst du mit "UDP macht kein NAT"? Und virtuelle Verbindung in dem von Ihnen erwähnten Sinn ist nicht dasselbe wie Fran erwähnt. In Ihrem Text geht es um die Neuordnung, wodurch das Paket nahtlos über den Kanal (Circuit) ankommt. UDP und TCP sind jedoch hinsichtlich der Identifizierung der IP-Adresse und der Port-Nummer identisch (obwohl TCP sowohl das Quell- als auch das Ziel und nur das UDP-Ziel verwendet). croraf vor 6 Jahren 0
@coraf Warum sollte UDP Quelle und Ziel nicht für das Tracking verwenden? Ich hätte gedacht, dass NAT ohne Source-Tracking sehr schlecht abbrechen würde (stellen Sie sich vor, dass mehrere Geräte hinter NAT alle DNS-Server von Google als Beispiel verwenden. Wenn Sie den Quellport nicht verfolgen, sehe ich nicht, wie dies funktionieren könnte.) davidgo vor 6 Jahren 0
ok, klar misspoke, bitte ersetzen Sie das Wort "Verbindung" durch "virtuelle Verbindung". TCP verfügt über Konnektivitätszustände, die durch Flags und syn / ack-Werte gesteuert werden, die einem Paketfluss Ordnungsmäßigkeit und Kontinuität verleihen (z. B. wissen Sie, dass sie alle auf denselben Fluss bezogen sind und in welcher Reihenfolge sie sich befinden sollen, unabhängig von der Reihenfolge, in der sie ankommen im). für TCP NAT verwendet diese Eigenschaften, um den Verbindungsstatus zu ermitteln. UDP muss Tricks wie Zeitfenster und Adressenabgleich verwenden, um zu bestimmen, dass ein Paar UDP-Pakete miteinander in Beziehung stehen. Frank Thomas vor 6 Jahren 1
@croraf Ich habe das nie gesagt, ich habe nie gesagt, dass es das tat oder nicht, bitte schau zu, wie du mich zitierst. barlop vor 6 Jahren 0
@davidgo Ich habe darüber gesprochen, das Paket "flow" als TCP / UDP-Konzept zu identifizieren, dh zu wissen, zu welchem ​​UDP-Fluss das Paket gehört. Es verwendet nur das Ziel. TCP verwendet sowohl Quelle als auch Ziel. Diese Flusskennung ist eigentlich die Steckdose. Daher enthält TCP keine besondere Identifizierung des Flusses im Vergleich zu UDP. Für "NAT-Fluss" sollte sowohl Quelle als auch Ziel verwendet werden. (Sorry, etwas schwer zu erklären, was ich meine, aber ich denke, wir sind auf derselben Seite.) croraf vor 6 Jahren 0
@croraf - Ich denke, wir kommunizieren nicht miteinander - Meine Behauptung ist, dass UDP wie TCP sowohl die Quell-IP-Schnittstelle als auch die Ziel-IP- und -Port-Adresse verwenden muss, um Daten von Clients zu Server und zurück zu leiten. Wenn die Quell-IP und der Port nicht bis zum Mapping verwendet wurden, wenn zwei DNS-Suchvorgänge außerhalb von NAT durchgeführt werden, sehe ich nicht, wie das NAT-Gerät herausfinden kann, welche Antworten für welchen Client gelten. davidgo vor 6 Jahren 0
@davidgo Zustimmen! croraf vor 6 Jahren 0
@barlop "seit er sagte, UDP macht NAT, was absoluter Quatsch ist" croraf vor 6 Jahren 0
@FrankThomas Um den "Antwortfluss" in UDP und TCP zu identifizieren, verwenden Sie die Quell-IP und den Quellport des Rückgabepakets (Quelle ist jetzt der Server). Hier helfen Ihnen keine Ack / Nack-Sequenznummern oder -Flaggen. croraf vor 6 Jahren 0
@croraf UDP und NAT sind zwei verschiedene Dinge (wie Sie wissen). Es gibt eine Interaktion / Beziehung zwischen NAT und TCP und zwischen NAT und UDP. Zum Beispiel ist NAPT eine Form von NAT, viele Leute verwenden NAPT, und (wie wir wissen), kann NAPT aufgefordert werden, TCP oder UDP zuzulassen an einem bestimmten Hafen. Aber ich würde nicht so eine unbeholfene Sprache verwenden, um zu sagen, dass einer den anderen tut, denn so etwas zu sagen, ist bestenfalls unbeholfen und im schlimmsten Fall (und nicht im schlimmsten Fall) macht es keinen Sinn. Als Analogie: Ein Drucker druckt, ich würde nicht sagen, dass ein Drucker eine Person macht oder nicht, es ist inkohärent. barlop vor 6 Jahren 0
@barlop OK. Ich verstehe jetzt, was Sie gedacht haben. croraf vor 6 Jahren 0

1 Antwort auf die Frage

3
davidgo

Antworten:

  1. Ja.
  2. Dies hängt von der Implementierung von NAT für das Gerät ab. In Linux kann dies durch Bearbeiten von / proc / sys / net / ipv4 / netfilter / ip_conntrack_udp_ * angepasst werden.
  3. Ja - es sei denn, es gibt "verwandte" Ports, die von NAT erkannt werden. In diesem Fall werden zusätzliche NAT-Module verwendet, um die Zusammenhänge zu ermitteln (zumindest unter Linux).

Verwandte Probleme