Novgorod
ngb-Nutte
- Registriert
- 14 Juli 2013
- Beiträge
- 3.055
auf einem win10-rechner (x64 edu) läuft ein openVPN server mit einer sehr simplen config, nämlich 1. netzwerkverbindung zwischen server und allen clients im VPN (10.8.0.x netz) und 2. routen bzw. NAT des gesamten internettraffics der clients über den server.. für letzteres wird die internetverbindungsfreigabe von windows benutzt, d.h. der ethernet-port (der aufs internet zugreift) ist mit dem virtuellen openVPN adapter "geshared".. es läuft auch soweit problemlos, sobald alles eingerichtet ist, nur muss ich die einrichtung nach jedem neustart des win10-rechners mit dem openVPN server wiederholen und zwar wie folgt:
1. direkt nach dem neustart schaut die netzwerk-config so aus:
der openVPN-adapter hat automatische IP-config und ein manuell eingestelltes fake-gateway (10.8.0.254), damit das openVPN-netzwerk als ein "privates" (statt "unbekanntes") netzwerk erkannt wird und die firewall nicht meckert.. "Ethernet" ist der LAN-anschluss mit dem internetzugang (geshared für den openVPN-adapter) und die VMware adapter sollten keine rolle spielen.. im screenshot ist der openVPN-server selbst noch nicht verbunden, daher das rote x..
2. ich verbinde den server manuell über die openVPN-GUI, das rote x verschwindet und der client kann sich mit dem VPN verbinden.. nun kommt das problem: das VPN läuft zwar (der client kann den server unter 10.8.0.1 erreichen), der internettraffic des clients wird aber nicht geNATet, obwohl die freigabe am server ja eigentlich eingeschaltet ist..
3. aus irgendeinem grund muss ich nun die internetverbindungsfreigabe aus- und wieder einschalten:
nach diesem schritt ist jedoch noch nichts gelöst und nun lässt sich nicht einmal mehr der server (10.8.0.1) vom client aus pingen ..
4. den grund dafür sieht man, wenn man wieder in die IP-config des openVPN-adapters schaut:
WTF!? warum wurde durch das aus- und einschalten der internetverbindungsfreigabe die IP des openVPN-adapters auf manuell gesetzt und zudem noch mit irgendeiner generischen 192.168.x.x adresse??
5. ich stelle die IP-config des openVPN-adapters wieder exakt so ein wie in schritt 1 (inkl. fake-gateway) und voilà - der client kann wieder den server (10.8.0.1) erreichen UND sein internettraffic wird endlich ordnungsgemäß über den server geleitet.. all das geschah wohlgemerkt, ohne dass sich der server oder der client per openVPN neu verbinden musste (seit schritt 2)..
ich kann nicht ausschließen, dass openVPN für diesen bug verantwortlich ist, aber es deutet alles eher auf windows hin.. das problem entsteht ja erst dadurch, dass die internetverbindungsfreigabe nach einem systemneustart nicht funktioniert, obwohl sie aktiviert ist.. vielleicht liegt es daran, dass der openVPN-adapter gleich nach dem booten noch nicht verbunden ist (rotes x) - aaaber: wenn ich die openVPN-verbindung des servers manuell disconnecte (-> rotex x erscheint am openVPN-adapter) und wieder connecte, funktioniert alles einwandfrei, d.h. die internetverbindungsfreigabe bleibt ordnungsgemäß bestehen, somit tritt das problem offenbar nur beim ersten mal nach dem neustart auf ..
hat jemand eine idee, was das problem sein könnte und wie man die internetverbindungsfreigabe dazu bekommt, gleich nach dem neustart zu funktionieren UND beim aus-/einschalten dieser die IP-config des openVPN-adapters nicht zu zerschießen?
1. direkt nach dem neustart schaut die netzwerk-config so aus:
der openVPN-adapter hat automatische IP-config und ein manuell eingestelltes fake-gateway (10.8.0.254), damit das openVPN-netzwerk als ein "privates" (statt "unbekanntes") netzwerk erkannt wird und die firewall nicht meckert.. "Ethernet" ist der LAN-anschluss mit dem internetzugang (geshared für den openVPN-adapter) und die VMware adapter sollten keine rolle spielen.. im screenshot ist der openVPN-server selbst noch nicht verbunden, daher das rote x..
2. ich verbinde den server manuell über die openVPN-GUI, das rote x verschwindet und der client kann sich mit dem VPN verbinden.. nun kommt das problem: das VPN läuft zwar (der client kann den server unter 10.8.0.1 erreichen), der internettraffic des clients wird aber nicht geNATet, obwohl die freigabe am server ja eigentlich eingeschaltet ist..
3. aus irgendeinem grund muss ich nun die internetverbindungsfreigabe aus- und wieder einschalten:
nach diesem schritt ist jedoch noch nichts gelöst und nun lässt sich nicht einmal mehr der server (10.8.0.1) vom client aus pingen ..
4. den grund dafür sieht man, wenn man wieder in die IP-config des openVPN-adapters schaut:
WTF!? warum wurde durch das aus- und einschalten der internetverbindungsfreigabe die IP des openVPN-adapters auf manuell gesetzt und zudem noch mit irgendeiner generischen 192.168.x.x adresse??
5. ich stelle die IP-config des openVPN-adapters wieder exakt so ein wie in schritt 1 (inkl. fake-gateway) und voilà - der client kann wieder den server (10.8.0.1) erreichen UND sein internettraffic wird endlich ordnungsgemäß über den server geleitet.. all das geschah wohlgemerkt, ohne dass sich der server oder der client per openVPN neu verbinden musste (seit schritt 2)..
ich kann nicht ausschließen, dass openVPN für diesen bug verantwortlich ist, aber es deutet alles eher auf windows hin.. das problem entsteht ja erst dadurch, dass die internetverbindungsfreigabe nach einem systemneustart nicht funktioniert, obwohl sie aktiviert ist.. vielleicht liegt es daran, dass der openVPN-adapter gleich nach dem booten noch nicht verbunden ist (rotes x) - aaaber: wenn ich die openVPN-verbindung des servers manuell disconnecte (-> rotex x erscheint am openVPN-adapter) und wieder connecte, funktioniert alles einwandfrei, d.h. die internetverbindungsfreigabe bleibt ordnungsgemäß bestehen, somit tritt das problem offenbar nur beim ersten mal nach dem neustart auf ..
hat jemand eine idee, was das problem sein könnte und wie man die internetverbindungsfreigabe dazu bekommt, gleich nach dem neustart zu funktionieren UND beim aus-/einschalten dieser die IP-config des openVPN-adapters nicht zu zerschießen?