vServer von extern nicht erreichbar nach Verb. mit VPN-Server

[eXTA]

Moin!

Also mein ursprüngliches Ziel ist es, den vServer sowohl als VPN-Server als auch als VPN-Client zu betreiben.
Der VPN-Server läuft auch soweit ohne Probleme.

Wenn ich nun den Client auf dem (Ubuntu)-vServer starte, um mich mit dem 2. VPN-Server zu verbinden, flieg ich aus der SSH Sitzung und Ping geht auch nicht mehr auf die öffentl. IP.
Zuerst dachte ich, dass die Clientconfig irgendwie fehlerhaft war bzw sich mit dem VPN-Server beißt, aber wenn ich über die Konsole des Dashboards raufschaue, sehe ich, dass die Verbindung mit dem VPN-Server hergestellt wurde:

Nach Beenden des Clients, lief Ping wieder.

Nun die (Verständnis-)Frage: ist es überhaupt noch möglich, von extern zuzugreifen, wenn der gesamte Traffic des vServers über den 2. VPN-Server läuft? Oder muss ein weiteres (virtuelles) Interface konfiguriert werden?
Der vServer hat nur einen eth0 (und noch lo und tun0).

Über Anregungen/Denkanstöße wäre ich dankbar

 

[NiclasM]

Ersteinmal, nein. Denn du schickst Anfragen an deinen VPS. Sagen wir mal, du bist Person A, der VPS Person B und der zweite VPn Person C.

Kommunizierst du ohne VPN auf dem VPS zw. A und B geht alles normal. B sieht dass A Anfragt und A sieht dass B antwortet.

Ist der VPS über das VPN verbunden, schickst du von A an B eine Anfrage. B Antwortet aber nicht, sondern C. Da B als Standard Gateway C eingetragen hat. Also bekommt A von C die Antwort die er von B erwartet hat. Da A an C keine Anfrage gestellt hat, schmeißt er die Pakete weg.

Also, so rum geht's schon mal nicht.


Du könntest mit einer zweiten Routing Tabelle Arbeiten und mit ip rules Anfragen von deinem Client an deinen VPS an die zweite Routing Tabelle verweisen.

 

[eXTA]

Klingt logisch

Bei Routing wirds dann für mich etwas zäh, CCNA ist bereits 8 Jahre her und seitdem auch nicht wirklich praktisch damit gearbeitet.

Hab mal kurz überflogen https://www.thomas-krenn.com/de/wiki/Zwei_Default_Gateways_in_einem_System
Das fängt bei mir schon damit an, dass in /etc/network/interfaces kaum was drin steht.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

 

[NiclasM]

Hm, wenn du willst können wir das zusammen per TeamViewer machen. Wenn Interesse -> PN.

 

[fdsonne]

Hab mal kurz überflogen https://www.thomas-krenn.com/de/wiki/Zwei_Default_Gateways_in_einem_System
Das fängt bei mir schon damit an, dass in /etc/network/interfaces kaum was drin steht.

Ist doch auch klar -> du hast nur das Loopback Interface sowie dein eth0 -> letzteres steht dabei sogar noch auf DHCP, sprich bezieht die IP automatisch anstatt statisch konfiguriert. Warscheinlich bekommst du eine fixe IP vom DHCP Server zugewiesen anhand der MAC des eth0 Interfaces.


Was dein Problem angeht, es kann mehrere Gründe haben. Der eine, wie oben schon erwähnt wurde, wenn du jeglichen Traffic durch den Tunnel schickst, dann kann folgerichtig auch das Rückpacket für deine SSH Session nicht am Tunnel vorbei gehen. Das Teil antwortet einfach nicht mehr.
Wenn du die Source IPs/Netze kennst, wovon du die SSH Session ausbaust, könntest du dich mal in Split Tunneling einlesen... Das bedeutet, dass es möglich ist, auch Traffic am Tunnel vorbei zu schicken. Der vServer hat ja so oder so eine Routing Table, die genutzt wird -> da stehen Routen drin, damit du erstmal überhaupt in Richtung INet kommunizieren kannst. Wenn du nun die bekannten Sourcen in Verbindung mit Split Tunneling am Tunnel vorbei Routest, dann kommst du gleichsam auch via SSH da dran/drauf. -> Nachteil ist, dass dabei jeglicher Traffic von/zu diesen IPs/Netzen am Tunnel vorbei geht.


Ich denke aber, es wäre hilfreich, wenn du mal skizzierst, was du genau vorhast. Das macht die Überlegungen für uns und das Verständnis für dich wohl etwas einfacher. Sprich wer ist wie involviert, wer soll mit wem reden können und was wird genau benötigt, sprich was soll das Konstrukt abdecken.

Denn so rein aus dem Bauchgefühl herraus würde ich sagen, wenn du zwischen zwei vServern einen Tunnel spannst, solltest es eigentlich ausreichend sein, wenn sich diese beiden vServer selbst unterhalten können. Ggf., sofern noch eine Dritte Partei im Spiel ist (bspw. ein dritter Router -> bei dir Zuhause), sollte dessen IP bzw. das Netz dahinter ebenso im Konstrukt bekannt sein, damit du von diesem aus über den Tunnel sprechen kannst.
Denn es besteht je nachdem, was du wie erreichen willst durchaus ein Unterschied in der Umsetzung... Verkettest du (bildlich gesehen) vServer A mit vServer B und an B hängt dann der Client Router Zuhause, so müsstest du Routingeinträge bekannt geben, damit der Router C (Zuhause) über B zu A (und zurück) kommunizieren kann. Technisch ggf. einfacher umzusetzen wäre ein Multitunnel Konstrukt. Sprich Jeder mit Jedem? Sprich Router C hat einen Tunnel zu A und zu B -> damit sind die Wege klar. Traffic zwischen A und B geht über einen dedizierten Tunnel. Mit geschickten Einträgen in der Routingtable ist es somit möglich, von C aus A direkt oder indirekt über B zu erreichen. Technisch gesehen wäre damit ein direktes ansprechen auf SSH von public nicht mehr wirklich notwendig, da du fast sicher sein kannst, dass mindestens ein Weg zu einem der vServer steht.

Auf der anderen Seite, wenn du das unbedingt brauchst, könnte man mit Routingeinträgen großer Netzbereiche arbeiten. Das hat den Charm, dass du damit keine default Routen durch den Tunnel setzen musst, sondern die default Route am Tunnel vorbei geht. Da näher spezifizierte Bereiche idR bevorzugt werden, wird der vServer seine Pakete durch den Tunnel schicken, es sei denn, der Tunnel steht nicht, dann greifen auch die Routen nicht mehr. In Verbindung mit Split Tunneling wäre es ein möglicher Lösungsansatz. Das Problem dabei ist nur, wenn du mit zwei vServern arbeitest, musst du dich entscheiden, wohin du die Pakete schickst... Volldynamisch wäre dann eher was für den advanced Ansatz -> dynamische Routing Protokolle ala OSPF, EIGRP, BGP und Co. -> ich denke, das würde für den "Leihen" etwas zu weit gehen.


PS: was mir gerade noch einfällt. Du schreibst oben was von "wenn ich nun den Client auf dem vServer starte" -> ich würde wenn möglich Branche Office Verbindungen schalten, anstatt diese Client/Server Tunnel. Keine Ahnung, wie man das genau bei den ganzen Softwaretools schimpft. Allerdings meine ich damit genau den Part, mitdem du zwei Router über einen Tunnel verbindest, wie als wären sie direkt mit einem Kabel im verbunden. -> die Client Einwahl über einen VPN Client ist da eher ungünstig, da es damit eben der Fall ist, das man sich den "Client" zum Server holt. Sprich der Client bekommt eine definierte IP im eigenen Netz (oder einen dediziert definierten Netz). Bei der Branche Office Verbindung gibst du hingegen in der SA die IPs und Netze bekannt, die im Tunnel erreichbar sein sollen. Beide seiten können dabei aber mit ihrer eigenen IP agieren. -> das macht das Konstrukt einfacher aus meiner Sicht.

 

[eXTA]

Okay, ich kläre mal etwas weiter auf.
Wenn irgendwas an iptables etc benötigt wird, kann ich das auch nachreichen.

Der Aufbau soll wie folgt sein:
Ich verbinde mich von einem Windows PC via OpenVPN-Client mit meinem VPS, welcher extern gehostet wird, auf dem Ubuntu läuft.
Dieser VPS soll als Client mit einem weiteren VPN-Server (Cyberghost) verbunden werden.

Router sind da jetzt direkt nicht involviert.

Über Sinn und Unsinn des Ganzen müssen wir ja nicht unbedingt diskutieren, ich wollte es nur mal ausprobieren.

Das mit dem Tunneling hatte ich bei meiner Recherche auch schon gelesen.


Als ich vorhin mal die Sache mit dem ip route ausprobieren wollte, scheiterte es irgendwie an den benutzten Netzen/Clients seitens Cyberghost.
Aus dem Verbindungslog kann ich nicht alles entnehmen. (das ist das aus Post #1)

 

[TCM]

Läuft auf dem Server ein Paketfilter? Wenn der "state" einer eingehenden Verbindung korrekt getrackt und auf das richtige Interface fixiert wird, dann ist es egal, was die Routingtabelle sagt. Eingehende Verbindungen würden dann "einfach so" funktionieren. Zumindest ist das bei PF (OpenBSD manual pages) so.

 

[eXTA]

Naja, iptables ist installiert

 

[TCM]

Ist es aktiv? Ist es per default "stateful"? Ich weiß nicht viel über das Zeug.

 

[fdsonne]

Der Aufbau soll wie folgt sein:
Ich verbinde mich von einem Windows PC via OpenVPN-Client mit meinem VPS, welcher extern gehostet wird, auf dem Ubuntu läuft.
Dieser VPS soll als Client mit einem weiteren VPN-Server (Cyberghost) verbunden werden.

Und kannst du nicht zwischen den beiden VPS einfach eine normale VPN Connection einrichten, eben Branch Office Connection anstatt einer Einwahlverbindung? Das würde das Problem irgendwie stark vereinfachen...
Denn das was du da vor hast, ist irgendwie nicht wirklich das, für was man das Zeug normal benötigt.
Normal wäre die statische Verbindung zwischen den beiden VPS (sollten ja beider 24/7 erreichbar sein??) und dann einfach mit dem Client aus auf die Ubuntu Kiste einwählen. Routing sauber konfigurieren bzw. die Tunnel SAs sauber definieren und fertig die Laube.
Eigentlich kein Hexenwerk und wird in Firmen mit verteilten Standorten oftmals so benutzt. Nur das dort häufiger auch "Hardware" VPN Router stehen, die die Tunnelgeschichten übernehmen anstatt deratiger Softwarelösungen. Rein vom Verfahren her sollte es aber faktisch keinen Unterschied machen. Denn so oder so würde dein beiden VPS Servern einfach nur ein zusätzliches virtuelles Tunnelinterface geschalten, wenn der Tunnel steht -> darüber "sehen" diese sich dann. Der eingewählte Client vom Ubuntu Server hätte dann ein Netz, was im Tunnel bekannt ist und kann zum Cyberghost VPS sprechen -> wenn du die default Router (bzw. näher spezifizierte Routen) durch den Tunnel schickst, "geht auch das INet" nach der Einwahl diesen Weg...

 

[eXTA]

Ich kann am Cyberghost Server nix konfigurieren, genausowenig die Router.
Also bleibt ja nur diese Möglichkeit (?)

Und klar, so eine kleine Firefox o.ä. hinstellen wäre natürlich einfacher.

 

[fdsonne]

Wäre es ggf. möglich, dass du nicht mit einer Client Software vom Ubuntu VPS den Tunnel spannst, sondern das über OpenVPN oder ähnliches tätigst? Also ich meine nicht den VPN Client, sondern die Server Software davon, die ja bei dir auf dem Ubuntu Server läuft, da du ja den Tunnel von dem Windows Client spannst... -> da muss doch auch ein statischer Tunnel zu einem anderen VPN Device gehen, halt den CyberGhost VPS?
Weil im Grunde ist technisch gesehen der Unterschied ja eher die Software, mit der du das fabrizierst. Muss aber gestehen, da mit OpenVPN nicht so wirklich was am Hut zu haben... Sondern bin halt eher der Hardwaretyp, bzw. hab meine Jungs aus dem Netzwerkteam, die das dann machen, am besten sogar so, wie ich das will
Aus meiner Sicht sollte der Knackpunkt ja erstmal der sein, dass der Ubuntu Server bei stehendem Tunnel den Spaß dann nich tmehr annimmt bzw. verwirft (ggf. sogar noch antwortet, aber eben dann durch den Tunnel, wenn dieser steht und mit die Pakete ins Nichts verschwinden. Vor allem wenn da anständige Firewalls irgendwo dazwischen stehen, die einfach das Zeug wegdroppen, was nicht da hin gehört -> also wo Antwortpakete von Verbindungen kommen, wo die Hinpakete gar nicht vorhanden waren/sind.

 

[eXTA]

Also Firewall ist im "Kundencenter" vom VPS deaktiviert. Bis jetzt ging auch alles durch wie es soll.
Das wird schon mit sehr hoher Wahrscheinlichkeit ein Routingproblem sein bzw. mit Tunneling probieren.

Und alles wird mit OpenVPN realisiert.
Auf Windows-PC eine Clientkonfiguration, auf dem VPS Serverkonfiguration (und die Verbindung läuft tadellos), und auf dem VPS halt gleichzeit eine Clientkonfig Richtung Cyberghost. Bzw "gleichzeitig" läuft das ja nicht, entweder Client oder Server.

Jetzt gerade habe ich auch nicht die Muße, mich da reinzudenken, vielleicht nächste Woche mal.
Das ganze eilt ja nicht, ist alles nur Spielerei und Testumgebung.


Bezüglich iptables, hier mal die aktuelle Konfig aus der rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

#Port 443, 1194 Freigabe
iptables -A FORWARD -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT
#OpenVPN Server
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -o eth0 -i tun0 -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

#L2TP IPSec
for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done
iptables -t nat -A POSTROUTING -j SNAT --to-source $SERVERIP$ -o eth0


exit 0

 

[TCM]

443 ist der SSH-Port? Und wenn du bei der 443-Regel auch -m conntrack --ctstate NEW mit ranschreibst, gehts dann?

 

[eXTA]

Also

iptables -A FORWARD -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

?

Damit ging auch nix mehr von außen, nachdem die Verbindung zu Cyberghost hergestellt wurde.


Das ist die .ovpn, mit der sich der VPS als Client verbindet:

client
remote 4-de.cg-dialup.net 443
dev tun 
proto udp
auth-user-pass pw.txt

resolv-retry infinite 
redirect-gateway def1
persist-key
persist-tun
nobind
cipher AES-256-CBC
auth MD5
ping 5
ping-exit 60
ping-timer-rem
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
tun-mtu 1500 
fragment 1300
mssfix 1300
verb 4
comp-lzo


ca ca.crt

cert client.crt

key client.key

Mich wundert, dass das ganze über 443 mit UDP läuft und funktioniert. Ist 443 nicht TCP only?

 

[fdsonne]

Nein, warum sollte es? HTTPS ist TCP Port 443. Welchen "Dienst" du aber explizit über einen Port schickst, ist eigentlich nicht 100% fix definiert. Du kannst auch HTTP über Port TCP 443 schicken um mal ein Beispiel zu bringen.
Ich kenne nun wie erwähnt OpenVPN nicht im Detail. Es gibt aber andere VPN Lösungen am Markt, die Tunnel via TCP oder UDP 443 herstellen. Bspw. bei einer Anyconnect Einwahl auf eine Cisco ASA. Dort sogar sogar soweit, dass erst UDP 443 probiert wird -> wenn das nicht geht, wird auf TCP 443 geschwenkt.

Ansonsten, wenn ich mir den Screenshot im ersten Post ansehe, kannst du die Routen, die da reingeschaufelt werden, ändern?
Durch die Routen, die du dort setzt bzw. die gesetzt werden, schickst du wie oben schonmal erwähnt, ALLES durch den Tunnel. Das sind die beiden Einträge mit 0.0.0.0/1 auf IP xy und 128.0.0.0/1. -> durch diese beiden Einträge sagst du, dass sowohl der untere halbe gesamte IPv4 Netzbereich sowie der obere halbe gesamte IPv4 Netzbereich über die 10.129.39.249 erreichbar sind. Das kommt quasi einem default Gateway Eintrag gleich. Allerdings, da zwei Routen mit jeweils einem halben Netzbereich eine "nähere" Spezifikation sind, als eine default Route, drängelt sich das folgerichtig vor.

Wie oben schon erwähnt, ich denke es wäre günstig, wenn du hier einfach nur im Tunnel zu CyberGhost die Netze bekannt gibst/routest, die du damit auch erreichen willst. Das ist natürlich "blöd" wenn du INet Zugriffe über diesen zweiten Tunnel abdecken willst. Denn dann sollte diese Route schon bestehen (bleiben)

-> du hast eigentlich nur zwei Optionen:
- entweder du drehst die Routen zum Cyberghost Server so um, dass dort nur Netze hingeroutet werden, die da hinter dem Cyberghost Server erreichbar sein sollen. Damit wäre es bspw. möglich, bestimmte IP Netze lokal oder aus dem INet durch explizit genau diesen Tunnel zu schicken und den Rest am Tunnel vorbei direkt am Ubuntu Server rauszulassen. Inkl. der Möglichkeit, dass der SSH Access damit normal wieder funktionieren sollte!
- oder du schickst alles durch den Tunnel und setzt näher spezifizierte Routen von Source IPs/Netzen, die du am Tunnel vorbei routest. Quasi das gleiche in Bund, nur genau umgedreht. Denn hier schickst du alles in den Tunnel, was nicht näher spezifiziert ist. Bei der ersten Option schickst du nur das spezifizierte in den Tunnel.

Das zumindest erstmal die eine Geschichte... Auf der anderen Seite musst du schauen, wie der "Spaß" auf der Client/Windows Seite zum Ubuntu VPS ausschaut... Denn dort ist das Prinzip im Grunde gleich. Wenn du den Ubuntu VPS am Tunnel vorbei mit seiner public IP via SSH ansprechen willst, dann muss das natürlich auch erlaubt sein -> möglicherweise ist dort deine Config also auch kontraproduktiv, dir fällt es nur nicht auf, weil du entweder Tunnel und normale INet Connection oder nur normale INet Connection zur IP des Ubuntu Servers stehen hast -> bei beiden hättest du wohl dann ein asyncrones Routing. Unsauber, ggf. aber funktional... Je nach Hardware/Software wird das nicht unbedingt verworfen. Bei ner echten Firewall dazwischen hingegen könnten die Rück-Pakete wegfliegen -> weil die Hin-Pakete nicht den selben Weg gegangen sind