Neues tool: remusock -- remote Unix socket access

Zirias

Well-Known Member
Ich hab mir ein neues Tool gebaut. Der Zweck ist sehr spezifisch, aber ich zeige es trotzdem mal, denn vielleicht kann es ja jemand brauchen oder ist am Source interessiert :)

Es tut genau eine Sache: Einen Unix Socket auf einem entfernten Rechner bereitstellen. Alle Unix Socket Verbindungen werden dabei durch eine TCP Verbindung zwischen beiden Rechnern getunnelt. Die TCP Verbindung kann in beide Richtungen aufgebaut werden. Wenn die Unix Client Instanz den TCP Server bereitstellt können mehrere andere Instanzen verbinden, so kann der Socket auch auf mehreren entfernten Systemen bereitgestellt werden. Wenn die TCP Verbindung in die entgegengesetzte Richtung läuft ist das natürlich nicht möglich.

Source:
Features:
  • Alle Unix Socket Verbindungen zwischen zwei Instanzen werden durch eine einzige TCP Verbindung getunnelt
  • Besitzer (User/Group) und Zugriffsrechte für einen Server Socket können an der Kommandozeile angegeben werden
  • Wenn es als Root gestartet wird, wechselt es zu dem angegebenen Socket-Besitzer (Privilegien werden gedroppt)
  • Inaktive TCP Verbindungen werden regelmäßig gepingt, und bei Nicht-Antwort geschlossen
  • Die TCP Client Instanz versucht immer wieder, abgebrochene TCP Verbindungen wieder aufzubauen
Portierbarkeit:
  • Sollte auf jedem modernen POSIX System laufen, getestet mit FreeBSD und Linux
  • Im Detail wird pselect() und die netdb-Funktionen getaddrinfo() und getnameinfo() gebraucht
  • Nicht kompatibel mit Windows, es werden einige POSIX Funktionen genutzt, die Windows nicht kennt, außerdem wird die Unix Semantik für lokale Sockets vorausgesetzt, z.B. dass man sie unlink()en kann
In einer "produktiven" Umgebung habe ich bisher nur mein Szenario intensiv getestet: Der Unix Socket Server ist dabei auch der TCP Server, mit genau einem TCP Client auf der Maschine mit dem "originalen" Unix Socket.

Die erste Version hat keinerlei Verschlüsselung oder Authentifizierung, weil ich das selbst nicht brauche, es läuft bei mir durch einen VPN Tunnel. Gibt es jemanden, der so ein Tool über ein öffentliches Netz brauchen könnte, also, würde es Sinn ergeben, TLS und Authentifizierung zu ergänzen?

Hintergrund:

Ich hatte ein Problem mit meinem Exim MTA, der SMTP Auth über Dovecot macht. Exim kann dazu nur zu einem lokalen (Unix) Socket verbinden. Leider akzeptiert der Dovecot Socket jedes Passwort, wenn Dovecot im Proxy-auth Modus läuft, ein wirklich böser Fallstrick :ugly:. Die Lösung ist also, dass Exim den Dovecot Socket meiner internen Installation nutzt.

Zunächst habe ich nach existierenden Möglichkeiten gesucht. Ssh Tunnelling hat es als "schneller workaround" getan. War mir aber definitiv zu komplex, das sauber und zuverlässig zu scripten. Die nächste Idee, netcat, konnte ich bald wieder verwerfen -- da hätte es an beiden Enden zwei Instanzen gebraucht, mit bidirektionaler Pipe dazwischen -- könnte man sicher mit zwei named pipes lösen, wird aber auch wieder sehr umständlich und fragil. Außerdem kann ein netcat listener nicht mit mehr als einem Client gleichzeitig umgehen.

Das war dann der Punkt, an dem ich begonnen habe, selbst was zu programmieren. Danach kam im ##bsdforen.de noch der Hinweis auf socat, und natürlich hat man mir von der Eigenimplementierung abgeraten ;). Socat ist ein sehr komplexes Tool, mein Anwendungsfall schien laut manpage immerhin so grob abgedeckt, allerdings unter der Voraussetzung, dass immer die Instanz das TCP Servers die des Unix Socket Clients sein musste. Außerdem war nicht direkt erkennbar, ob mehrere parallele Verbindungen sauber gehandlet werden. Ich habe erstmal an meinem Tool weitergebastelt, kann ja auch Spaß machen.

Rückblickend hat es 10 Tage (neben der regulären Arbeit natürlich) gedauert, bis "remusock" das, was ich brauche, zuverlässig getan hat. Da ich socat gar nicht getestet habe sind zwei Varianten möglich: Wenn socat mein Problem gelöst hätte, wäre das zu scripten vermutlich viel schneller gegangen. Wenn nicht hätte ich etwas Zeit geopfert, das herauszufinden. Nunja ;)

Ich habe dann noch grob weitere 10 Tage investiert, um nach möglichen "Edgecases" und Portierbarkeitsproblemen zu suchen und die so gut wie möglich zu behandeln. Das war definitiv für mich persönlich nicht mehr nötig, aber wie gesagt, Programmieren kann ja auch Spaß machen und man lernt was dazu :)
 
Zurück
Oben