Socket Server über SSH

[chessboi]

Naja, ein übliches VPN hat dann schon noch ein paar Vorteile gegenüber dem SSH-Tunneling:

- Man will nicht gerade dem VPN-Client root-Rechte am Server geben
- VPN wie IPSec kennen noch andere Authentifizierungsmethoden als nur gerade Preshared-Keys oder User-Passwort
- VPN wie IPsec können zwischen verschiedenen Verschlüsselungsalgorithmen gewählt werden, und es lässt sich fein einstellen was Verschlüsselt werden soll (z.B. nur die Nutzlast)

Dafür ist SSH relativ einfach und für die Standardbedürfnisse wohl bei weitem sicher genug.

[oreissig]

kann man darüber auch dhcp fahren um die routen und IPs einzustellen?

[bobe]

das ist ja genial, danke

[chessboi]

oreissig schrieb:  kann man darüber auch dhcp fahren um die routen und IPs einzustellen?

Naja ... dann müsste der SSH-Server ja auch der DHCP-Server sein, da dieser sonst ausserhalb der Broadcastdomäne ist (ausser du richtest dir einen Releay-Agent ein), zudem weiss ich nicht ob man mit DHCP ein Interface auch auf eine Point-to-Point Verbindung einrichten lässt (wie es hier gemacht wird, falls dies denn überhaut zwanghaft so notwendig ist) - das mal grundsätzlich zu DHCP.

Allerdings seh ich nicht genau ein, für was du DHCP nutzen willst. Um die SSH Verbindung herstellen zu können, musst du bereits in einem Netz sein (lokles Netz, oder gar Internet) - diese Verbindung kannst du selbstverständlich mit DHCP einrichten lassen. Die Verbindung des virtuellen Interfaces tun0, welches du mit dem SSH-Tunnel einrichtest, kann ein autonomes Netz sein. (z.B. auch ein Klasse A Netz, wenn du dich sonst in einem C Netz befindest.) Wenn du nun den SSH-Server nicht als Default-Route verwenden willst, kannst du allenfalls noch per Script beim Server die Routingtabelle auslesen und die Netze bei dir einrichten, mit dem Server als Ziel.

[pETe!]

Hi, sehr nettes Howto.
Was noch schön wäre, wäre eine Erklärung der einzelnen Befehle und Parameter und warum man sie benutzt.
Das sorgt dafür, dass man im Anwendungsfall nicht nur copierpaste aus dem Forum macht, sondern auch noch nebenbei das ganze anzuwenden lernt
Vor allem fühlt man sich gleich sicherer, etwas einzutippen, von dem man auch schon vorher die Auswirkungen kennt...


Was macht son Socket technisch? Alles was ich da rein schmeiße kommt an der Gegenseite wieder 1:1 heraus? (Wikipedia ist leider gerade down)

[gandro]

Welchen Beitrag meinst du jetzt?

Im Eröffnungsbeitrag steht ja alles erklärt, zum neuen Beitrag unten schau dir mal folgende Links an:

Die SSH-Zeile:
https://help.ubuntu.com/community/SSH_VP...%20command

NAT:
NAT mit Linux und iptables - Tutorial (Einführung)

Einzig die Sache mit dem pointopoint habe ich noch nicht ganz verstanden, die Manpage von ifconfig sagt da leider auch nicht gewaltig viel mehr.

Ein Socket ist abstrakt gesprochen, ein Paar aus IP-Adresse und Port, welches du als Programm deinem Betriebsystem übergibst: Dieses leitet dann alle einzelnen Pakete von diesem Socket zu dir und jedes Paket zu diesem Socket an die entsprechende IP-Adresse mit dessen Port.

Bei einem SOCKS-Server redest du dabei mit nicht deinem Betriebsystem, sondern mit dem SOCKS-Server, dieser leitet dann die Pakete weiter (in diesem Falle über eine verschlüsselte SSH-Verbindung) und übergibt erst am anderen (sicheren Ende) des Tunnels das Socket einem Betriebsystem.

Der Nachteil ist, dass Programme SOCKS unterstützten müssen, sonst reden sie weiter mit dem Betriebsystem. Man kann dies bei dynamisch gelinkten Programmen z.T. mit umleiten der entsprechenden Funktionen lösen, geht aber nicht überall und mit allem, daher empfiehlt sich eine VPN-artige Lösung, wo man nicht Sockets, sondern einzelne Pakete tunnelt.

[chessboi]

Grob hab ich es ja schon eklärt, detailierter ist es in den Links, aber ich kann es auch hier etwas genauer erklären, mit meinen eigenen Worten:

SSH ist ein Protokoll zum Remotelogin an einem anderen Rechner, vergleichbar mit RemoteShell (RSH) oder Telnet, allerdings mit einer Verschlüsselung der übertragenen Daten. Allerdings kann man über dieses Protokoll auch einfach einen Befehl ausführen am anderen Rechner oder Daten kopieren (mit SCP) oder was für uns interessanter ist einen Socket oder einen Tunnel aufbauen.
ssh -NTCf -w 0:0 root@server
Zu den Parametern: N sagt das ich am gegenüber keinen Befehl ausführen will, also auch keine Shell gestartet werden soll, T sagt dass ich auch kein virtuelles tty haben will C komprimiert die übertragenen Daten und f schickt das ganze in den Hintergrund. -w ist der eigentliche Paramter für einen Tunnel, gefolgt von lokalemInterface:serverInterface. 0:0 erstellt mir somit auf beiden seiten ein tun0 Device. Dafür muss im übrigen das Kernelmodul tun geladen sein. (modprobe tun)

Das Netzwerkinterface tun0, welches wir mit der SSH-Verbindung erhalten ist ein logisches Interface, welches wir benutzen können um in die am Server angeschlossene Netzwerke zu benutzen. Sprich wir haben ein VPN - Virtual Private Network - ich kann von meinem Rechner (oder meinem Netzwerk) eine Verschlüsselte Verbindung in ein anderes Netzwerk (über den SSH-Server) aufbauen, ohne dass jemand im (unsicheren) Netzwerk (Internet) dazwischen die Verbindung abhören könnte. Dieses Netzwerkinterface muss aber noch konfiguriert werden, dass macht man mit ifconfig. (Vergleichbar mit dem Befehl ipconfig unter Windows, allerdings kann man damit die Werte nicht nur auslesen, sondern auch setzen.)
ifconfig tun0 192.168.2.90 pointopoint 192.168.2.80
Setzt die ip-Adresse des tun0 auf 192.168.2.90. Als Adressraum nimmt man am besten etwas völlig anderes als bei den übrigen Interfaces (an denen man am unsicheren Netzwerk angeschlossen ist) um verwechslungen zu vermeiden.
Auf dem Server das Selbe:
ifconfig tun0 192.168.2.80 pointopoint 192.168.2.90
Pointopoint heisst im übrigen, dass wir hier eine direkte Verbindung zwischen den beiden Interfaces haben. Damit gibt es auch keine Unterstützung für Broadcasts oder ARP, da dies einfach nur unnützer Overhead wäre. Natürlich funktioniert das ganze auch wenn man das Interface wie gewohnt mit mit ifconfig tun0 192.168.2.80 netmask 255.255.255.0 konfigurieren würde - es wäre aber einfach Blödsinn.

Nun steht zwar die Verbindung, und Server sowie Client können sich gegenseitig anpingen, doch weiss ich noch nichts über die Netwerke welche sich hinter dem Server verbergen. Daher adde ich den Server einfach als Standardgateway.
route add default gw 192.168.2.80 netmask 0.0.0.0
Natürlich könnte man mit dem route Befehl auch einfach nur bestimmte Netzwerke oder einzelne Hosts auf den Server umleiten. Wenn man den Server als Standardgateway definiert wird einfach der gesammte Netzwerkverkehr (wie etwa der Zugriff auf das Internet) über den Server umgeleitet. Ausser die Routen welche sonst definiert sind (und wenn man keine manuell definiert hat, sind das nur jene welche direkt mit dem Client verbunden sind).

Nun leite ich also den ganzen Netzwerkverkehr auf den Server um. Doch dieser verwirft die Pakete welche er erhält einfach! Denn er weiss nicht was er mit ihnen anfangen soll. Nun gibt es unter Linux eine Datei welche aussagt ob ein Host Traffic weiterleiten darf oder nicht. Damit der Server den Traffic weiterleitet muss in dieser Datei eine 1 ("Eins" für true) stehen:
echo "1" > /proc/sys/net/ipv4/ip_forward

Wenn ich nun etwa den Browser öffne und auf Google zugreiffe, wird die HTTP-Anfrage über den Server umgeleitet (verschlüsselt durch den Tunnel) und der schickt sie weiter an Google. Doch bei Google steht in der Absenderadresse der IP-Datagramme die Adresse des SSH-Servers. Der Google Webserver schickt mir also alles an den SSH-Server zurück, und der verwirft die Pakete, da er ja nie einen HTTP-Request gemacht hat.
Damit nun die Pakete auch wieder den korrekten Weg zurück finden, muss ein sogenantes Source-NAT gemacht werden. Die Pakete von meinem Client bekommen dann offiziell als Absenderadresse die des Servers über. Die Sequenznummer des IP-Datagramms wird auf dem SSH-Server (der nun auch als NAT-Server fungiert) in einer Tabelle eingetragen. Dank dieser weiss er, wenn Pakete retour kommen, von welchem Client sie stammen (evtl brauchen ja auch mehrere Clients den Server als Gateway).
Dieses NAT lässt sich ganz einfach mit einer Firewall-Regel über iptabels einrichten. (iptables ist eine extrem schnelle im Linux-Kernel integrierte Firewall).
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Alle Pakete welche durch das Interface wlan0 heraugeroutet werden werden somit nach dem Routen entsprechend maskiert und in die NAT-Tabelle eingetragen.

Wer sich noch etwas genauer dafür interessiert wie das denn genau mit den Paketen abläuft, soll sich doch das ganze mal aufbauen und den Netzwerkverkehr sniffen (etwa mit Wireshark).

[ggeretsae]

gibts dafür eigentlich auch ne methode mit putty für windows, oder kann man das über cygwin erreichen?

[chessboi]

ggeretsae schrieb:  gibts dafür eigentlich auch ne methode mit putty für windows, oder kann man das über cygwin erreichen?

Einen Socket kriegst du mit Putty hin, gibt auch gute Anleitungen im Internet. (Unter anderem auf Youtube.) Einen Tunnel mit einem nutzbaren Interface bezweifle ich, da dass ganze recht betriebssystemnah ist. (Unter Linux brauchst du ein entsprechendes Kernelmodul.)

[Alpha]

ggeretsae schrieb:  gibts dafür eigentlich auch ne methode mit putty für windows, oder kann man das über cygwin erreichen?

Ich hab das ganze hier nur überflogen... aber ist das hier nicht im Prinzip nen SOCKS5 Proxy via SSH? Das kann man ja mit Putty machen...