openVPN und Internet gleichzeitig

[ronjaraeubertochter]

Hallo Community,

ich habe bei mir einen Debian Server, der eine normale Internetverbindung über meinen Speedport aufbaut. Auf dem Server rennen paar Dienste, für die ich Ports im Router freigegeben/weitergeleitet habe.
Soweit so gut.

Nun habe ich eine VPN-Verbindung mit openVPN eingerichtet. Jetzt ist es so, dass sobald die VPN-Verbindung steht, der Server nicht mehr über meine öffentliche Telekom-IP erreichbar ist. Will ich auf mein Server zugreifen, muss das entweder innerhalb des internen Netzes (192.168...) ODER über die Adresse des VPNs geschehen.
Ich hätte aber gern beides: Erreichbarkeit über meine öffentliche Telekom-IP und über das VPN-Netzwerk.

Wie realisier ich das?
Schonmal vielen Dank im Voraus.

MfG
RRT

[orcape]

Hi,
ich weiß ja nicht wie Deine OpenVPN-config des Servers aussieht ?
Die Funktion "Force all client generated traffic through the tunnel. " sollte deaktiviert sein.
Dann klappt´s auch mit dem Internet wenn der Tunnel aktiv ist.
Gruß orcape

[ronjaraeubertochter]

Meine Config sieht so hier aus:

Code: Alles auswählen

client
dev tun
auth-user-pass
proto udp
remote IP_ADRESSE PORT
resolv-retry infinite
nobind
auth-user-pass /pfad/zur/login/datei
persist-key
persist-tun
comp-lzo
ca ZERTIFIKAT.crt
verb 3

Das, was du da geschrieben hast, müsste wohl auch direkt mit in die ovpn.conf?

MfG
RRT

[Cae]

Ich denke mal, da ist die Standardroute falsch und die Antwortpakete z.B. vom SSHd gehen ueber's VPN raus, anstatt lokal. Poste

Code: Alles auswählen

# ip route

-- da sollte das deutlich werden. Die Loesung dazu waere, zumindest dem lokalen Gateway (Plastikrouter) eine statische Route ueber das physikalische Interface zu verpassen.

Willkommen im Forum!

Gruss Cae

[ronjaraeubertochter]

Hallo,

sollte dazu die openVPN-Verbindung hergestellt sein, damit die Ausgabe von ip route was bringt? Weil ohne VPN, so wie der Server momentan läuft, bringt es mir folgende Ausgabe:

Code: Alles auswählen

root@Server:/home/rrt# ip route
default via 192.168.2.1 dev eth0  proto static
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.108
root@Server:/home/rrt#

192.168.2.1 ist mein Router und die 108 der Server.

Gerne kann ich den VPN auch noch mal anmachen und erneuer ip route eingeben.

Schon mal Danke soweit.

[Cae]

sollte dazu die openVPN-Verbindung hergestellt sein, damit die Ausgabe von ip route was bringt?

Richtig vermutet, denn die Erreichbarkeit ueber den Plastikrouter (mit der oeffentlichen IP) bricht ja weg, sobald du das VPN einschaltest.

Prognose: Die Standardroute (default via...) zeigt nicht mehr auf 192.168.2.1, sondern auf die Gegenstelle im VPN. Probier' dann man

Code: Alles auswählen

# ip route add 192.168.2.1/32 dev eth0

... aber nee, das sollte eigentlich nix aendern. Die Pakete kommen ja nicht-ge(source)NATtet bei der Kiste an und haben eine Internet-Adresse als Absender drin stehen (meine Fehlannahme oben war, dass die Quell-IP die des Routers sei). Ich vermute mal, man muss da iptables nehmen und per connection tracking (-m conntrack) dafuer sorgen, dass Verbindungen jeweils auf dem Interface weitergefuehrt werden, wo sie initiiert wurden.

Gruss Cae

[orcape]

Meine Config sieht so hier aus:

...hier hast Du die Client.conf gepostet.
Die Server.conf wäre noch interessant, sowie die Ausgabe von "route" auf Server und Client, wenn der Tunnel läuft.
Wenn ein remotes Netz im Spiel ist, sollte auch eine Client-Config-Directory (ccd) mit entsprechenden Routing-Einträgen notwendig werden.
Du hast hier sicher eine Fehlconfiguration im OpenVPN-Server vorliegen.
Ich weiß nicht ob der Kernel noch zum Routing überredet werden muss, wenn OpenVPN auf dem Server läuft.
OpenVPN habe ich bei mir alles auf einem ALIX-Board mit pfSense als Firewall laufen.
Schau mal in die "/proc/sys/net/ipv4/ip_forward und mach aus der 0 eine 1, dann sollte zumindest die Routing-Funktion im Kernel eingeschaltet sein.
Ob das aber die Ursache ist....?
Gruß orcape

[Cae]

Schau mal in die "/proc/sys/net/ipv4/ip_forward und mach aus der 0 eine 1, dann sollte zumindest die Routing-Funktion im Kernel eingeschaltet sein.
Ob das aber die Ursache ist....?

Auf dem Client? Nein, der soll sehr wahrscheinlich nicht routen.

Gruss Cae

[orcape]

Auf dem Client?

@ Cae
Ich hatte eigentlich den Server gemeint.
Wie ich den TE verstanden habe, hat er den OpenVPN-Server auf dem Debian-Server eingerichtet.
Leider hat er das nicht so genau definiert, nur die Tatsache das so eine Speedportbüchse gar nicht in der Lage ist
eine OpenVPN-Tunnel zu machen, bringt mich zum Debian-Server.
Gruß orcape

[ronjaraeubertochter]

Sorry, war etwas im Stress, deswegen die späte Antwort.
Nochmal zum Verständnis: Ich habe einen Debian-Server bei mir zu Hause stehen, der ganz normal an einem Speedport hängt und ins Internet darf. Auf dem Server läuft auch ein Dienst, der über einen Port nach außen kommuniziert. Dazu habe ich im Speedport auch ein Portforwarding eingerichtet. (Handelt sich dabei im TeamSpeak, wär es genau wissen möchte).

Nun habe ich zusätzlich noch openVPN installiert und baue damit (als Client) eine Verbindung zu einem VPN-Netzwerk auf. Diese Verbindung soll für andere Zwecke genutzt werden. Sobald nun diese VPN-Verbindung steht, bin ich nicht mehr über meine Telekom-IP erreichbar. Das soll sich ändern

@orcape
Leider kann ich mit der Server-Config von openVPN leider nicht dienen, da ich in diesem "Netzwerk" tatsächlich auch nur Client bin und ich den Server(betreiber) auch nicht kenne. Es handelt sich ja dabei um einen Dienstanbieter für VPNs.

@Cae
Hier nun einmal die ip route bei hergesteller VPN-Verbindung:

Code: Alles auswählen

root@Server:/home/rrt# ip route
0.0.0.0/1 via 10.208.88.5 dev tun0
default via 192.168.2.1 dev eth0  proto static
10.208.88.1 via 10.208.88.5 dev tun0
10.208.88.5 dev tun0  proto kernel  scope link  src 10.208.88.6
128.0.0.0/1 via 10.208.88.5 dev tun0
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.108
212.7.208.86 via 192.168.2.1 dev eth0
root@Server:/home/rrt# 

Zur Erklärung: 192.168.2.1 ist mein Telekom-Router, die 212.7.208.86 ist die IP, die ich aus meinem VPN-Netzwerk erhalte.
Über diese IP (nur diese!) bin ich auch aus dem Internet erreichbar. Allerdings will ich auch über meine "öffentliche" Telekom-IP erreichbar sein. Diese Erreichbarkeit funktioniert auch, solange der VPN nicht läuft.

Am Ende des Tages will ich einfach nur über 212.7.208.86 (VPN-IP) und 91.21.2xx.xxx (Telekom-IP) gleichzeitig erreichbar sein. Nicht entweder/oder

MfG
RRT

Ergänzung:
Bei Windows wird dies (scheinbar) so gelöst:
Haken bei "Standartgateway für das Remotenetzwerk verwenden" in den VPN-Eigenschaften entfernen.

[orcape]

So wie ich das sehe, müsste in Deinem Fall Dein Server zwischen Tunnel und Internet routen und das tut er wohl nicht.
Kann sein das in der Server.conf die Funktion.."Force all client generated traffic through the tunnel. " aktiviert ist, was Du aber nicht beeinflussen kannst.
Das wirst Du zu aller erst abklären müssen, ob dem so ist. In dem Fall würde es nicht mal helfen wenn der VPN-Client auf dem Router läuft.
Vielleicht ist das ja auch so von Tunnel-Provider beabsichtigt, dann hast Du mit dem Tunnel quasi eine statische IP erhalten und nur darüber kommst Du ins Internet, bzw. vom Internet in Dein LAN.
Gruß orcape

[ronjaraeubertochter]

Würde in dem Fall eine 2. Netzwerkkarte was bringen? Also ich würde noch eine einbauen und auch diese mit dem Router verbinden und ob sich dann openVPN irgendwie nur auf die eine Netzwekkarte legen lässt, sodass die Erreichbarkeit über die Telekom-IP über die 2. Netzwerkkarte realisiert wird?!

[DynaBlaster]

Code: Alles auswählen

root@Server:/home/rrt# ip route
    0.0.0.0/1 via 10.208.88.5 dev tun0
    default via 192.168.2.1 dev eth0  proto static
    10.208.88.1 via 10.208.88.5 dev tun0
    10.208.88.5 dev tun0  proto kernel  scope link  src 10.208.88.6
    128.0.0.0/1 via 10.208.88.5 dev tun0
    192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.108
    212.7.208.86 via 192.168.2.1 dev eth0
    root@Server:/home/rrt#

Die erste Zeile ist Schuld. Vermutlich ist tasächlich serverseitig irgendetwas in der Richtung redirect-gateway konfiguriert und nach dem OpenVPN-Verbindungsaufbau wird eben der gesamte Traffic durch das VPN geroutet. Soweit ich das sehe, müsste es eigentlich reichen, den ersten Routing-Eintrag manuell zu löschen. Anschließend sollte eigentlich das VPN trotzdem bestehen bleiben und gleichzeitig der "normale" Internettraffic wiedr über den Speedport rausgehen (Zeile 2).

Sollte in etwa so gehen:

Code: Alles auswählen

ip route del 0.0.0.0/1 via 10.208.88.5 dev tun0 

Probleme macht dann aber vermutlich die fehlende Route in die Netze hinter dem Router 10.208.88.1. Wenn du da andere Rechner ausser dem OpenVPN-Server selbst erreichen musst, dann müsstest du das Netz bzw. die Netze inkl. Netzmasken erraten, um diese Routen irgendwie ebenfalls manuell nachzuschieben.

[ronjaraeubertochter]

Hey DynaBlaster,

vielen Dank für Deine Antwort. Ich werde es gleich morgen früh mal aufprobieren.

[...] Wenn du da andere Rechner ausser dem OpenVPN-Server selbst erreichen musst, dann müsstest du das Netz bzw. die Netze inkl. Netzmasken erraten, um diese Routen irgendwie ebenfalls manuell nachzuschieben.

Zum Glück nicht

[DynaBlaster]

Ggf. auch den 5. Routing-Eintrag kicken. Der deckt auch ein Riesen-Netz ab....

[ronjaraeubertochter]

Wenn ich diese Route lösche...

Code: Alles auswählen

0.0.0.0/1 via 10.208.88.5 dev tun0

...dann wird der Server wieder über meine Telekom-IP erreichbar. Allerdings wieder nur über meine Telekom-IP und nicht zusätzlich die vom VPN
Außerdem wird die Route wieder neugesetzt sobald ich den openVPN-Dienst neustarte.

Gibt es nicht irgendwie eine Möglichkeit 2 Netzwerkkarten zu nutzen, beide mit dem Internet (Router) zu verbinden und dann openVPN nur eine Netzwerkkarte verwenden zu lassen?

[Cae]

Allerdings wieder nur über meine Telekom-IP und nicht zusätzlich die vom VPN

Doch, aber die Antwortpakete auf Anfragen aus dem VPN werden wieder ueber die Telekom anstatt den Tunnel geroutet und werden vom Ziel deshalb nicht als Anworten erkannt.

Die Idee mit der zweiten Netzwerkkarte bringt keinen Vorteil; du hast ja momentan schon zwei Interfaces: Das physikalische und das tun oder tap vom Tunnel.

Gruss Cae

[ronjaraeubertochter]

D.h. die notwendigen Einstellungen müssten am Server getätigt werden und ich habe soweit von mir aus keine Chance?

MfG
RRT