22
Windows ignoriert sporadisch Metrik bei mehreren Default-Gateways
Hallo zusammen,
ich nutze seit vielen Jahren regelmäßig VPNs, darunter früher Hamachi, OpenVPN, Cisco und ZeroTier. Manche VPNs konfigurieren einen Default-Gateway der allerdings nicht ins Internet routet.
An sich ist das kein Problem, denkt man. Ich sorge dafür dass die Schnittstellenmetrik der VPN Adapter höher ist als die meines (W-)LAN über das ich ins Internet gehe, und dann sollte das eigentlich funktionieren (meist ist das mit der auto-metrik eh der Fall). route print listet mir entsprechend zwei 0.0.0.0/0 routen mit Metriken analog der Schnittstellenmetriken (VPN deutlich größer als (W-)LAN).
Leider sieht die Realität anders aus. Sowohl unter Windows 10 als auch früher Windows 8 habe ich das Problem dass sporadisch "das Internet ausfällt".
Ein Blick in Wireshark zeigt dann, dass Windows den gesamten Traffik plötzlich über das VPN routet.
Dies passiert gänzlich ohne Schema, mal alle paar Minuten, mal ein paar Stunden garnicht. Mal löst sich das Problem innerhalb ein paar Sekunden von selbst, mal dauert es bis ich die Geduld verliere und den VPN Adapter deaktiviere und reaktiviere.
Ich kann dieses Verhalten weder erklären, noch habe ich bisher irgendwo Beschreibungen dazu gefunden. Trotzdem ist es mir allgegenwärtig, auf unterschiedlichen PCs und mit unterschiedlicher VPN und Windows Software.
Mit OpenVPN hatte ich die Möglichkeit selbst festzulegen, wie die Routen konfiguriert werden. Aber nicht jedes VPN lässt das zu.
Eine Lösung war, die Default-Route aufzusplitten. Statt 0.0.0.0/0 hatte ich einfach 0.0.0.0/1 + 128.0.0.0/1 konfiguriert.
Dies löste das Problem und führte dazu, dass der Default-Gateway des VPN nur angesprungen wurde, wenn keiner mit 0.0.0.0/0 existierte.
Edit: Äh moment, wenn ich recht drüber nachdenke sorgte das dafür dass immer der GW des VPN angesprungen wurde, da die Netzmaske spezifischer ist...
Nun stehe ich mit ZeroTier wieder vor dem Problem... Und es nervt ;)
Gibt es andere, die Ähnliche Erfahrungen gemacht haben? Wie löst ihr das Problem?
Besten Dank!
ich nutze seit vielen Jahren regelmäßig VPNs, darunter früher Hamachi, OpenVPN, Cisco und ZeroTier. Manche VPNs konfigurieren einen Default-Gateway der allerdings nicht ins Internet routet.
An sich ist das kein Problem, denkt man. Ich sorge dafür dass die Schnittstellenmetrik der VPN Adapter höher ist als die meines (W-)LAN über das ich ins Internet gehe, und dann sollte das eigentlich funktionieren (meist ist das mit der auto-metrik eh der Fall). route print listet mir entsprechend zwei 0.0.0.0/0 routen mit Metriken analog der Schnittstellenmetriken (VPN deutlich größer als (W-)LAN).
Leider sieht die Realität anders aus. Sowohl unter Windows 10 als auch früher Windows 8 habe ich das Problem dass sporadisch "das Internet ausfällt".
Ein Blick in Wireshark zeigt dann, dass Windows den gesamten Traffik plötzlich über das VPN routet.
Dies passiert gänzlich ohne Schema, mal alle paar Minuten, mal ein paar Stunden garnicht. Mal löst sich das Problem innerhalb ein paar Sekunden von selbst, mal dauert es bis ich die Geduld verliere und den VPN Adapter deaktiviere und reaktiviere.
Ich kann dieses Verhalten weder erklären, noch habe ich bisher irgendwo Beschreibungen dazu gefunden. Trotzdem ist es mir allgegenwärtig, auf unterschiedlichen PCs und mit unterschiedlicher VPN und Windows Software.
Mit OpenVPN hatte ich die Möglichkeit selbst festzulegen, wie die Routen konfiguriert werden. Aber nicht jedes VPN lässt das zu.
Eine Lösung war, die Default-Route aufzusplitten. Statt 0.0.0.0/0 hatte ich einfach 0.0.0.0/1 + 128.0.0.0/1 konfiguriert.
Dies löste das Problem und führte dazu, dass der Default-Gateway des VPN nur angesprungen wurde, wenn keiner mit 0.0.0.0/0 existierte.
Edit: Äh moment, wenn ich recht drüber nachdenke sorgte das dafür dass immer der GW des VPN angesprungen wurde, da die Netzmaske spezifischer ist...
Nun stehe ich mit ZeroTier wieder vor dem Problem... Und es nervt ;)
Gibt es andere, die Ähnliche Erfahrungen gemacht haben? Wie löst ihr das Problem?
Besten Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 360420
Url: https://administrator.de/contentid/360420
Ausgedruckt am: 24.11.2024 um 19:11 Uhr
22 Kommentare
Neuester Kommentar
Hi,
ich fürchte, Du hast hier ein Mißverständnis bei der "0.0.0.0" Route. Das ist die Default-Route (Default Gateway) und davon sollte ein Host nur eine haben.
Die VPN haben doch alle einen Sinn? Bestimmte, bekannte Netze zu erreichen? Wenn der Rest weiter über Internet gehen soll ("die Welt") dann darf man für diese VPN keine Default Gateways einstellen. Statt dessen jeweils explizite Routen für die jeweiligen Zielnetze.
E.
ich fürchte, Du hast hier ein Mißverständnis bei der "0.0.0.0" Route. Das ist die Default-Route (Default Gateway) und davon sollte ein Host nur eine haben.
Die VPN haben doch alle einen Sinn? Bestimmte, bekannte Netze zu erreichen? Wenn der Rest weiter über Internet gehen soll ("die Welt") dann darf man für diese VPN keine Default Gateways einstellen. Statt dessen jeweils explizite Routen für die jeweiligen Zielnetze.
Statt 0.0.0.0/0 hatte ich einfach 0.0.0.0/1 + 128.0.0.0/1
Ähhh ... Hä?E.
Hi,
Naja, nein... Routing, und da macht der Default-Gateway keine Ausnahme, kann natürlich für ein Ziel mehrere Routen haben. Und genau dafür gibt es z.B. die Metrik, um nämlich dann zu entscheiden welche der möglichen Routen genommen wird.
Schön, das sehe ich oft auch so, aber das ist nicht unter meiner Kontrolle. Software wie früher Hamachi oder heute ZeroTier erlaubt dir nicht den Default Gateway zu entfernen oder umzukonfigurieren (jedenfalls nicht über vorgesehene Wege).
0.0.0.0/1 -> Route für 0.0.0.1 bis 127.255.255.255
128.0.0.0/1 -> Route für 128.0.0.0 bis 255.255.255.254
Entspricht der selben Route wie 0.0.0.0/0, sorgt aber dank der abweichenden Netzmaske für eine andere Bewertung durch Windows.
*) Jetzt muss ich mich aber gleich korrigieren... Wenn ich recht drüber nachdenke hat dieser Trick dazu geführt dass der Default-GW des VPN gegenüber dem des (W-)LAN bevorzugt wurde, weil er ja spezifischer ist... Sorry, ich nutze das OpenVPN zur Zeit nicht mehr, daher sind das ältere Erinnerungen ;)
ich fürchte, Du hast hier ein Mißverständnis bei der "0.0.0.0" Route. Das ist die Default-Route (Default Gateway) und davon sollte ein Host nur eine haben.
Naja, nein... Routing, und da macht der Default-Gateway keine Ausnahme, kann natürlich für ein Ziel mehrere Routen haben. Und genau dafür gibt es z.B. die Metrik, um nämlich dann zu entscheiden welche der möglichen Routen genommen wird.
Die VPN haben doch alle einen Sinn? Bestimmte, bekannte Netze zu erreichen? Wenn der Rest weiter über Internet gehen soll ("die Welt") dann darf man für diese VPN keine Default Gateways einstellen. Statt dessen jeweils explizite Routen für die jeweiligen Zielnetze.
Schön, das sehe ich oft auch so, aber das ist nicht unter meiner Kontrolle. Software wie früher Hamachi oder heute ZeroTier erlaubt dir nicht den Default Gateway zu entfernen oder umzukonfigurieren (jedenfalls nicht über vorgesehene Wege).
Statt 0.0.0.0/0 hatte ich einfach 0.0.0.0/1 + 128.0.0.0/1
Ähhh ... Hä?0.0.0.0/1 -> Route für 0.0.0.1 bis 127.255.255.255
128.0.0.0/1 -> Route für 128.0.0.0 bis 255.255.255.254
Entspricht der selben Route wie 0.0.0.0/0, sorgt aber dank der abweichenden Netzmaske für eine andere Bewertung durch Windows.
*) Jetzt muss ich mich aber gleich korrigieren... Wenn ich recht drüber nachdenke hat dieser Trick dazu geführt dass der Default-GW des VPN gegenüber dem des (W-)LAN bevorzugt wurde, weil er ja spezifischer ist... Sorry, ich nutze das OpenVPN zur Zeit nicht mehr, daher sind das ältere Erinnerungen ;)
eführt dass der Default-GW des VPN gegenüber dem des (W-)LAN bevorzugt wurde, weil er ja spezifischer ist...
Eben.0.0.0.0/1 -> Route für 0.0.0.1 bis 127.255.255.255
128.0.0.0/1 -> Route für 128.0.0.0 bis 255.255.255.254
Ja schon klar. Ich sehe da bloß keinen Sinn. Es sei denn, man will da sowas wie Last-Verteilung erreichen. Aber darum geht es doch bei Dir nicht.128.0.0.0/1 -> Route für 128.0.0.0 bis 255.255.255.254
Software wie früher Hamachi oder heute ZeroTier erlaubt dir nicht den Default Gateway zu entfernen oder umzukonfigurieren (jedenfalls nicht über vorgesehene Wege).
Warum sollte das nicht gehen? Einfach ein Script im Hintergrund laufen lassen, welches ständig die Routen überprüft. Und wenn eine "falsche" 0.0.0.0-Route auftaucht dann diese entfernen und durch gezielte Routen ersetzen.
Moin,
Ganz einfach: Windows spinnt, wenn man mehr als eind default route setzt, egal wascdie Metriken sagen.
Deshalb ist es eine Binsenweosheit, unter Windows das niemals zu machen.
Eigentlich macht man das am client gar nicht, sondern überläßt das routen der Routinginfrastruktur, sprich den Routern.
lks
Ganz einfach: Windows spinnt, wenn man mehr als eind default route setzt, egal wascdie Metriken sagen.
Deshalb ist es eine Binsenweosheit, unter Windows das niemals zu machen.
Eigentlich macht man das am client gar nicht, sondern überläßt das routen der Routinginfrastruktur, sprich den Routern.
lks
Warum sollte das nicht gehen? Einfach ein Script im Hintergrund laufen lassen, welches ständig die Routen überprüft. Und wenn eine "falsche" 0.0.0.0-Route auftaucht dann diese entfernen und durch gezielte Routen ersetzen.
Natürlich geht das, aber genau das ist ein unschöner und ungewollter Workaround. Ich kann auch - und das wäre simpler - die IP Konfiguration des VPN Adapters einfach manuell machen statt sie dem virtuellen DHCP der VPN Software zu überlassen. Aber dadurch verliere ich Funktionalität der VPN Software.
Die generelle Frage ist doch, warum Windows überhaupt dieses völlig Sinn freie sporadische Verhalten an den Tag legt und ob man nicht die Ursache bekämpfen kann. Die Workarounds bekämpfen ja nur das Symptom.
Ganz einfach: Windows spinnt, wenn man mehr als eind default route setzt, egal wascdie Metriken sagen.
Das ist eine Aussage die ich nicht akzeptiere ;) Ich bin ziemlich sicher dass Windows hier eine generell nachvollziehbare Logik implementiert hat, die wir hald einfach nur nicht kennen. Dass Windows über so viele Generationen hier einfach nur "spinnt", glaube ich mal nicht...
Deshalb ist es eine Binsenweosheit, unter Windows das niemals zu machen.
Ja, das steht hald nicht unter meiner Kontrolle
Eigentlich macht man das am client gar nicht, sondern überläßt das routen der Routinginfrastruktur, sprich den Routern.
Bei Einsatz eines (Software) VPN ist der Client per Definition Teil der Routinginfrastruktur. Da führt nicht wirklich ein Weg dran vorbei.
Windows benutzt meines Wissens immer das Default Gateway jener NIC, deren Bindung an oberster Stelle steht. Egal, was man da an Metric eingetragen hat.
Wenn Du da also VPN hast, die zu- und abgeschaltet werden, dann landet u.U. immer eine ander Schnittstelle an oberster Stelle und damit deren GW.
Du müsstest also dafür sorgen, dass die NIC mit dem gewünschten Default Gateway immer an erster Stelle steht.
Wenn Du da also VPN hast, die zu- und abgeschaltet werden, dann landet u.U. immer eine ander Schnittstelle an oberster Stelle und damit deren GW.
Du müsstest also dafür sorgen, dass die NIC mit dem gewünschten Default Gateway immer an erster Stelle steht.
1
Stimmt, die Adapterreihenfolge spielt hier mit. Ich weiss auch dass ich diese früher immer so angepasst habe dass die VPN Adapter weiter unten waren. Interessanter Weise kann ich unter Windows 10 diese Option garnicht mehr finden. In den Netzwerkverbindungen gibt es unter den Erweiterten Einstellungen nur noch eine "Anbieterreihenfolge".
Allerdings passt dies auch nicht mit den Beobachtungen zusammen. Es ist ja keineswegs so, dass immer das VPN bevorzugt wird. Es ist wirklich augenscheinlich völlig sporadisch und die Adapter sind zu dieser Zeit permanent aktiv...
Allerdings passt dies auch nicht mit den Beobachtungen zusammen. Es ist ja keineswegs so, dass immer das VPN bevorzugt wird. Es ist wirklich augenscheinlich völlig sporadisch und die Adapter sind zu dieser Zeit permanent aktiv...
Ganz einfach: Windows spinnt, wenn man mehr als eind default route setzt
Spinnen in der Hinsicht das Windows es primär abhängig von der Bindungsreihenfolge macht. Das Gateway mit der höheren Bindungsreihenfolge gewinnt und das sind in der Regel nicht die virtuellen Interfaces der VPNs.Da stellt sich jetzt die Frage wie Windows dann spezifisch bei Konflikten zw. Bindungsreihenfolge und Route Metriken umgeht.
Diese Logik müsste man kennen. Spannend wäre dann sicher mal ein Vergleich mit einem unixoiden OS wie sich dort ein Client unter gleichen Bedingungen verhält bzw. wer da mehr Standard konformer ist.
Letztlich hat Kollege emeriks aber Recht in der Grundeinschätzung. Ein Endgerät ist eben kein Router und verhält sich dementsprechend auch (etwas) anders.
Danke, hilft mir aber nicht. Laut Shell entsprechen die über die Shell gesetzten Metriken den Werten die man auch beim Adapter in der GUI über das IPv4/6 Protokoll als Metrik setzen kann.
Insofern ist die Einstellung bei mir bereits richtig und die Metrik des VPN deutlich höher als die des W-LAN.
Zudem sind das ja afaik statische Werte und sollten daher keine sporadischen Schwenks verursachen...
Insofern ist die Einstellung bei mir bereits richtig und die Metrik des VPN deutlich höher als die des W-LAN.
Zudem sind das ja afaik statische Werte und sollten daher keine sporadischen Schwenks verursachen...
Spinnen in der Hinsicht das Windows es primär abhängig von der Bindungsreihenfolge macht. Das Gateway mit der höheren Bindungsreihenfolge gewinnt und das sind in der Regel nicht die virtuellen Interfaces der VPNs.
Wie ich grade gelernt habe gibt es bei Windows 10 keine separate Bindungsreihenfolge mehr, sondern es entspricht (wie es sein soll) der für IPv4/6 konfigurierten Schnittstellenmetrik.
Da stellt sich jetzt die Frage wie Windows dann spezifisch bei Konflikten zw. Bindungsreihenfolge und Route Metriken umgeht.
Ich sehe keine Konflikte. Zwei Routen mit unterschiedlicher Metrik sind kein Konflikt, da ist in der Theorie glasklar was zu tun ist.
Diese Logik müsste man kennen.
Die Frage ist eben, welche zusätzliche Logik da noch reinspielt...
Danke, hilft mir aber nicht.
Nein mir auch nicht. Denn die Metrik ist bei einem Router das einzige Kriterium. Bei Windows aber eben nicht, denn dort ist es primär eben die Bindungsreihenfolge. Da aber keiner so richtig weiss WIE diese beiden Parameter dort interagieren was das layer 3 Forwarding anbetrifft bleibt es wohl bei Raterei. 
Bei wechselnden sich ab- und aufbauenenden virtuellen VPN Interfaces ist genau die Bindungsreihenfolge eben kein statischer Wert. Die Metrik ja.
gibt es bei Windows 10 keine separate Bindungsreihenfolge mehr
Kann ich hier nicht bestätigen... Mehrere Laptops mit Creators Update 1709 stoppen sofort das Internet via WLAN (def. Gate) wenn ihnen z.B. von einem testweise aufgesteckten DHCP am LAN Port ein weiteres blindes Default Gateway gleicher Metrik angeboten wird. Statisches Gateway ebenso.Laut deiner Theorie sollte das ja dann nicht passieren. Wäre das Gateway nicht blind müsste Windows ein Session basiertes Balancing machen bei gleicher Metrik. Das passiert bei Windows logischerweise auch nicht.
Mit standartisiertem Verhalten hat das also weniger zu tun, denn irgendwie spielt immer eine Bindungsreihenfolge in die L3 Forwarding Entscheidung mit rein.
da ist in der Theorie glasklar was zu tun ist.
In der Theorie schon. Aber seit wann hält sich MS an bekannte Standards. Mit Netzwerk haben die das ja bekanntermaßen nicht so. Man denke da nur an das Drama mit dem Lastenausgleich (NLB) und anderen Katastrophen.Dort konformes Verhalten zu erwarten ist wohl Utopie.
Nein mir auch nicht. Denn die Metrik ist bei einem Router das einzige Kriterium. Bei Windows aber eben nicht, denn dort ist es primär eben die Bindungsreihenfolge. Da aber keiner so richtig weiss WIE diese beiden Parameter dort interagieren was das layer 3 Forwarding anbetrifft bleibt es wohl bei Raterei.
Bei wechselnden sich ab- und aufbauenenden virtuellen VPN Interfaces ist genau die Bindungsreihenfolge eben kein statischer Wert. Die Metrik ja.
Bei wechselnden sich ab- und aufbauenenden virtuellen VPN Interfaces ist genau die Bindungsreihenfolge eben kein statischer Wert. Die Metrik ja.
Nun, ich rede ja garnicht von ab/aufbauenden Verbindungen. Bei mir passiert das während beide Verbindungen aktiv sind mal für ein paar Sekunden. Selbst wenn die Bindungsreihenfolge unter Windows 10 noch existieren würde, wäre sie in diesem Kontext statisch.
Kann ich hier nicht bestätigen... Mehrere Laptops mit Creators Update 1709 stoppen sofort das Internet via WLAN (def. Gate) wenn ihnen z.B. von einem testweise aufgesteckten DHCP am LAN Port ein weiteres blindes Default Gateway gleicher Metrik angeboten wird. Statisches Gateway ebenso.
Naja, damit belegst du zwar dass es einen Mechanismus abseits der Metrik gibt, nicht aber dass das die Bindungsreihenfolge ist. Dass es diese unter Windows 10 nicht mehr gibt, entnahm ich übrigens https://docs.microsoft.com/en-us/windows-server/networking/technologies/ ... und https://blogs.technet.microsoft.com/networking/2015/08/14/adjusting-the- ...
Laut deiner Theorie sollte das ja dann nicht passieren. Wäre das Gateway nicht blind müsste Windows ein Session basiertes Balancing machen bei gleicher Metrik. Das passiert bei Windows logischerweise auch nicht.
Mit standartisiertem Verhalten hat das also weniger zu tun, denn irgendwie spielt immer eine Bindungsreihenfolge in die L3 Forwarding Entscheidung mit rein.
Mit standartisiertem Verhalten hat das also weniger zu tun, denn irgendwie spielt immer eine Bindungsreihenfolge in die L3 Forwarding Entscheidung mit rein.
Es spielt etwas mit rein, ja. aber garantiert nicht die Bindungsreihenfolge, da die im genannten Szenario nicht existiert und wenn dann statisch wäre.
Ich fasse also zusammen: Bisher kann das Phänomen von euch auch keiner schlüssig erklären ;)
Ich nehme aber trotzdem an, dass Du eine Lösung suchst?
Falls ja: Die Lösung ist unter Windows: Nur genau ein Standard-Gateway.
Falls ja: Die Lösung ist unter Windows: Nur genau ein Standard-Gateway.
Danke für diese offensichtliche Lösung, ich wäre da jetzt nicht drauf gekommen!
Könntest du das bitte auch allen VPN Software Herstellern mitteilen? Wäre echt super
Könntest du das bitte auch allen VPN Software Herstellern mitteilen? Wäre echt super
Könntest du das bitte auch allen VPN Software Herstellern mitteilen? Wäre echt super
Aber gerne doch! Wo soll ich anfangen? 
Aber gerne doch! Wo soll ich anfangen?
ZeroTier wäre nett Das evaluiere ich grade als vielversprechenden Nachfolger für Hamachi 1.x
Mal ernsthaft anders herum betrachtet:
Diese Einstellung des Standard Gateways beim Aufbau einer VPN-Verbindung über Internet von einem Client auf das Gateway des VPN-Tunnels hat auch etwas mit Selbstschutz zu tun. Man will damit i.A. verhindern, dass der Client damit zum "Router" zwischen einem fremden Netz (u.U. gar dem Internet) und dem privaten Netzwerk, in welches das VPN eingewählt ist, wird. Genau so, wie man nicht will, dass ein interner Client parallel zum internen Netzwerk noch unkontrolliert über eine andere Leitung "an der IT vorbei" im Internet hängt.
Wofür braucht dieser Client eigentlich gleich mehrere VPN-Tunnel gleichzeitig? Wäre das nicht besser bei einem entsprechenden Router aufgehoben?
Diese Einstellung des Standard Gateways beim Aufbau einer VPN-Verbindung über Internet von einem Client auf das Gateway des VPN-Tunnels hat auch etwas mit Selbstschutz zu tun. Man will damit i.A. verhindern, dass der Client damit zum "Router" zwischen einem fremden Netz (u.U. gar dem Internet) und dem privaten Netzwerk, in welches das VPN eingewählt ist, wird. Genau so, wie man nicht will, dass ein interner Client parallel zum internen Netzwerk noch unkontrolliert über eine andere Leitung "an der IT vorbei" im Internet hängt.
Wofür braucht dieser Client eigentlich gleich mehrere VPN-Tunnel gleichzeitig? Wäre das nicht besser bei einem entsprechenden Router aufgehoben?
Mal ernsthaft anders herum betrachtet:
Diese Einstellung des Standard Gateways beim Aufbau einer VPN-Verbindung über Internet von einem Client auf das Gateway des VPN-Tunnels hat auch etwas mit Selbstschutz zu tun. Man will damit i.A. verhindern, dass der Client damit zum "Router" zwischen einem fremden Netz (u.U. gar dem Internet) und dem privaten Netzwerk, in welches das VPN eingewählt ist, wird. Genau so, wie man nicht will, dass ein interner Client parallel zum internen Netzwerk noch unkontrolliert über eine andere Leitung "an der IT vorbei" im Internet hängt.
Diese Einstellung des Standard Gateways beim Aufbau einer VPN-Verbindung über Internet von einem Client auf das Gateway des VPN-Tunnels hat auch etwas mit Selbstschutz zu tun. Man will damit i.A. verhindern, dass der Client damit zum "Router" zwischen einem fremden Netz (u.U. gar dem Internet) und dem privaten Netzwerk, in welches das VPN eingewählt ist, wird. Genau so, wie man nicht will, dass ein interner Client parallel zum internen Netzwerk noch unkontrolliert über eine andere Leitung "an der IT vorbei" im Internet hängt.
Hast du dir das ausgedacht, oder hast du dafür Quellen? So ganz verstehe ich das jetzt nicht... Zumindest ein Windows macht Standard-Mäßig niemals Routing
C:\Users\*****>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : Se*******
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Broadcast
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : fritz.boxDas müsste man extra konfigurieren. Zudem müssten dann ausserdem noch PCs des fraglichen Netzwerks Routen auf den PC mit VPN Client konfiguriert haben, denn ich wüsste keinen anderen Grund weshalb der PC mit VPN Client sonst IP Pakete aus dem LAN mit Ziel-Adressen im VPN Netz erhalten sollte. Versehentlich passiert das nicht. Gezielt wäre es aber als Angriffsszenario möglich.
Angenommen Routing wäre auf dem PC aktiv.
Ich sende jetzt dem PC auf dem der VPN Client läuft ein IP Paket mit Ziel im VPN Netz. Der PC würde in diesem Fall das Paket in das VPN routen. Wie genau würde die Default-Route das denn verhindern? Für IP Pakete mit Ziel im VPN Netz greift ohnehin die wesentlich speziellere Route des PCs mit Subnetzmaske des VPN Netzes. Default-Routen sind irrelevant, egal wieviele es gibt.
Wofür braucht dieser Client eigentlich gleich mehrere VPN-Tunnel gleichzeitig? Wäre das nicht besser bei einem entsprechenden Router aufgehoben?
Wer redet von mehreren? Ich habe ein ganz alltägliches Setup: Ich habe einen Windows Laptop den ich mit mir herum trage. Zudem habe ich PCs auf deren Netzlaufwerke ich unterwegs zugreifen können möchte. z.B. ein NAS zuhause und ein PC im Elternhaus.
Ich möchte dass die Zugriffe transparent sind. Mein Laptop, der PC im Elternhaus und das NAS sollen also eine private IP innerhalb eines Peer-2-peer VPNs erhalten und über diese IP kann ich dann, völlig egal wo ich mich befinde, auf die Freigaben zugreifen.
Das ganze hat vor 10 Jahren mit Hamachi 1.x super funktioniert. Die Software wurde auf den drei Geräten installiert, alle traten dem selben virtuellen Netzwerk bei und schon hatten alle mit fixen privaten (nicht gaz privaten 5.0.0.0/8) IPs aufeinander Zugriff. Die Software lief als Dienst permanent im Hintergrund.
Selbiges kann und soll nun ZeroTier tun. Und das tut es auch. Aber es provisioniert eben auch auf allen drei Geräten einen Default-Gateway im virtuellen Netz.
Ich habe jetzt keine Quelle zur Hand, aber ausgedacht habe ich mir das nicht. Das ist mir vor Jahren schon "über den Weg gelaufen".
Es muss kein Routing sein. Proxy geht auch. Man stelle sich vor, der Client ist infiziert. Jemand kann sich draufschalten, wenn der Client im Internet ist. Wenn der Client Verbindung zu einem Netzwerk hat, dann kann man den Client u.U. als Bastion Host benutzen und sich in dieses Netzwerk weiterhangeln.
Wenn beim Aufbau des VPN durch das Setzen des VPN Standard Gateways an erster Stelle erfolgt, dann würde der Client seine "normale" Kommunikation mit dem Internet verlieren. Ein Externer könnte also nicht gleichzeitig von außen initiert auf den Client zugreifen und sich in das VPN hinein weiterhangeln.
Habe soeben bei Mutti etwas gefunden:
You Cannot Connect to the Internet After You Connect to a VPN Server
Das bezieht sich zwar noch auf Win2000 und NT4 aber es gilt sicher immer noch.
Und hier noch ein Beispiel:
Can’t connect to Internet while VPN is connected
Es muss kein Routing sein. Proxy geht auch. Man stelle sich vor, der Client ist infiziert. Jemand kann sich draufschalten, wenn der Client im Internet ist. Wenn der Client Verbindung zu einem Netzwerk hat, dann kann man den Client u.U. als Bastion Host benutzen und sich in dieses Netzwerk weiterhangeln.
Wenn beim Aufbau des VPN durch das Setzen des VPN Standard Gateways an erster Stelle erfolgt, dann würde der Client seine "normale" Kommunikation mit dem Internet verlieren. Ein Externer könnte also nicht gleichzeitig von außen initiert auf den Client zugreifen und sich in das VPN hinein weiterhangeln.
Habe soeben bei Mutti etwas gefunden:
You Cannot Connect to the Internet After You Connect to a VPN Server
Das bezieht sich zwar noch auf Win2000 und NT4 aber es gilt sicher immer noch.
Und hier noch ein Beispiel:
Can’t connect to Internet while VPN is connected
Wenn beim Aufbau des VPN durch das Setzen des VPN Standard Gateways an erster Stelle erfolgt, dann würde der Client seine "normale" Kommunikation mit dem Internet verlieren. Ein Externer könnte also nicht gleichzeitig von außen initiert auf den Client zugreifen und sich in das VPN hinein weiterhangeln.
Okay ja verstehe. Setzt aber auch voraus dass die VPN Software den bisherigen Default-Gateway aktiv löscht...
Aber das ist in meinem Fall ja nicht gewünscht. Das VPN soll ja nur zum Zugriff auf das VPN Subnetz verwendet werden und das lokale LAN und das Internet soll weiterhin funktionieren.
Dass mein PC dadurch als Proxy missbraucht werden kann, Schadsoftware oder sowas wie XSRF vorausgesetzt, ist mir klar.
