OpenVPN Tunnel

lordfritte

Lieutenant
Registriert
Juli 2006
Beiträge
1.009
Hallo ich habe mir einen günstigen vServer mit ipv4 und ipv6 gemietet und möchte darüber einen OpenVPN ipv4 -> ipv6 Tunnel auf meinen Home-Server herstellen.

Ich habe folgende Konfiguration: Den vServer mit einer festen ipv4 und einer festen ipv6 und meinen Homeserver mit einer ipv6, die ipv4 bringt mir nichts, wegen DS-Lite.
Auf dem vServer wird ein OpenVPN Server laufen und mein Home-Server stellt eine Verbindung darauf her.

Ich möchte, dass Anfragen über ipv4 auf den vServer über das OpenVPN auf meinen Homeserver getunnelt werden.

Aber wenn ich jetzt die ipv4 über die ipv6 auf meinen Home-Server Tunnel habe ich doch auf den vServer selber keinen Zugriff mehr?
Lässt sich das so lösen, dass ich je nach Domain über die die Anfrage kommt getunnelt wird oder nicht?
 
Was ist deine Intention dabei?

Also du müsstest doch von deinem Home Server über das VPN per SSH oder per RDP noch auf den vServer zugreifen können.
Was für OS laufen auf den Servern?
 
Port Forwarding auf dem vServer (IPv4) zum homeserver (IPv6): http://ef.gy/forwarding-ipv4-to-ipv6
Edit: Alternativ ginge auch ein Reverse-Proxy (nginx) wenn es sich nur um spezielle Dienste handelt...
 
Zuletzt bearbeitet:
MaC-87 schrieb:
Was ist deine Intention dabei?

Also du müsstest doch von deinem Home Server über das VPN per SSH oder per RDP noch auf den vServer zugreifen können.
Was für OS laufen auf den Servern?
Also das Problem ist: Dank DS-Lite erreiche ich meinen Home-Server von außen nicht mehr. Daher möchte ich sowas bauen.
Auf meinem Home-Server läuft ubuntu server 12.10 64-Bit

HighTech-Freak schrieb:
Port Forwarding auf dem vServer (IPv4) zum homeserver (IPv6): http://ef.gy/forwarding-ipv4-to-ipv6
Edit: Alternativ ginge auch ein Reverse-Proxy (nginx) wenn es sich nur um spezielle Dienste handelt...
Stimmt ein reverse-Proxy wäre auch eine Möglichkeit, daran habe ich noch gar nicht gedacht.
Ein Reverse-Proxy kann alle Dienste durchleiten, anhand des Portes oder?
 
lordfritte schrieb:
Stimmt ein reverse-Proxy wäre auch eine Möglichkeit, daran habe ich noch gar nicht gedacht.
Ein Reverse-Proxy kann alle Dienste durchleiten, anhand des Portes oder?
Für Port-basiertes Weiterleiten musst Du das Pseudo-Portfowarding benutzen, dass ich verlinkt habe.
Reverse-Proxy kann zB HTTP, SMTP, IMAP, POP3 und dergleichen durchleiten... Das bietet einen zusätzlichen Schutz und ist einfacher zu troubleshooten, wenn mal was nicht funktioniert.
 
HighTech-Freak schrieb:
Für Port-basiertes Weiterleiten musst Du das Pseudo-Portfowarding benutzen, dass ich verlinkt habe.
Reverse-Proxy kann zB HTTP, SMTP, IMAP, POP3 und dergleichen durchleiten... Das bietet einen zusätzlichen Schutz und ist einfacher zu troubleshooten, wenn mal was nicht funktioniert.

Gut Danke! Ich denke, das ist eine Bessere Lösung als OpenVPN, das wäre nämlich die nächste Frage gewesen: Firewall, ich möchte nur die Dienste tunneln, welche ich auch brauche. Aber das hat sich mit einem rverse-Proxy ja wohl erledigt.

Aber so wie ich gerade gesehen habe funktioniert ein Reverse-Proxy auch auf subdomain Basis? Zumindestens war es bei Apache so.
Sprich ich könnte realisieren, dass bei vserver.mydomain.de port 22 ssh auf meinem vServer landen und server.mydomain.de port 22 auf meinem Home-Server

Aber eine Frage habe ich noch zum Reverse-Proxy: Wie schaut es mit der Performance aus? Belastet das nicht den Server stark?
 
Ich würde vorschlagen, Du setzt auf dem Ding einen normalen HTTP-Proxy auf (Squid). Damit können die meisten Clients umgehen (SSH-Clients, FTP-Clients, HTTP-Clients) die Du zur Administration benötigst. Den Proxy lässt Du irgendwo auf einem Highport laufen um Portscans zu entgehen.

Für Serverdienste, die von außen erreichbar sein sollen, benutz entweder einen Reverse-Proxy (nginx ist vermutlich die beste Wahl für HTTP - das geht auch mit subdomain, zumindest solange kein SSL benötigt wird, da der SSL-Handshake ganz zu beginn stattfindet) oder eben Port-Forwarding. Speziell für FTP-Dienste ist Port-Forwarding auf Grund PASV die bessere Wahl. Propreitäre Services wie Video-Streaming-Server funktionieren oft auch nur per Port-Forwarding -zumindest solange diese nicht irgendwie auf HTTP beruhen (was zugegebenermaßen häufig der Fall ist).

D.h.:
SSH (und andere private Dienste):
benutzt Proxy (vserver.deinedomain.de:32180 [IPv4] autorisiert per username/passwort) um sich schließlich mit
  • server.deinedomain.de:22 [IPv6] oder
  • vserver.deinedomain.de:22 [lokales IPv4 oder IPv6]
zu verbinden
Dieser Proxy erlaubt es Dir außerdem generell von IPv4 aus auf IPv6-Hosts zugreifen zu könne, ist also ein gutes "Schweizermesser" für Dein Netzwerk...
Public HTTP:
  • vserver.deinedomain.de:80 [IPv4] verbindet via Reverse-Proxy (nginx) zum lokalen (zB) Apache Server
  • server.deinedomain.de:80 [IPv4] verbindet via Reverse-Proxy (nginx) zu deinem homeserver [IPv6]
(Du kannst nur eine subdomain for Port 443 einrichten! D.h. vserver.deinedomain.de:443 = server.deinedomain.de:443)
Man könnte das zwar auch per socat machen, aber dann würdest Du keine subdomains anlegen können. Außerdem ist nginx ein gutes Schutzschild und erlaubt diverse Spielereien. Mit dem Ding kann man viel anstellen und das ohne aufgeblasene Config-Files wie bei Apache...
Public FTP:
benutzt Port-Forwarding per socat.
  • alles was an vserver.deinedomain.de:21 [nomales FTP, IPv4] ankommt wird an deinen homeserver [IPv6] weitergeleitet
  • alles was an vserver.deinedomain.de:990 [implicit SSL FTP, IPv4] ankommt wird an deinen homeserver [IPv6] weitergeleitet
  • alles was an vserver.deinedomain.de:23400-23500 [PASV, IPv4] ankommt wird an deinen homeserver [IPv6] weitergeleitet
Port-Forwarding spricht für sich selbst. 1:1 Portweiterleitung zum Ziel für Protokolle, die nicht via Reverse-Proxy machbar sind...
 
Zuletzt bearbeitet:
Ich befürchte ich habe etwas wichtiges außer acht gelassen. Mein vServer hat eine feste IP, mein Home-Server aber nicht..
Ich denke, das wird noch ein Problem darstellen.
 
ich habe auch einen vserver mit fester IP-Adresse. Mit meinem Server zu Hause baue ich einen OpenVPN Tunnel zum vserver damit der Home Server eine eindeutige IP hat.
Ich hab das SSH Problem so gelöst. Ich hab eine IP-Tables Rule gebaut, die mir den Port 222 auf localhost:22 NATed. Wenn ich mich jetzt auf den vserver mit SSH auf Port 222 connecte, komme ich am vserver raus. Alles andere wird zu meinem Home Server über den Tunnel geroutet.

Gruß
Manuel
 
menzm schrieb:
ich habe auch einen vserver mit fester IP-Adresse. Mit meinem Server zu Hause baue ich einen OpenVPN Tunnel zum vserver damit der Home Server eine eindeutige IP hat.
Ich hab das SSH Problem so gelöst. Ich hab eine IP-Tables Rule gebaut, die mir den Port 222 auf localhost:22 NATed. Wenn ich mich jetzt auf den vserver mit SSH auf Port 222 connecte, komme ich am vserver raus. Alles andere wird zu meinem Home Server über den Tunnel geroutet.

Gruß
Manuel

Und wie genau hast du das gemacht?
Gibt es da irgendeine Anleitung zu?
 
Nein, eine Anleitung gibt es dazu nicht.

Ich habe einen OpenVPN Tunnel zu meinem Server. Dort habe ich vier IPTabels Rules eingetragen:

iptables -t nat -A PREROUTING -d <öffentliche IP des vservers> -i <Incoming Interface des vservers> -p udp -m udp --dport 1199 -j DNAT --to-destination <IP des vservers>:1199
iptables -t nat -A PREROUTING -d <öffentliche IP des vservers> -i <Incoming Interface des vservers> -p tcp -m tcp --dport 222 -j DNAT --to-destination <IP des vservers>:22
iptables -t nat -A PREROUTING -d <öffentliche IP des vservers> -i <Incoming Interface des vservers> -j DNAT --to-destination <IP des privaten Server>
iptables -t nat -A POSTROUTING -s <IP des privaten Servers> -o <Outgoing Interface des vservers> -j SNAT --to-source <öffentliche IP des vservers>

In den ersten beiden Zeilen legst du das forwarding für die lokalen Dienste des vservers fest. Bei mir ist das OpenVPN auf UDP 1199 und SSH mit PortNAT auf 222 -> 22.
Die letzten beiden Zeilen machen das NATing für den privaten Server. Hier wird einfach die öffentliche IP Adresse des vservers in die private IP deines Homeservers geNATed. Das, in meinem Fall, in beide Richtungen (Source und Destination).

Ich kann dir am Montag Abend auch gerne mit einer TeamViewer Session helfen das ganze einzurichten.

Gruß
Manuel
 
Zuletzt bearbeitet:
Zurück
Oben