Debian als Proxy/NAT

[aLeXL]

Hi Junx,

villeicht könnt ihr mir ein paar Tipps geben mit meinem kleinen Problem.

IST-Zustand:

Eine Anfrage auf dem Port z.b. 22.222 wird an meine DynDNS ip gesendet. Die Anfrage wird dann zu mir nach Hause weitergeleitet und bearbeitet. Wenn man jetzt allerdings einen Traceroute auf die dyndns adresse macht, lässt sich dadurch meine reale IP ermitteln.

Dies möchte ich verhindern.

Ich würde gerne auf einem Linux Server (Root oder V-Server) im Internet eine Anfrage auf einem bestimmten Port z.b. 22.222 entgegen nehmen. Diese Anfrage soll dann an mich zuhause weitergeleitet werden. Allerdings soll das als Art NAT geschehen. D.h. der Absender der Anfrage darf keine Möglichkeit haben, meine endgültige IP zu erkennen.

Was würdet ihr vorschlagen, einfach auf dem Debian System per iptables weiterleiten, oder irgendwelche besseren ideen wie man das realisieren könnte ?

[aLeXL]

Seit wann kann man denn hier seinen Beitrag nichtmehr editieren ??

Naja, selbst schuld am Doppelpost.

Ich könnte das einfach realisieren, wenn ich das IPv4 Forwarding aktiviere und dann z.b. folgenden eintrag setzte:

iptables -A PREROUTING -t nat -p tcp -d ip.vom.server --dport 22222 \ -j DNAT --to ip.von.daheim:22222

Das würde eigentlich für meine Bedürfnisse ok sein oder?

[albundy23]

squid : Optimising Web Delivery

[aLeXL]

squid : Optimising Web Delivery

Ziemlich sinnloser Beitrag, ich weiß was squid ist, was willst du mir sagen ? Wie soll der Link helfen ? Kannst du auch Sätze schreiben ?

[lordy]

Deine Lösung über IPtables wird wahrscheinlich nicht funktionieren.

Du bekommst zwar die Pakete rein, deine Antworten schickst du dann ja aber von deiner Heim-IP, mit der der Client aber nichts anfangen kann, weil er ja eigentlich zum Server verbunden hat. Es sei denn, du hast ein VPN zu deinem Server und NATtest eh über diesen.

Was du eigentlich brauchst, und darauf hat der Vorposter wohl angespielt, ist ein Tool, das die Verbindung auf dem Server annimmt und dann eine neue, separate Verbindung zu deiner Heim-IP öffnet. Ich würde so was z.B. mit tcpserver/tcpclient aus dem ucspi-tcp Paket machen, gibt aber sicherlich eine Menge andere Tools.

[flashpixx]

Man könnte auch einen SSL Tunnel aufbauen, der Server leitet die Anfrage, die er auf einem Port bekommt an den localen Port weiter, der dann auf den Heim PC geforwardet wird.

Eine entsprechende IPTable Regel braucht man nicht zwangsläufig und was an dieser Lösung aus meiner Sicht angenehmer ist, dass der Client, d.h. der Server zu Hause die Verbindung initiert, d.h. keine Konfiguration im heimischen Router usw. Weiterhin erhält ein User auch eine entsprechende Meldung, wenn eben kein SSH Tunnel, d.h. kleine Verbindung zum Dienst existiert (=> Connection refused).

Das ganze lässt sich auch wunderbar via Script steuern, so dass der Verbindungsaufbau automatisch zum Server statt findet.

Wobei ich natürlich etwas an die Datenmenge und die Latenzen denke, da der Server im Netz sicher eine höhere Bandbreite hat und die Verbindung somit über eine weitere nachfolgende Stelle abgewickelt werden muss.

[aLeXL]

hm, also ich hätte es am liebsten genau so, wie ein normaler Router das per NAT macht.

Paket kommt beim Router auf Port XY an, wird dann an eine definierte IP:Port gesendet. Dort wird es bearbeitet, wieder an den Router zurückgeschickt und der Router setzt dann wieder seine eigene IP und Port ein.

Das Paket wird anschließend an den Versender zurückgesandt.

Im Prinzip ganz normales NAT wie im Router, nur halt auf einem V-Server und übers Internet.

Auf meinem PC daheim ist debian, auf dem v-server dann auch, also man könnte theoretisch auch eine vpn verbindung zwischen den beiden herstellen. Müsste ja aber auch ohne gehen oder?

[flashpixx]

Auf meinem PC daheim ist debian, auf dem v-server dann auch, also man könnte theoretisch auch eine vpn verbindung zwischen den beiden herstellen. Müsste ja aber auch ohne gehen oder?

Wofür ein VPN? Ein VPN verbindet letztendlich einen Rechner mit einem Netzwerk oder zwei Netzwerke. Du willst im Grunde nur einen Dienst forwarden und dafür würde sich eben das Portforwarding eines SSH Servers anbieten.

Den Sinn verstehe ich zwar nicht, denn letztendlich kannst Du den Dienst auch direkt auf dem VServer laufen lassen. Aber ansonsten schließe ich mir lordy an, nur dass ich eben für einen einzelnen Dienst kein VPN oder NAT aufziehen würde, es ist in meinen Augen zu viel Aufwand.

[aLeXL]

jop flashpixx, desshalb meinte ich ja auch, dass ich eigentlich kein vpn brauche, außer es wäre damit leicht zu bewerkstelligen gewesen.

SSH Server läuft ja eh auf meinem Server, da könnte man dann also einfach das Port Forwarding eintragen?

Hättest du eventuell eine Adresse, wo ich die nötigen Unterlagen dazu finde?

Den Dienst kann ich leider nicht auf dem Vserver laufen lassen, da er auf lokale Geräte über USB zugreift.

[flashpixx]

Hättest du eventuell eine Adresse, wo ich die nötigen Unterlagen dazu finde?

"man ssh" sollte eigentlich alles notwendige liefern, wie man den Tunnel aufbaut. Natürlich muss es dem Benutzer erlaubt seinen, einen lokalen Port auf den Remoterechner zu forwarden. Steht aber alles in den Manpages

[aLeXL]

jo, hab ich inzwischen schon gemacht, hab den tunnel erstellt und es kam auch kein fehler, aber funktioniert anscheinend nicht :/

ssh -L 24000:localhost:22000 root@ip.von.daheim

Damit müsste der Server ja auf Port 24.000 Annehmen und an mich daheim auf port 22.000 weiterleiten oder hab ich da nen fehler drin ?

[flashpixx]

Du bindest den entfernten Port 22000 auf den lokalen 24000, da aber auf dem 25000 kein Dienst läuft, macht das keinen Sinn.

Du möchtest es aber genau umgekehrt, denn der lokale Port soll auf den entfernten gebunden werden, denn bei Dir läuft lokal der Dienst:

ssh -R <entfernter Rechner Port>:localhost:<lokaler Port>

Außerdem empfehle ich ganz dringend den root-Zugang zum Server zu deaktivieren und eine Public-Key Authentifizierung tz verwenden und auch solche Sachen nicht als Root durchzuführen. Das geht auch als normaler User, wenn man das entsprechend konfiguriert.

[aLeXL]

ok, verbindung steht, aber ich bekomme keine Connection.

Kann ich irgendwie überprüfen, ob was am server ankommt und was damit gemacht wird ?

// Hab den root Zugang nur zum Test drin, die zwei Computer stehn im Nebenzimmer ohne Internet.

Bearbeitet 18. September 2010 von aLeXL

[flashpixx]

Du bindest mit dem ssh Kommando lokal auf dem entfernten Rechner, d.h. Dein Dienst wird auf das local Interface gebunden

[Lalelu]

iptables -t nat -A POSTROUTING -o ethx -j MASQUERADE

wenn ich mich nicht irr müsste die Regel ausreichen..

[flashpixx]

@Lalelu: Iptables sind dafür nicht notwendig, das geht alleine mit dem SSH Dienst

[Mr Unix]

ssh -L 24000:localhost:22000 root@ip.von.daheim

SSH halte ich hier fuer unnoetig, da es einen ordentlichen Overhead erzeugt. Fuer permanente Loesungen wuerde ich eher zu IPSEC oder OpenVPN greifen.

Wenn du auf dem Rootserver noch eine freie IP hast, kannst du dir einfach mit OpenVPN diese IP "zuweisen". Blockste halt alle Ports auf dem entsprechenden Device und leitest deinen Port mit iptables auf den gewuenschten Port um.

[dano0b]

tcptunnel

mehr wirst du nicht brauchen, alle anderen lösungen erzeugen eine verschlüsselte verbindung was natürlich grundsätzlich besser ist

[aLeXL]

Hoi, danke für eure Hilfe, hat mich in die richtige Richtung gebracht.

Hier meine Lösung:

Die DynDNS IP leitet jetzt nicht mehr zu mir nach Hause weiter, sondern auf einen OpenVPN Server im Ausland. Dort wird die IP meinem Acc / meiner Verbindung zugeordnet.

Sobald ich mich von meinem PC im Nebenzimmer per linux openvpn zum server verbinde, werden die Pakete an meinen PC daheim weitergeleitet.

Die Pakete werden dann bearbeitet und wieder über den VPN Server im Ausland zurückgeschickt.

Der Traceroute geht jetzt nur bis zum vpn server und nicht mehr bis zu mir nach Hause. D.h. meine IP lässt sich jetzt nur noch mittels erheblichem Aufwand ermitteln und zusätzlich ist die Verbindung von mir bis ins Ausland verschlüsselt, d.h. in Deutschland kann niemand die Daten abhören. genau das was ich wollte

PS: Fragt nicht, für was ich das brauche