Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Leider kann man bei VPN Abbruch trotzdem mit dem eingetragenem Programm in meinem Fall Firefox Webseiten aufrufen.
Auf meiner VM am PC mit Win 7 funktioniert es aber Problemlos.
Bitte um Hilfe
Ps. ich will mir auf meinem Notebook nicht die Comodo einrichten müssen deswegen der Griff zu der Windows Lösung.
Sind die Netzwerktypen korrekt gesetzt, d.h. ist dein normaler Internetzugang als Privatnetzwerk und der VPN-Tunnel als öffentliches Netzwerk konfiguriert? Hast du einmal getestet, ob das Problem auch in Verbindung mit anderen Anwendungen auftritt?
Eine Alternative zu einem Paketfilter wäre übrigens, die Routing-Konfiguration so anzupassen, dass bei einem VPN-Abbruch das alte Standard-Gateway nicht wiederhergstellt wird. Welches VPN-System (OpenVPN, PPTP, ...) und welchen Anbieter setzt du ein? Wenn du den Tunnel aufbaust und danach die Ausgabe von `route print` (auf der Kommandozeile ausgeführt - Win-R, `cmd.exe` ausführen, Befehl eintippen) postest, könnte ich dir nötigen Anpassungen nennen.
Danke für den route-print-Output. In deinem Fall müsste ein
Code:
route delete 0.0.0.0 mask 0.0.0.0 192.168.0.1
nach dem Aufbau des Tunnels ausreichen, um das alte Standard-Gateway zu löschen.
Um ohne Neustart des System nach dem (gezielten) Abbau des Tunnels wieder eine direkte Internetverbindung zu erhalten, reicht
Code:
route add 0.0.0.0 mask 0.0.0.0 192.168.0.1
um das Standard-Gateway wieder einzutragen.
Beachte, dass diese Befehle mit administrativen Rechten ausgeführt werden müssen - entweder von einem Administator-cmd-Prompt aus oder aus einer Batch-Datei, welche du als Administrator ausführst (Rechtsklick -> `Als Administrator ausführen` oder permanent über die Dateieigenschaften).
Um das etwas detaillierter zu erklären, da ich diesbezüglich einige Anfragen erhalten hatte: Relevant sind bei der Ausgabe von `route print` die Zeilen
sind die von OpenVPN bei aktiver `redirect-gateway def1`-Option erzeugten /1-Routen (/1 = Subnetzmaske 128.0.0.0), um das alte Standard-Gateway zu ersetzen - diese führen in diesem Beispiel über den VPN-Endpunkt 10.23.42.1). Die Zeile
ist die frühere Standard-Gateway-Route (/0 = Subnetzmaske 0.0.0.0 = Standard-Gateway), in diesem Beispiel über den Router 192.168.0.1. Bei dieser Routing-Konfiguration kann das Standard-Gateway demnach per
gelöscht werden (man beachte die Gateway-IP, in diesem Beispiel 192.168.0.1), was zur Folge hat, dass keine Pakete mehr in nicht-lokale Netzwerke geroutet werden können, wenn die VPN-Verbindung zusammenbrechen und OpenVPNs /1-Routen wegfallen sollten. Um nach einem bewussten Abbau des VPN-Tunnels das alte Standard-Gateway wiederherzustellen, reicht es aus, das Gegenstück zum obigen delete-Kommando auszuführen
Oh, die Frage muss mir entgangen sein. Ob das Vorgehen auch auf andere VPN-System anwendbar ist, hängt von der konkreten Routing-Konfiguration (nach dem Aufbau des jeweiligen VPN-Tunnels) ab. Wenn du die Ausgabe von `route print` nach dem Aufbau eines konkreten VPNs postest, kann ich dir sagen, ob das Vorgehen so anwendbar ist oder nicht.
User schrieb:
Ich weiß nicht was alles rückgesetzt wurde nach dem Angriff auf das Forum.
Verloren gegangen bzw. absichtlich nicht wiederhergestellt wurden nur diejenigen Änderungen, welche nach dem Angriff während der folgenden Minuten vorgenommen wurden. Der Zustand vor dem Angriff wurde vollständig wiederhergestellt.
zum gewünschten Verhalten führt. Da zwei Standard-Gateways (d.h. /0-Routen) eingetragen sind, müsste das funktionieren, sofern der L2TP-Client beim Verbindungsabbau die alte Konfiguration nicht explizit wiederherstellt.
Code:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.102 4250
0.0.0.0 0.0.0.0 Auf Verbindung 192.168.26.2 26
Hallo!
Es wird die Verbindung geblockt.
Super :-)
Jetzt ist es bei mir so das nicht nur Open Vpn sondern auch L2TP Verbindungen geblockt werden bei Verbindungsabbruch.
Mit dem Selben Befehl
route delete 0.0.0.0 mask 0.0.0.0 192.168.0.1
in einer .bat Datei
Echt eine tolle Lösung
Nochmal Danke für den Support /Hilfestellung
ich mühe mich seit Tagen meinem System beizubringen, dass es, wenn die VPN-Verbindung abbricht, nicht weiter über sein normales Gateway connecten soll.
Dabei bin ich auf die schöne Erklärung von Kugelfisch hier gestoßen. Danke schon mal dafür.
Im Prinzip funktioniert das auch. Ich setze:
Code:
route delete 0.0.0.0 mask 0.0.0.0 10.0.0.1
Mein Router hat die IP 10.0.0.1, der Win7 PC auf dem OpenVPN läuft hat die 10.0.0.155 - wenn ich jetzt die VPN-Verbindung trenne, ist auch tatsächlich keine Verbindung mehr möglich.
Aber jetzt tun sich zwei Probleme auf.
1. versuche ich nun einen reconnect zum VPN-Anbieter (nVPN) werde ich dort abgewiesen mit der Meldung:
"cannot resolve host adress xyz. Der angegebene Name ist gültig, es wurden jedoch keine Daten des angeforderten Typs gefunden"
nach Eingabe von
Code:
route add 0.0.0.0 mask 0.0.0.0 10.0.0.1
Lässt sich die Verbindung wieder herstellen.
2. ich sperre mich selbst aus... Ich benutze das System über Teamvievier, aber im eigenen Netz.
Ich kann netzintern nicht mehr von 10.0.0.27 auf 10.0.0.155 zugreifen.
Eigentlich möchte ich nur Verbindungen ins Internet blockieren, wenn VPN nicht läuft, netzinterne Verbindungen aber zulassen.
Irgendwie bin ich zu blöd die Routingregeln zu begreifen, ich habe mich vorher auch schon erfolglos am Windows Firewall und an Comodo abgemüht.
So eine einfache Regel wie
..erlaube Verbindungen ins Internet generell nur über VPN, fällt VPN aus, blokiere ein- und ausgehende Verbindungen ins Internet, lasse aber netzinterne Zugriffe zu....
bekomme ich einfach nicht gebacken :-(
Hat jemand für mich eine step-by-step Lösung oder ein Tool zur Hand, was das für mich übernimmt? Ich bin kein Netzwerkfachmann und auch schon ein alter Mann und muss mich mühsam in die Materie einlesen. Batchs kann ich halbwegs schreiben - das musste man in der Zeit, aus der ich komme noch können :-)
1. versuche ich nun einen reconnect zum VPN-Anbieter (nVPN) werde ich dort abgewiesen mit der Meldung:
"cannot resolve host adress xyz. Der angegebene Name ist gültig, es wurden jedoch keine Daten des angeforderten Typs gefunden"
Das ist beabsichtigt, da durch das gelöschte Standard-Gateway auch der DNS-Server nicht mehr erreicht werden kann, sofern dieser nicht in deinem lokalen Netzwerk liegt. Um DNS-Leaks zu verhindern, ist das ja durchaus wünschenswert.
Das Problem kann ich anhand der Routing-Tabelle, die du mir per PN hast zukommen lassen, nicht nachvollziehen: Gemäss
Code:
10.0.0.0 255.255.255.0 Auf Verbindung 10.0.0.155 266
besteht eine Route für das lokale Netz, welche aufgrund der Präfixlänge Präferenz gegenüber der /1-Route von OpenVPN haben müsste. Tritt das Problem tatsächlich erst auf, nachdem du das Standard-Gateway löschst? Sind möglicherweise noch Paketfilter/Firewalls von deinen vorherigen Versuchen aktiv?
Ja, das Prinzip wäre exakt dasselbe, lediglich die Syntax des `route`-Befehls (alternativ: `ip route`) unterscheidet sich. Alternativ liesse sich auch Netfilter/iptables einsetzen - ein Beispiel dafür habe ich in
Das ist beabsichtigt, da durch das gelöschte Standard-Gateway auch der DNS-Server nicht mehr erreicht werden kann, sofern dieser nicht in deinem lokalen Netzwerk liegt. Um DNS-Leaks zu verhindern, ist das ja durchaus wünschenswert.
Danke - da lag also ein Denkfehler meinerseits vor.
Aber um das so zum Laufen zu bringen wie ich möchte muss ich das irgendwie noch automatisieren.
Jetzt ist es so, dass nach der Zwangstrennung durch den ISP (oder Trennung aus anderen Gründen) die VPN-Verbindung abbricht und so stehen bleibt.
Da auf der Maschine ein P2P Client läuft, wäre es wünschenswert, wenn OpenVPN reconnect Versuche macht. Die verhindere ich aber ja durch das Löschen der Route auch.
Erwünscht wäre also sozusagen ein automatisches Wiederverbinden durch VPN mit der Sicherheit, dass nicht am VPN vorbei connectet wird.
Wie könnte man das gestalten das zu automatisieren?
besteht eine Route für das lokale Netz, welche aufgrund der Präfixlänge Präferenz gegenüber der /1-Route von OpenVPN haben müsste. Tritt das Problem tatsächlich erst auf, nachdem du das Standard-Gateway löschst? Sind möglicherweise noch Paketfilter/Firewalls von deinen vorherigen Versuchen aktiv?
Jaaa.. da sieht man wieder mal, dass ich sowas von gar keine Ahnung habe. Ich verstehe deine Aussage mangels Vorwissen quasi überhaupt nicht.
- das Problem besteht tatsächlich nach dem Löschen der Route, aaaber
- es ist nicht ganz so, wie ich es heute Nacht beschrieben habe. Der Rechner ist netzintern Pingbar. das Problem scheint im Teamviewer zu liegen. Der bekommt einen Connect
"außenherum" (über deren Server) hin, versucht man es aber intern über die IP geht es nicht (Fehlermeldung unbekannter Fehler)
- sind noch Paketfilter aktiv? Wie bekomme ich das heraus?
Hallo!
An dieser Stelle möchte ich nochmal Danke sagen für die Lösung.
Funktioniert echt Top, da lohnt es sich öfter im Forum zu stöbern.
DANKE Kugelfisch :-)
Das zu automatisieren wäre wenig sinnvoll, denn dadurch bestünde während des Neuverbindens die Gefahr von IP-Leaks. Sinnvoller wäre, für die OpenVPN-Server-IP eine /32-Route anzulegen (11.22.33.44 ist durch die IP-Adresse deines VPN-Servers zu ersetzen)
und in deiner OpenVPN-Konfigurationsdatei den Hostnamen durch die IP-Adresse zu ersetzen, damit zum Verbindungsaufbau kein DNS-Server kontaktiert werden m
