Tunnel und Ports

Wozu eine Portweiterleitung dient

Eine Portweiterleitung öffnet einen Port auf Ihrem Mac und schleust alles, was dort ankommt, durch die SSH-Verbindung bis zu einer Maschine, die nur der entfernte Server erreicht. Für Ihre lokalen Werkzeuge sieht der entfernte Dienst aus, als liefe er auf Ihrem Rechner.

Der Fall, der die meisten Einrichtungen auslöst: eine PostgreSQL-Datenbank auf einem Server, die nur auf 127.0.0.1 lauscht. Erreichbar ist sie damit ausschliesslich vom Server selbst – und das ist die richtige Einstellung. Trotzdem möchten Sie sie von Ihrem Rechner aus in TablePlus oder pgAdmin öffnen. Eine lokale Weiterleitung löst das: Ihr Werkzeug verbindet sich zu 127.0.0.1 auf einem Port Ihrer Wahl, der Verkehr geht verschlüsselt durch SSH hinaus, und die Datenbank bleibt nach aussen geschlossen. In der Firewall des Servers muss kein Port geöffnet werden.

Dieselben drei Mechanismen decken die meisten täglichen Bedürfnisse ab:

• Eine Datenbank, ein Redis oder eine Administrationsoberfläche erreichen, die auf dem Server an localhost gebunden ist.
• Einem Kollegen von aussen einen Dienst zeigen, der auf Ihrer Maschine läuft.
• Den Verkehr eines Browsers über den Server leiten, um eine Website so zu testen, wie sie aus jenem Netz gesehen wird.

Was diese Version kann

Drei Teile sind vorhanden: die Ansicht Tunnels, ein vollständiges und geprüftes Formular zum Anlegen sowie eine nativ geschriebene Engine für Portweiterleitungen. Nur die Verbindung zwischen Formular und Engine fehlt. Praktisch heisst das: Sie können einen Tunnel in Hawser beschreiben, aber nicht starten.

Der Rest dieser Seite beschreibt, was vorhanden und dokumentierbar ist: die Bedeutung der drei Typen, die Felder des Formulars, die Prüfmeldungen. Der letzte Abschnitt zeigt, wie Sie heute einen Tunnel aufbauen – ausserhalb von Hawser. Die vollständige Aufstellung der fehlenden Funktionen steht unter Grenzen und Fehlerbehebung.

Die drei Typen

Local (L) braucht drei Angaben: den Port, den Hawser bei Ihnen öffnet, sowie Host und Port, die vom Server aus angesprochen werden sollen. Der entfernte Host ist meist 127.0.0.1, also der Server selbst; es kann aber ebenso eine andere Maschine sein, die nur der Server sieht, etwa ein Datenbankserver in einem privaten Netz.

Remote (R) läuft in die Gegenrichtung. Hier öffnet der SSH-Server den lauschenden Port. Viele Server weigern sich standardmässig, ihn ausserhalb ihres eigenen Loopbacks anzubieten; entschieden wird das über die Servereinstellung GatewayPorts. Bei einer Ablehnung meldet die Engine protocol error: tcpip_forward: samt der Begründung des Servers.

SOCKS5 (D) öffnet einen lokalen Port, der das SOCKS5-Protokoll spricht. Jedes vom Client angefragte Ziel wird zu einem eigenen SSH-Kanal. Anschliessend stellen Sie Ihren Browser oder macOS auf diesen Proxy ein. Die Engine setzt bewusst nur einen Teil um: ausschliesslich die Methode ohne Authentifizierung, ausschliesslich den Befehl CONNECT, als Ziele IPv4, IPv6 und Domainnamen. Weder BIND noch UDP ASSOCIATE noch Passwortanmeldung.

Einen Tunnel anlegen

Der Tresor muss offen sein und mindestens einen Host mit Protokoll SSH enthalten. Sonst bleibt das Auswahlmenü leer, und nichts lässt sich bestätigen. Siehe Einen Server hinzufügen.

1. Klicken Sie im linken Rail auf Tunnels. Die Kopfzeile wechselt zu « Tunnels », und das Suchfeld verschwindet, denn diese Ansicht lässt sich nicht filtern.
2. Klicken Sie oben rechts auf + Tunnel. Die Befehlspalette bietet denselben Weg: ⌘K, dann « tunnel », dann der Eintrag New tunnel. Ein eigenes Tastaturkürzel für Tunnel gibt es nicht.
3. Wählen Sie unter Type Local (L), Remote (R) oder SOCKS5 (D). Voreingestellt ist Local (L).
4. Wählen Sie unter Via connexion SSH (Über SSH-Verbindung) den Host, der den Tunnel trägt. Das Menü führt nur Hosts mit Protokoll SSH auf, mit ihrem Namen. Einen leeren Eintrag gibt es nicht, und aktualisiert wird das Menü nicht, wenn Sie bei geöffnetem Fenster einen Host hinzufügen.
5. Füllen Sie Port local (Lokaler Port) aus, danach Remote host und Remote port.
6. Klicken Sie auf Démarrer.

Port local steht standardmässig auf 8080, Remote port auf 80, beide begrenzt auf 1 bis 65535. Remote host ist zunächst leer und zeigt 127.0.0.1 als Hinweistext. Bei SOCKS5 (D) verschwinden die beiden Felder für die Gegenstelle: Ein dynamischer Proxy hat kein festes Ziel.

Vier Prüfungen laufen, bevor überhaupt Netzwerkverkehr entsteht. Jede zeigt einen roten Balken und bricht den Vorgang ab:

Starten, stoppen, wiederfinden

Nach dem Klick auf Démarrer wird die Schaltfläche für die Dauer der Verarbeitung deaktiviert und zeigt eine Fortschrittsanzeige. Ein zweiter Klick in dieser Zeit wird übergangen. Dann kommt der Balken Tunnels not implemented in this build. Das Fenster bleibt offen, angelegt wird nichts.

Vorgesehen ist eine Zeile je Tunnel, im Format <type>-forward : <lokaler Port> → <Host>:<Port>, mit dem Namen des tragenden Hosts als Untertitel und einer roten Schaltfläche Stop. Erreicht wird diese Darstellung nie, da die Liste leer bleibt.

Auf der nativen Seite kann die Engine sauber abräumen. Beim Trennen einer SSH-Sitzung bittet sie den Server, die entfernten Weiterleitungen aufzuheben, damit auf einem Bastion kein Port belegt bleibt, und beendet danach die lauschenden Aufgaben. Dieses Verhalten ist da, bleibt aber unbeobachtbar, solange kein Tunnel startet.

Wenn der lokale Port belegt ist

Das ist die erste echte Hürde einer lokalen Weiterleitung. Sie verlangen Port 5432, während auf Ihrem Mac bereits eine PostgreSQL-Instanz läuft – und das Öffnen des Ports scheitert.

Hawser prüft nicht, ob der Port frei ist. Kontrolliert werden allein die Grenzen 1 bis 65535. Der Konflikt zeigt sich erst, wenn die Engine den Lauschposten öffnen will, und zwar als roher Systemfehler: I/O error: Address already in use (os error 48). Ein Port unter 1024 ergibt I/O error: Permission denied, denn diese Ports sind dem Administrator vorbehalten.

Über die Oberfläche sind diese beiden Meldungen heute auf keinem Weg erreichbar: Der Fehler 501 kommt vorher. Sie stehen hier, damit Sie sie wiedererkennen – auch dann, wenn sie vom weiter unten beschriebenen Befehl ssh stammen.

lsof -nP -iTCP:5432 -sTCP:LISTEN

An den Systemberechtigungen liegt es nicht. Hawser fordert auf beiden Vertriebswegen ausdrücklich das Recht an, einen lokalen Lauschport zu öffnen, mit der Portweiterleitung als Begründung. macOS blockiert hier nichts.

Lauschen und Netzsichtbarkeit

Bei den Typen Local (L) und SOCKS5 (D) greift in der Engine eine Schutzregel: Der Lauschport lässt sich nur auf einer Loopback-Adresse öffnen. Zugelassen sind das Wort localhost und jede Loopback-IP, also 127.0.0.0/8 und ::1. Abgewiesen werden 0.0.0.0, ::, jede Adresse aus Ihrem lokalen Netz und jeder DNS-Name, selbst wenn er heute auf 127.0.0.1 zeigt – eine Auflösung kann sich ohne Vorwarnung ändern. Die Ablehnung lautet refusing to bind local-forward on non-loopback host, gefolgt vom angefragten Host.

Für den Typ Remote (R) gilt die Regel nicht: In dieser Richtung öffnet der SSH-Server den Port, und seine Konfiguration entscheidet über die Sichtbarkeit.

Bis dahin: Tunnel im Terminal

Solange die Tunnel-Ansicht nicht angeschlossen ist, erledigt der mit macOS gelieferte Befehl ssh die Arbeit. Er ist von Hawser unabhängig: Der Tunnel taucht in keiner Ansicht der App auf und endet, sobald Sie das Terminalfenster schliessen.

Die beiden anderen Formen folgen derselben Logik: ssh -N -R 8080:127.0.0.1:3000 admin@serveur lässt den Server auf seinem Port 8080 lauschen und leitet auf Ihren Port 3000 weiter; ssh -N -D 1080 admin@serveur öffnet lokal einen SOCKS5-Proxy auf Port 1080.

Immerhin die Kurznamen kann Hawser liefern: ⌘K, dann « Exporter en config OpenSSH » (Als OpenSSH-Konfiguration exportieren) erzeugt eine Datei ssh_config mit den Zeilen Host, HostName, User und Port Ihrer SSH-Hosts. Deren Inhalt übertragen Sie selbst in ~/.ssh/config. Weder IdentityFile noch Schlüssel noch Passwörter stehen in dieser Datei.