Benutzer gehen über VPN auf die Synology können aber keine Laufwerke mappen

[Typ_aus_Berlin]

Hi Leute,

Konfi ist unten im Fuß, ich brauche dringend Hilfe, am Montag steht die ganze Firma!

Wir haben einen neuen Standort bezogen und damit einen neuen Telekom Anschluß mit fester IP. Die Synology ist vom alten Standort an den neuen mit umgezogen. Die Benutzer waren am alten Standort per VPN-Server mit OpenVPN im System, konnten Netzwerklaufwerke mappen, alles war bestens.

Wir kommen jetzt am neuen Standort von außen auf die Fritzbox und mittels der festen IP auch auf die DSM Oberfläche, können die Synology über diesen Weg konfigurieren usw., dieser Weg funzt bestens. Der VPN-Server wurde gelöscht und neu aufgesetzt, damit die aktuellen Daten im VPN-Server auch aktiv werden.

Wenn ein Benutzer jetzt über den neu konfigurierten VPN-Server auf die Synology geht, bekommt er vom DHCP auf der Synology eine IP-Adresse XXX.XXX.3.XXX, der Benutzer erhält seine Daten vom AD und ist in der Synology. Er ist im VPN-Server sichtbar.

Wir haben den Firewall in der Synology ausgeschaltet, auf Grund der nachfolgend beschriebenen Probleme.

Der im VPN befindliche AD Benutzer, kann jedoch keine Laufwerke der Synolgy mappen, bzw. nicht einmal die interne IP-Adresse (XXX.XXX.1.10) der Synology pingen.

Wir haben überlegt ob der AD eine Macke hat, haben den VPN-Server neu aufgesetzt für die internen Benutzer der Synology. Um alle evtl. Berechtigungsprobleme auszuschalten, haben wir den Zugang mittel Synology Admin auf den VPN-Server gestartet, der Admin kommt auf den VPN-Server ist auch sichtbar und kann auch nicht die Synology auf der internen IP-Adresse anpingen, bzw. die Laufwerke der Sysnology mappen.

Im lokalen Netz ist alles OK, ich kann mit einem AD-Benutzer und/oder mit einem Synology Benutzer die interne Adresse der Synology pingen und alle Netzwerklaufwerke mappen.

Uns sind die Optionen ausgegangen und alle Benutzer der Firma kommen am Montag nicht an Ihre Laufwerke, ich glaube das gibt Ärger....

Bin um jeden Tipp dankbar und bedanke mich schon im Voraus.

 

[bastians]

Ich würde mal ein traceroute (bzw. tracert, wenn Windows) vom VPN Client zur (internen) IP der Synology und umgekehrt von der Synology zur internen IP des VPN Client machen. Vielleicht stimmt das Routing irgendwo nicht. Mit ping sieht man ja nur, dass es nicht geht, aber nicht wo es hakt.

 

[Typ_aus_Berlin]

Das werd ich gleich mal machen, danke

 

[Typ_aus_Berlin]

Wir haben zum testen das VPN-Server Netz auf XXX.XXX.2.0 (war auf XXX.XXX.3.0) geändert und sehen beim trace folgendes:

Gegeben:
VPN per domain user
VPN Netz ist das XXX.XXX.2.0
Synology hat feste IP XXX.XXX.1.10
AD sitzt auf der Synology mit fester IP XXX.XXX.1.10

Die in der Synology freigegebenen Ordner aufrufbar nur per VPN-Netzwerk XXX.XXX.2.1 statt der festen IP XXX.XXX.1.10

VPN-Clients haben keine Verbindung zum AD (gpupdate /force schlägt fehl)

Hosts-Datei so angepasst, dass der Synology-Hostname auf die XXX.XXX.2.1 gemappt ist.

Versuche ich, die Network-Shares, statt per IP (\\XXX.XXX.2.1\Ordner) per Namen aufzurufen (\\Synology-Hostname\Ordner) , dann werde ich nach einem Login gefragt.

Wenn ich die Benutzer-Credentials nutze, mit denen ich mich bereits im VPN angemeldet habe, dann erhalte ich Zugang zum \\Synology-Hostname\Ordner

Rufe den gleichen Share über IP auf, benötige ich kein zusätzliches Login.

 

[blurrrr]

Konfi ist unten im Fuß, ich brauche dringend Hilfe, am Montag steht die ganze Firma!

Uns sind die Optionen ausgegangen und alle Benutzer der Firma kommen am Montag nicht an Ihre Laufwerke, ich glaube das gibt Ärger....

Wir haben zum testen das VPN-Server Netz auf XXX.XXX.2.0 (war auf XXX.XXX.3.0) geändert

VPN-Clients haben keine Verbindung zum AD

Hosts-Datei so angepasst

Wir haben überlegt ob der AD eine Macke hat

haben den VPN-Server neu aufgesetzt

usw.....

Ich frage mal ganz blöd: Was zum Geier(!) soll ein physikalischer Umzug mit der internen Netzwerk-Config zu tun haben, ausser genau "garnichts"?

Denke der Umzug ist vermutlich schlimmstmöglich gelaufen und sicherlich, nachdem man alles mögliche platt gemacht hat (warum?!), kann man sicherlich auch das AD platt machen (wenn man sonst nix im Leben zu tun hat und ansonsten eh schon alles grandios daneben gelaufen ist). Planloses rumfummeln war schon immer der beste Plan ever...

"Vernünftig" wäre es dann so gelaufen: Alles ordnungsgemäß runterfahren, rüberschaffen, wieder in der richtigen Reihenfolge hochfahren, "fertig". Wenn sich der Router ändert, ändert sich nicht automatisch das Netz (sowas wäre einfach nur ohne Sinn und Verstand), sondern der Router wird an die Gegebenheiten angepasst. VPN-Einwahl wird auch nicht auf eine IP, sondern im besten Fall auf einen FQDN gesetzt, dann kann man das ganze dann einfach auf die neue öffentliche IP anpassen und "ist durch" mit dem Umzug.

Ich fass mal kurz zusammen: "Irgendwer" (ihr nämlich mit Sicherheit nicht, oder nichtmals ansatzweise kapiert was gemacht wird) hat euch das so dahin gestellt, da "irgendwer" halt Geld kostet, hat man sich gedacht, dass man das "bisschen" doch einfach selbst machen kann. Daraufhin wurde dann "irgendwie" rumgefummelt und nu ist alles hin, weil ihr das einfach nicht auf die Kette bekommt. Mir wurden zwar Ratschläge in diese Richtung mehr oder minder untersagt, aber vielleicht wäre es doch sinnvoll (in Anbetracht der Zeit....*auf die Uhr guck* ), wenn man sich doch mal wen mit entsprechender Expertise ins Haus holt (was so kurzfristig auf einen Montag dann vermutlich auch etwas problematisch werden könnte).

An einem Sonntag in einem Forum voller Privatleute nach Lösungen für den Betrieb seiner Firma zu fragen (nachdem man alles völlig verzockt hat), ist dann doch eher eine "fragwürdige" Praxis.

Also kurzum und für meine Verhältnisse dann vermutlich doch noch recht "blumig" ausgedrückt: Ihr habt es schlichtweg verkackt. (sorry, aber so isset)

Auf der anderen Seite... ich bin auch kein Unmensch, von daher frage ich jetzt erstmal ein paar Dinge ab (sofern genehm) und dann sieht man mal weiter... Den ganzen Spass mit gpupdate und Co kannst Du Dir zunächst erstmal völlig knicken, denn das sind Themen die im OSI-Layer viel weiter oben angesiedelt sind und solange es mit den unteren Schichten schon nicht klappt, brauchst Du Dir um alles andere auch gar keine Gedanken machen. Somit geht es auch erstmal um 2-3 Themen:

1) Routing

(s. #2 von @bastians und das bitte nicht(!) mit einem "geänderten" Netz, sondern "genau so" wie es sein soll - es soll nicht mit einem Testnetz laufen, sondern so, wie es sein soll bzw. wie es vorher war). Bevor das Thema nicht durch ist, bringt auch alles andere nichts.

Die in der Synology freigegebenen Ordner aufrufbar nur per VPN-Netzwerk XXX.XXX.2.1 statt der festen IP XXX.XXX.1.10

Da fehlt dann wohl ein Haken beim VPN-Server... (dort mal nach "LAN-Zugriff erlauben" suchen, dann sollte auch die Route für das entsprechende Netz an die Clients mitgegeben werden). Dann sollten die VPN-Clients auch wieder mit dem LAN sprechen dürfen. Soviel dann erstmal zum Thema Routing...

2) Firewall

Es wird wohl alles "korrekt" konfiguriert gewesen "sein", bis jemand mit der Axt kam und völliger Panik und Verzweiflung alles kurz und klein gekloppt hat. Prost Mahlzeit!... Ebenso bedingt durch Dinge wie "neues Testnetz" und "alles platt gemacht" etc. kann es nun gut sein, dass Firewall-technisch (u.a. ggf. auch am AD selbst! ) nun die Dinge etwas "verzockt" sind (deswegen auch besser altes, als neues Netz nutzen - damit besteht zumindestens die Möglichkeit, dass auch auf dem AD die bestehenden Firewall-Regeln noch vernünftig mit dem alten Netz funktionieren).

3) DNS

Dazu liegt die Vermutung nahe, dass - alles andere wäre auch blödsinnig - der richtige DNS-Server nicht übergeben wird (das Gefummel in der Hosts-Datei ist übrigens völliger Blödsinn und sowas hat auch nichts in Firmennetzwerken verloren (sorry, weniger blumig, dafür ehrlich ?)). Normalerweise gibt es die Möglichkeit via VPN-Einwahl ebenso einen zu nutzenden DNS-Server anzugeben. Das wäre in eurem Fall dann schlichtweg der DC (Domänencontroller -> AD). Um Fehler zu vermeiden, sollte die Hosts-Datei dann auch entsprechend bereinigt werden.

So, dann lass mal knacken, ich bin jedenfalls noch ein wenig hier... Rechnung schick ich euch dann später ?

EDIT: So rein aus Interesse.... Um wieviele User handelt es sich denn? Wenn es Anschiss gibt, muss es sich ja auch richtig lohnen... ?

 

[mockri]

Ich hab zwar eigentlich keinen Plan von Netzwerktechnik, aber wenn ich lese, VPN Server neu aufgesetzt und Fritzbox, kommt mir als erstes der Gedanke, ist die Route in der Fritte (unter Heimnetz / Netzwerk / Netzwerkeinstellungen / Statische Routingtabelle) auf das Netz des VPN Servers gesetzt?

 

[Thonav]

D.h. wenn der Router z.b. die 192.168.178.1 hat, müsste diese Adresse unter statische Routingtabelle eingetragen werden?

 

[blurrrr]

Nette Idee, bringt aber erstmal nix, wenn man die Syno unter ihrer "internen" IP anspricht (die kennt nämlich die Routen in beide Netze)

@Thonav Jeder "Router" im Netz sollte die entsprechenden "Routen" in die anderen vorhanden Netze kennen (Rest regelt dann einfach die Firewall).

 

[Thonav]

Danke blurrrr - ich bin z.b. mit einer meiner FritzBoxen per VPN (läuft auf der Fritz, nicht auf einer Synology) verbunden, kann aber per VPN nicht auf die Netzwerk-Geräte hinter diesem Router zugreifen. Z.b. habe in in dem Netzwerk einen Raspberry Pi, den ich gerne von ausserhalb per VPN und der IP Adresse des Pi´s aufrufen möchte.
Keine Ahnung was ich da einstellen muss...

 

[blurrrr]

Nachdem jetzt schon knapp 3 Stunden nix mehr gekommen ist, hat man sich entweder in Eigenbrödelei vertieft und/oder hat sich damit abgefunden, dass dann Montag nix funktioniert, denn ansonsten wäre hier wohl schneller eine Reaktion gekommen. Denke mal, dass das Thema hier dann auch erledigt sein dürfte ??

 

[Typ_aus_Berlin]

Hi Leute,

@ Blurrr vielen Dank für Deine ausführlichen Kommentare, aber keine Sorge, wir gehören doch zu den Profis, auch wenn wir offensichtlich bei Dir nicht einen solchen Eindruck hinterlassen haben.

Selbstverständlich haben wir den Umzug komplett geplant, aber jeder Plan kann auch mal schief gehen, wir haben natürlich auch die Synology ordnungsgemäß runtergefahren und am neuen Standort wieder so wie sie war im neuen Netz gestartet, Der öffentliche DNS hat auch auf der richtigen IP aufgelöst und die Synology war von außen komplett erreichbar. Die FritzBox hat natürlich den Port auf den VPN-Server erhalten und wie in meinem Eingangsthread dargelegt, keiner kam per VPN auf den Server. Die VPN und der DMS Zugang über 443 sind die einzigen Portöffnungen in der FritzBox. Es war sogar so irre, das die Benutzer die im lokalen Netz mit der Synology gearbeitet haben nicht auf die Synology Laufwerke kamen und nichts mappen konnten.

Das man ab dieser Stelle jetzt natürlich alles erdenkliche testen muss ist wohl obsolet, das erste war der Firewall der Synology (dessen Daten wir selbst erstellt hatten) der Einfachheit halber ausschalten und siehe da, die internen Benutzer kamen an die Laufwerke (ein Problem weg). Die externen Benutzer kamen mittels VPN (lief vorher einwandfrei) nicht auf die Synology, also VPN neu installiert und konfiguriert und natürlich auf die Netzlaufwerke frei gegeben, die Benutzer kamen auf die Synology und konnten keine Laufwerke mappen. Dann ahben wir um evtl. Probleme auszuklammern die VPN Verbindung für die internen Benutzer der Synology neu aufgebaut, kamen einwandfrei rein, konnten jedoch auch keine Laufwerke mappen.

Wir haben durch traces festgestellt, dass die Benutzer über VPN (VPN Netz= XXX.XXX.2.1 in der Synology) auf der IP XXX.XXX.2.2 in das System gekommen sind und konnten über diese Adresse die Laufwerke der Synology mappen. Das klappte mit den internen Benutzern wie auch mit den AD Benutzern. Im DNS Server haben wir die IP6 Adressen auf die neue Adresse geändert, was aber auch keine Änderung gebracht hat.

Ergebnis: wir mappen die Laufwerke über die IP XXX.XXX.2.2, haben die Host Datei in der Originalversion zurück geändert und müssen jetzt lediglich beim mappen der Laufwerke nochmal den AD Benutzer mit Kennwort eingeben und alles ist schick, aber nicht richtig.

Im Grunde fehlt uns auf den VPN Server eine reverse lookup zone die wiederum auf die IP XXX.XXX.1.10 auflöst, da haben wir bisher keine Lösung.

Aber wie ich sehe, haben andere auch so ein Problem wie wir, na ob das mal nicht doch ein Bug ist??

 

[blurrrr]

wir gehören doch zu den Profis

Ich sag mal... "Profi" ist dann wohl ein sehr weiter Begriff..., denn:

fehlt uns auf den VPN Server eine reverse lookup zone die wiederum auf die IP XXX.XXX.1.10 auflöst, da haben wir bisher keine Lösung.

... Wenn ihr ein AD laufen habt, läuft auch ein DNS-Server und da gibt es "immer" die Möglichkeit, dass man eine reverse-lookup-Zone erstellt und entsprechende PTR-Records setzen (lassen) kann. Da wir uns wohl nicht ganz verstanden haben, kann ich es gern nochmal sagen: Wenn das Routing funktioniert und die Firewall-Regeln passen, kann man dem VPN-Client den DC als DNS-Server mitgeben und kann am DC ganz einfach seine Zonen pflegen.

EDIT: Ich hab mir das ganze jetzt nochmal durchgelesen und sorry... "Profis" wissen auch was ein traceroute ist, also ich denke... sorry, aber das mit den "Profis" lassen wir vllt mal besser nicht so stehen... (zumindestens auf den Admin-Job bezogen)

 

[Typ_aus_Berlin]

Danke für Deine Info blurrrr, die Debatte bzgl. der Profis ist müssig und sollten wir einfach lassen, gehört eigentlich auch gar nicht hierher. Da das Problem offensichtlich schon öfter aufgetreten ist, sollten wir hier lösungsorientiert schreiben, damit andere zukünftig wissen was zu tun ist.

Wir haben durch den Zugang auf die IP XXX.XXX.2.1 das Problem erstmal vom Tisch, alle Benutzer kamen ins System und heute Abend werden wir uns an die Routen bzw. an die DNS Einträge machen und die "richtige" Lösung weiter suchen, im Laufenden Betrieb machen wir solche Arbeiten nicht, daher haben wir bis jetzt hierfür noch keine Lösung die wir publizieren könnten. Das es nur in die Richtung gehen kann ist soweit klar, was mich aber stört, wir haben vor längerer Zeit am alten Standort die VPN Zugänge eingerichtet, ganz nach Standard Vorgabe, ohne irgendwelche speziellen Konfigurationen und alles war bestens, moven das Teil einfach nur von einer Adresse zur nächsten, ohne irgend etwas zu verändern und haben solch gigantischen Probleme. Da wäre mal ein guter Kommentar hilfreich, was könnte das verursacht haben.

Ich denke wenn wir den DNS bearbeitet haben ist das Problem weg, aber wie ist es überhaupt entstanden?? Wir haben keine DNS Korrekturen seinerzeit gemacht, als wir das erste Mal eine VPN Verbindung generiert haben (die ja auch einwandfrei lief), wieso ist jetzt überhaupt eine nötig, hier liegt doch der dickste Wurm im System. Ich werde weiter suchen um das Entstehen der Probleme zu finden...., mal sehen, vielleicht hast Du noch ein paar Ideen, was das alles verursacht haben könnte.

 

[blurrrr]

Ja nu, sorry, aber wenn man irgendwo ordnungsgemäß runterfährt, es woanders hinstellt, wieder einschaltet und es nicht mehr funktioniert, dann war schon vorher was nicht korrekt, weil "einfach so" ist es recht unwahrscheinlich, dass so ganz "spontan" etwas nicht mehr funktioniert, was vorher ewig funktioniert hat (ausser bei Hardware-Defekten o.ä.). Unter uns: sowas habe ich noch "nie"(!) erlebt (und ich mach sowas schon etwas länger...).

Der VPN-Server wurde gelöscht und neu aufgesetzt, damit die aktuellen Daten im VPN-Server auch aktiv werden.

Ist z.B. so ein Punkt, welchen ich überhaupt nicht nachvollziehen kann. Das Ding lief, das Ding wäre auch am neuen Standort völlig problemlos weitergelaufen, warum fummelt man da rum? Was für "aktuelle Daten"? Ihr habt doch "nur" den Standort gewechselt? Bedeutet doch nur - im Falle eines neuen Routers - neuen Router an die Gegebenheiten anpassen. Falls kein neuer Router: ggf. DSL-Einwahldaten anpassen und fertig?

 

[Typ_aus_Berlin]

Das mit dem neuen VPN-Server lässt sich einfach erklären: Durch die neue öffentliche IP war auch ein neues Zertifikat erforderlich und selbiges ist dann auch für die VPN Benutzer erforderlich, daher haben wir den Zugang erneuert und dadurch die neuen Konfigurationsdaten für die VPN Benutzer erstellen können, Problem gelöst, die Benutzer kamen nach dieser Änderung wenigstens wieder auf die Synology. Wie schon mehrfach gesagt, leider ohne Laufwerk-Mapping.

Das sich durch die Umstellung auf eine neue Adresse in der Synology nichts ändert, ist auch in Sachen IP Konfi nicht ganz richtig, da sich die IPV6 Adressen ändern, sobald man ein neues Netz aufbaut. OK das haben wir durch die manuelle Eingabe im DNS mit den richtigen IPV6 Adressen für die beiden Netzanschlüsse der Synology recht schnell behoben, hatte allerdings auch keinen Effekt

Du siehst wir haben da einige "Macken" im System gefunden, die eine zusätzliche Maßnahme oder besser gesagt, eine Änderung in der Synology erforderlich gemacht haben.

Das schon vorher ein Problem in der Synology war, ist natürlich nicht abwegig, aber allein die Tatsache, dass die Kiste seit zwei Jahren problemlos läuft spricht da schon dagegen. In der Zeit haben wir viele Ergänzungen gemacht, bzgl. Docker mit virtuellen Maschinen, Chat System und noch so verschiedene Installationen, alles lief die ganze Zeit ohne Probleme.... und dann kam der Umzug...........

Nun zu den nächsten Erkenntnissen, leider kann ich im DNS-Server keine sinnvollen Einträge vornehmen um dort evtl. auf die XXX.XXX1.10 zu loopen, das war etwas einfach gedacht, da müsste man tiefer einsteigen, was ich aber nicht machen werde, da, selbst wenn es geklappt hätte, dieser Weg ja auch nur von hinten durch die Brust ins Auge geht .

Wir suchen weiter nach einer Lösung und der Ursache... hoffentlich nicht the never ending story

 

[blurrrr]

Durch die neue öffentliche IP war auch ein neues Zertifikat erforderlich

Weil? Kein FQDN im Zertifikat angegeben war, oder was? ?

Also sorry, aber das mit der "vernünftigen" Darlegung des Sachverhaltes hast Du es echt nicht drauf... Den Unterschied zwischen:

XXX.XXX.1.10

und

da sich die IPV6 Adressen ändern

haste jetzt schon irgendwie bemerkt, oder? Du hast "die ganze Zeit" nur und ausschliesslich von IPv4 gesprochen und JETZT(!) kommste mit IPv6 um die Ecke?!

Ich bin dann mal raus - ihr lebt wohl in einer anderen Welt als ich.... Also sag ich mal: Alles gute und viel Erfolg bei der weiteren Suche nach einer Lösung und so! ??

 

[Typ_aus_Berlin]

Das mit dem FQDN ist nur teilweise richtig, Wenn auf demselben Server mehrere Webseiten mit ihren jeweils zugeordneten SSL-Zertifikaten gehostet werden, muss jede Website eine eindeutige IP haben, um zu gewährleisten, dass der Webserver weiss, für welche Domain die SSL-Verbindung bestimmt ist. Wenn nur eine einzige Domain gehostet wird, kann man Namen-basiertes Hosting anwenden. Wenn jedoch mehrere Domains auf demselben Server gehostet werden muss IP-basiertes Hosting angewendet werden.

Im DNS Server haben wir die IP6 Adressen auf die neue Adresse geändert, was aber auch keine Änderung gebracht hat.

In meinem Threat 11 habe ich schon die IP6 angesprochen, im Übrigen kann man mit der IP6 im VPN Server nicht viel anfangen, daher war das jetzt auch nicht unbedingt das primäre Thema, ledigleich im DNS Server sind die Verweise auf die IP6 vorhanden und die haben wir auf die neue Adresse geändert, hätte ja was bringen können.

Du kannst ja echt gut meckern und um Dich schlagen, wie wäre es mal mit was konstruktivem? Bisher habe ich von Dir noch nicht viel konstruktives gelesen, schade eigentlich....

 

[Typ_aus_Berlin]

Nun mal weiter im Text:
Wir konnten alle zuvor genannten Problem nicht lokalisieren, daher haben wir die Synology auf Werkseinstellung zurückgesetzt und neu installiert mit genau der bisherigen Konfiguration (nicht zurück geladen) sondern manuell konfigurert und siehe da, alle Probleme weg.

Entweder hat die Büchse einen internen Bug, wäre mal eine Stellungnahme von Synology wert, oder ?????

Naja egal, vielleicht findet ja mal ein anderer die Ursache und setzt diesen Threat fort

 

[blurrrr]

Wenn auf demselben Server mehrere Webseiten mit ihren jeweils zugeordneten SSL-Zertifikaten gehostet werden, muss jede Website eine eindeutige IP haben, um zu gewährleisten, dass der Webserver weiss, für welche Domain die SSL-Verbindung bestimmt ist

Was ist das bitte für eine Aussage (die mal VÖLLIG daneben ist)? (nebenbei - hier werden im Nebengeschäft auch Webseiten gehostet, aber nicht auf so einer gummeligen Syno und auch nicht über irgendeinen einen Reselleraccount wie es die Agenturen gerne machen, also versuchst Du hier grade definitiv dem falschen das Schnitzel an die Backe zu werfen ?)

im Übrigen kann man mit der IP6 im VPN Server nicht viel anfangen, daher war das jetzt auch nicht unbedingt das primäre Thema, ledigleich im DNS Server sind die Verweise auf die IP6 vorhanden und die haben wir auf die neue Adresse geändert, hätte ja was bringen können.

Zweite mal völlig daneben... Wenn der Client via VPN eine "IPv4" bekommt und Du durch das VPN ein IPv6-Ziel ansprechen willst... na jetzt rate mal, was NICHT funktionieren würde... ("Profi-Runde Nr 2"....) IPv4 und IPv6 können nicht "einfach so" direkt miteinander sprechen... also "hätte ja was bringen können" -> NEIN, hätte es nicht, kann es nicht und wird es nicht (jedenfalls nicht, ohne etwas dazwischen).

Konstruktiv war ich schon, hast Du nur völlig ignoriert und teils vermutlich einfach garnicht verstanden (was meine beiden letzten Zitate auch voll bestätigen). Das ist eigentlich ganz einfach:

a) Du gibst offen zu, dass Du einfach NULL Plan hast (ausser 3 bunte Knöpfe zu drücken), was völlig in Ordnung ist, da man dann auch entsprechend mit Dir umgehen kann (sprachlich, als auch informativ).

b) Du bleibst bei "Ich bin voll der Netzwerk-Guru" und wirst 1) entsprechend behandelt, also werden Dir die Sachen nur so um die Ohren fliegen (weil Du sie nicht verstehst) und 2) wird man Dir sehr schnell auf die Schliche kommen und Dich dann auch entsprechend behandeln (s. Status jetzt).

Allerdings entstehen bei Variante B eben entsprechend unnötige Reibungen (wie wir das ja jetzt schon mehrfach hier hatten). In Zukunft vielleicht einfach besser direkt Klartext und so ...

Was das eigentliche Problem angeht: Du warst zu schnell... ohne Plan einfach direkt losfummeln ist meist nicht so die geilste Idee. Anfangen bist Du hier mit dem ersten Post:

Der VPN-Server wurde gelöscht und neu aufgesetzt, damit die aktuellen Daten im VPN-Server auch aktiv werden.

Das ist meiner Meinung nach schon totaler Murks gewesen, denn da hätte man schon weit vorher nach dem eigentlichen Problem suchen sollen. Mir ist schon klar, dass einem sowas als Laie (und sorry, so ist es - zumindestens in diesem Bereich und es ist auch nicht in irgendeiner Art negativ gemeint) nicht einfach dann dahinter zu steigen, aber ich hätte bis dahin ein relativ simples Problem vermutet, denn alles was man so im ersten Post gelesen hat, hat lediglich darauf hingedeutet, dass die VPN-User nicht über ins eigentliche LAN gekommen sind (das umfasst halt auch SMB/CIFS, DNS und das AD). Somit blieben theoretisch nur falsche IP-Infos, Routing (inkl. VPN), Firewall und dann ist eigentlich auch schon Ende. Selbst falsche Routen beim VPN-Dienst sind kein Grund dafür, dass Ding in Grund und Boden zu stampfen, sowas kann man auch einfach anpassen.

Leider wird man hier aber keine Lösung mehr finden, da das Problem ja mittlerweile eher "vom Winde verweht" scheint... ausser natürlich (das kann ich mir nun leider nicht verkneifen, sorry)... ihr zieht nochmal um ??

P.S.: Wenn es um's Auto "fahren" geht, bin ich bestimmt auch nicht so ungeschickt, was aber alles unter der Haube angeht, da bin ich dann der Voll-Laie (vermutlich wäre ich sogar auch (fast) zu doof eine Glühbirne zu wechseln) ?

 

[synfor]

Wenn auf demselben Server mehrere Webseiten mit ihren jeweils zugeordneten SSL-Zertifikaten gehostet werden, muss jede Website eine eindeutige IP haben, um zu gewährleisten, dass der Webserver weiss, für welche Domain die SSL-Verbindung bestimmt ist. Wenn nur eine einzige Domain gehostet wird, kann man Namen-basiertes Hosting anwenden. Wenn jedoch mehrere Domains auf demselben Server gehostet werden muss IP-basiertes Hosting angewendet werden.

Für das Problem gibts doch SNI