X
X

Wählen Sie Ihre Währung

$ US Dollar Euro £ British Pound
X
X

Wählen Sie Ihre Währung

$ US Dollar Euro £ British Pound

Wissensdatenbank

StartseiteWissensdatenbankLinux - MultiVPS IPv6+IPv4ICMP - IPv4-Pings und NAT IPv4-Port...

ICMP - IPv4-Pings und NAT IPv4-Portbereichstests

NAT-Portbereichstest

Damit die Anwendung, die Sie über das NAT-IPv4-System ausführen möchten, wie vorgesehen funktioniert, muss sie die folgenden Anforderungen erfüllen:

- Die Anwendung muss Dual-Stack-fähig sein (d. h. IPv4- und IPv6-Konnektivität unterstützen).

- Sie muss in der Lage sein, IPv6- und IPv4-Adressformate (d. h. [::]::0 und 0.0.0.0/0, die Catch-All-Adressen für IPv6 und IPv4) zu empfangen.

- Speziell für die Verwendung von UDP: Sie muss einen kontinuierlichen Paketstrom über UDP senden.

Nahezu alle für Linux geschriebenen Anwendungen unterstützen Dual-Stack-Konnektivität. Bekannte Ausnahmen sind unter anderem:

- SOCKS 4 und SOCKS 4a (wird bei SOCKS 5 unterstützt);

- Docker nur mit Versionen unter 27.0.1 (die am 24. Juni 2024 veröffentlicht wurde). Einige Distributionen implementieren noch die vorherige Version 26, vor allem Debian 12 und 13; Ubuntu 24.04 LTS unterstützt Docker 27.5, was es zu einer brauchbaren Alternative macht;

- Kubernetes (nur Versionen vor Dezember 2021). Debian 10 bietet keine Unterstützung, die erste Unterstützung gibt es bei Debian 11.

- Andere Software vor 2017/2018.

Die NAT-IPv4-IP-Adresse, die in unseren NAT-Port-Rechnern angegeben ist, muss der Anwendung auf dem VPS nicht mitgeteilt werden. Es reicht aus, wenn die Anwendung so konfiguriert ist, dass sie alle Adressen abhört. Der an einen bestimmten Portbereich gesendete Datenverkehr wird automatisch durch unsere NAT-Brücke aufgeteilt und, wenn eine direkte Verbindung über die IPv6-Adresse nicht möglich ist, automatisch über die IPv4-IP weitergeleitet.

Testbeispiele für TCP und UDP

Denken Sie daran: Ports werden für Sie immer automatisch im angegebenen Bereich vorab geöffnet. Sie müssen uns kein Ticket senden.

Beispiel für TCP: Versuchen Sie, /etc/ssh/sshd_config auf einen Port innerhalb des vorhergesagten Portbereichs Ihres VPS zu ändern.

Stellen Sie sicher, dass „PubkeyAuthentication” auf „No” gesetzt und nicht auskommentiert (ohne #) ist und dass „PasswordAuthentication” auf „Yes” gesetzt und nicht auskommentiert ist. Speichern Sie die Änderungen. Führen Sie nun Folgendes aus:

sudo systemctl restart sshd [für Debian, AlmaLinux, Rocky Linux, Fedora] oder

sudo systemctl restart ssh [für Ubuntu]

aus, damit der SSH-Dienst neu gestartet wird. Stellen Sie vor dem Testen sicher, dass er auf beiden Formaten empfangsbereit ist.

Danach können Sie versuchen, sich mit PuTTY, MobaXterm oder einem beliebigen SSH-Client anzumelden, indem Sie die IPv4-Adresse des globalen Servers, den VPS-Linux-Benutzer (root) und den spezifischen Port, den Sie gerade im SSH-Dienst angegeben haben, eingeben.

Dies wurde am 29.10.2024 unter AlmaLinux 9.4 und Debian 12 auf einem MobaXterm-Client unter Windows und einer reinen IPv4-Verbindung mit socat als zugrunde liegender Technologie getestet.

Beispiel für UDP: Installieren Sie netcat-openbsd, verfügbar unter Debian- oder Ubuntu-Systemen. Stellen Sie nach der Installation sicher, dass Sie vor netcat keine weiteren Befehle ausführen möchten, und führen Sie den folgenden Befehl aus:

nc -6 -u -l -p [Nummer Ihres Ports]

wobei [Nummer Ihres Ports] der UDP-exklusive Portbereich ist, den Sie auf Ihrem VPS für NAT IPv4 haben (siehe Knowledge Base-Artikel zur Berechnung des NAT IPv4-Ports).

Der Prozess beginnt, über IPv6 auf dem von Ihnen gewählten Port zu lauschen, und bleibt so.

Versuchen Sie anschließend, etwas (Text, Nachricht usw.) über UDP zu senden:

Von Windows Powershell aus

$message = „Test UDP“; $udpClient = New-Object System.Net. Sockets.UdpClient; $udpClient.Connect(„116.xxx.xxx.xxx“, [Nummer Ihres Ports]); $bytes = [Text.Encoding]::ASCII.GetBytes($message); $udpClient.Send($bytes, $bytes.Length); $udpClient.Close()

Von Linux

echo „Test UDP“ | nc -u -w1 116.xxx.xxx.xxx [Nummer Ihres Ports]

wobei „116.xxx.xxx.xxx” die öffentliche globale IPv4-Adresse auf Serverebene ist, über die Sie verfügen, und [Nummer Ihres Ports] die exklusive UDP-Portnummer ist, die genau mit der Portnummer übereinstimmen muss, auf die Ihr Prozess auf dem VPS hört, UND AUCH genau mit der Portnummer Ihres UDP-Portbereichs übereinstimmen muss.

Wenn Sie „Test UDP” auf Ihrem VPS erhalten, funktioniert alles.

Dies wurde am 29.10.2024 auf einem MobaXterm-Client unter Windows und einem reinen IPv4-Zugang über einen VPS mit Debian 12 getestet. Socat ist ebenfalls die zugrunde liegende Technologie.

Wir können nicht garantieren, dass das „nc”-Paket unter RHEL-basierten Systemen technisch mit dem unter Debian und Ubuntu verfügbaren netcat-openbsd gleichwertig ist (wurde nicht getestet), auch aufgrund ihrer Gewohnheit, Änderungen rückgängig zu machen, aber wir können versichern, dass das netcat-traditional-Paket für diese Aufgabe nicht geeignet ist, da es den Parameter -6 für IPv6-Listening nicht unterstützt.

In Bezug auf die ICMP-Konnektivität über IPv4

Ausgehende ICMP-IPv4-IP-Ping-Anfragen auf MultiVPS außerhalb des zugewiesenen Portbereichs werden aufgrund einer technischen Besonderheit – der ausgeführten DNS64-Implementierung sowohl auf dem Hauptserver als auch beim öffentlichen Service-Fallback – nicht unterstützt. Der Paket-Header wird dabei geändert, und DNS64 muss die Anfrage zunächst in einen geeigneten Domainnamen übersetzen, was bedeutet, dass sie nicht als IP-zu-IP erkennbar ist.

Das Pingen einer IPv4-Adresse wird daher unterstützt, wenn diese IPv4-Adresse als Domainname enthalten ist.

ICMP über direktes IPv6-zu-IPv6 wird in allen Protokollen immer unterstützt, unabhängig davon, ob eine IP-Adresse oder eine Domain angepingt wird.

Wenn Sie IPv4 NAT Ports auf Ihrem VPS berechnen wollen, klicken Sie hier.

Finden Sie nicht die Informationen, die Sie suchen?

Ticket erstellen
Fanden Sie es nützlich?
(2647 mal angesehen / 2 Kunden fanden es hilfreich)

Powered by WISECP
Top