Mein Server sollte mit einem VPN verbunden sein alsKlient. Wenn ich das OpenVPN-Skript (von HMA) ausführe, geht die Verbindung von meinem lokalen Computer zum Server über SSH verloren – eine Verbindung ist nicht mehr möglich und ich muss den VPN-Prozess manuell beenden. Außerdem ist in dieser Zeit ein versteckter TOR-Dienst (.onion-Seite) nicht verfügbar.
Ist es irgendwie möglich, dass die TOR-Seite verfügbar ist und ich eine Verbindung über SSH herstellen kann, während der Server mit dem VPN verbunden ist?
Antwort1
Das Problem besteht darin, dass das Standard-Gateway von OpenVPN geändert wird und dadurch jede Verbindung unterbrochen wird, die über die Nicht-VPN-Schnittstelle eingeht. Linux sendet Antworten auf Pakete, die über die echte Schnittstelle eingegangen sind, über die VPN-Schnittstelle! Sie müssen entsprechende Routen einrichten, bevor Sie OpenVPN starten.
Was folgt, funktioniert bei mir. Es verwendet iptables und ip (iproute2). Im Folgenden wird angenommen, dass die Standard-Gateway-Schnittstelle vor dem Start von OpenVPN „eth0“ ist. Die Idee besteht darin, sicherzustellen, dass beim Herstellen einer Verbindung zu eth0, auch wenn eth0 nicht mehr die Standard-Gateway-Schnittstelle ist, Antwortpakete für die Verbindung wieder über eth0 zurückgehen.
Sie könnten für die Verbindungsmarkierung, die Firewallmarkierung und die Routingtabelle dieselbe Nummer verwenden. Ich habe unterschiedliche Nummern verwendet, um die Unterschiede zwischen ihnen deutlicher zu machen.
# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412
# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412
===
AKTUALISIEREN:
Das oben genannte funktioniert bei mir unter Debian Jessie einwandfrei. Aber auf einem älteren Wheezy-System habe ich gerade festgestellt, dass ich dem Routing-Tabelleneintrag "via" hinzufügen muss:
# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412
Dort muss „12.345.67.89“ das ursprüngliche Nicht-VPN-Gateway sein.
Antwort2
Ich habe ein ähnliches Problem. Mein Ubuntu-Desktop befindet sich in einem VPN und meine normale SSH-Verbindung funktioniert von außerhalb des Heimnetzwerks nicht.
Mir ist aber gerade etwas eingefallen. Haben Sie die Ports immer noch an diesen Computer weitergeleitet?
Das VPN weist vom VPN-Standort eine neue IP-Adresse zu, sodass der Router diese IP-Adresse nicht mehr finden kann, um eine Verbindung herzustellen.
Ich würde davon ausgehen, dass Sie die neue IP-Adresse kennen müssen, die Ihnen vom VPN-Host zugewiesen wurde, um zu wissen, mit welcher Adresse Sie eine Verbindung herstellen müssen.
Ich gebe nur fundierte Vermutungen ab und kenne keine bekannte Lösung. Beschimpfen Sie mich also bitte nicht, wenn es nicht funktioniert. :)
Bei weiteren Untersuchungen habe ich festgestellt, dass Sie die Ports über Ihr VPN weiterleiten müssen (glaube ich), weil das VPN Port 80 umleitet und Ihre SSH-Tunnel normalerweise Port 22 verwenden. Ich denke, Sie müssen Port 22 über Ihr VPN weiterleiten, damit Sie bei der Verbindung mit Ihrem VPN über Port 80 zu dem weitergeleiteten Port weitergeleitet werden, der für Ihren SSH-Tunnel, d. h. PuTTy, erforderlich ist.
Ich bin mir immer noch nicht 100 % sicher, ob das so geht. Wenn das jemand bestätigen könnte, wäre das großartig.