NAT-Erkennung und Tunnel-Empfehlung

Dieser Artikel beschreibt, wie das Panel NAT-Server automatisch erkennt, zwischen „NAT mit einstellbaren Ports“ und „NAT ohne einstellbare Ports“ unterscheidet und den Nutzer bei Bedarf zum Betrieb über Tunnel führt.

Zuerst verstehen: Was ist NAT

Ein NAT-Server ist ein Server mit „nur einer internen IP, ohne eigene öffentliche IP“. Bei vielen günstigen NAT-VPS gibt der Anbieter beispielsweise eine interne Adresse (etwa 192.168.x.x) aus; du kannst den Server nicht direkt aus dem öffentlichen Netz erreichen, sondern nur über das vom Anbieter bereitgestellte Port-Mapping (bei dem ein öffentlicher Port auf dein internes Netz umgeleitet wird).

Funktionsbeschreibung

Nach dem Hinzufügen eines Servers erkennt das Panel bei erfolgreicher SSH-Verbindung automatisch, ob die Maschine vom NAT-Typ ist (lokal nur interne Adressen, keine eigene öffentliche IP). Wird NAT erkannt, erscheint auf der Server-Karte ein kleines Abzeichen und oben in der „Übersicht“ eine zusammengefasste Erläuterung. Über das gelbe Abzeichen kann der Nutzer bestätigen, ob für diesen NAT-Server im Anbieter-Panel selbst eine Port-Weiterleitung eingerichtet werden kann – und damit entscheiden, ob der Betrieb über Tunnel nötig ist.

Warum man NAT unterscheiden muss

„Interne IP“ ≠ „Tunnel nötig“. NAT-Server zerfallen in zwei Klassen:

Nur für „NAT ohne einstellbare Ports“ ist der Betrieb über Tunnel erforderlich. Bei NAT mit einstellbaren Ports lassen sich die Ports selbst abbilden, er verhält sich wie eine Maschine mit öffentlicher IP und sollte nicht wiederholt erinnert werden.

Erkennungsprinzip

Nach erfolgreicher SSH-Verbindung führt das Panel den Nur-Lese-Befehl ip -4 addr show aus, liest die lokalen Netzwerkkarten-IPs des Servers und prüft, ob sie alle zu internen Segmenten gehören:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 100.64.0.0/10 (CGNAT, NAT auf Betreiberebene)
• 127.0.0.0/8, 169.254.0.0/16, 0.0.0.0/8

Sobald mindestens eine IP aus einem öffentlichen Segment vorhanden ist, gilt der Server als „mit öffentlicher IP“ (kein NAT); sind alle IPs aus internen Segmenten, gilt er als „NAT“.

> Der Erkennungsbefehl ist ausschließlich lesend und ändert keinerlei Zustand des Servers. Das Ergebnis wird in der Datenbank abgelegt, nur beim ersten Verbindungsaufbau einmal ermittelt und danach direkt wiederverwendet – der Verbindungsaufbau wird nicht ausgebremst.

Abzeichen und Position der Erläuterungen

Wird NAT erkannt, erscheint der Hinweis an zwei Stellen:

1. Registerkarte „Übersicht“ im Systemverwaltungs-Panel: Nach dem Klick auf „Systemverwaltung“ auf einer Server-Karte zeigt die erste Registerkarte „Übersicht“ das passende NAT-Hinweisbanner – gelb markierte Server erhalten eine gelbe Erläuterung (mit Anleitung zum Aufheben), rot markierte Server eine rote Tunnel-Anleitung. Der Hinweis erscheint nur bei direkt verbundenen NAT-Servern, die noch nicht bestätigt wurden, und belegt die Karte nicht.

2. Kleines Abzeichen auf der Karte: Auf der Karte bleibt nur ein kleines Abzeichen, mit drei Zuständen:

Das gelbe NAT-Abzeichen steht für „Bestätigung ausstehend“: Ein Klick öffnet einen Bestätigungsdialog mit zwei Optionen:

• „Ports sind in Ordnung, Markierung aufheben“ → das Abzeichen verschwindet, es wird nicht mehr erinnert;
• „Ports nicht erreichbar, als tunnelpflichtig markieren“ → das Abzeichen wird rot und führt zum Betrieb über Tunnel.

Das rote Tunnel nötig ist eine „Warnung“: Ein Klick führt direkt zu Betrieb über Tunnel + Port-Tunneling.

> Warum es keine „automatische Prüfung, ob Ports erreichbar sind“ gibt: Panel-Server und Zielserver können im selben Rechenzentrum stehen; die Prüfung des Panels läuft dann über das interne Netz. Ein „erreichbar“ in diesem Test bedeutet nicht, dass externe Besucher den Port erreichen – das Ergebnis wäre nicht verlässlich. Deshalb wird „Tunnel nötig“ vom Nutzer im gelben Erläuterungsdialog manuell markiert.

Warum NAT-Server „mit der Zeit die Verbindung verlieren“

NAT-Server haben am Gateway des Anbieters einen idle timeout (Zeitüberschreitung für inaktive Verbindungen). Ist eine SSH-Verbindung einige Minuten inaktiv, trennt das Gateway sie stillschweigend (TCP halb offen), ohne dass eine der beiden Seiten es bemerkt.

Das Panel behebt das an zwei Stellen grundlegend:

1. keepalive für SSH-Verbindungen aktiviert: Nach dem Aufbau sendet jede Verbindung alle 30 Sekunden ein Keepalive-Paket – das verhindert sowohl das Trennen durch NAT-Leerlauf als auch, dass halbtote Verbindungen unbemerkt bleiben.

2. Verbindungspool wird regelmäßig aufgeräumt: Ein Hintergrund-Thread schließt alle 2 Minuten Verbindungen, die länger als 2 Minuten ungenutzt sind, damit sich halbtote Verbindungen nicht endlos ansammeln.

Zu beachten

1. Die Erkennung setzt eine erfolgreiche SSH-Verbindung voraus: Ist der Server offline oder das Passwort falsch, ist keine Erkennung möglich und es erscheint kein Abzeichen.

2. Server ohne Abzeichen: Server mit öffentlicher IP, Android-Geräte (Termux) und bereits angebundene Geräte (mit tunnel_token) zeigen kein NAT-Abzeichen – sie nutzen ohnehin ihre eigenen Kanäle und brauchen keine NAT-Erinnerung.

3. Sonderfälle bleiben berücksichtigt: Bei sehr seltenen „1:1-NAT“-Setups (Server mit allen offenen Ports) ist die lokale IP ebenfalls intern und wird als NAT erkannt. Der Nutzer wählt im Bestätigungsdialog einfach „in Ordnung“ – die Nutzung wird nicht beeinträchtigt.

4. Nach der Bestätigung änderbar: Der Zustand des Abzeichens ergibt sich aus der Bestätigung des Nutzers und lässt sich jederzeit per Klick auf das Abzeichen anpassen.

Verwandte Dokumentation

• Serververwaltung
• Betrieb über Tunnel
• Port-Tunneling