VPN einrichten

[spcqike]

Das ist in der Tat komisch. Die VM sollte die IP anzeigen die sie per DHCP vom Router bekommt.

Kannst du die .222 vom Windows PC aus anpingen?

Du kannst zum lokalen Testen von WireGuard natürlich auch WireGuard auf den PC installieren und dich von dort als Client mit see VM Verbinden. Und gucken ob der handshake klappt und du ins 10.66.66.0/24 Netzwerk kommst.

Edit:

Bevor du vollends verzweifelst solltest du wirklich erst einmal sicherstellen dass lokal alles klappt.

Ping zur VM

WireGuard lokal zur VM Und ins 10.66.66.1/24 netz

Danach

Externe portweiterleitung zur VM (wirklich 100% sicher dass die externe IPv4 deine eigene ist? Kein DS-Lite sondern ein echter DualStack?)

WireGuard von einem externen Gerät testen

 

[Ray Donovan]

Jetzt wird es langsam wirklich wired
Also. Ich fasse das jetzt wie folgt zusammen und denke, dass da auch die Lösung gefunden wird.

Host (Windows 10)

ipconfig

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix:
   Verbindungslokale IPv6-Adresse  . : fe80::91c4:1078:9aff:9f7f%21
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.8
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.178.1

D.h der Host hat die interne IP .8 am Ende. Wieso mir DietPi immer die .48 anzeigt, ist mir ein Rätsel.
Anpingen kann ich die .48 vom Host auch.

Der Port-Scanner zeigt mir zur .48 folgendes an:

Server

Status: Lebendig
Betriebssystem: Linux
IP: 192.168.178.48
MAC: 08:00:27:80:5F:C9
Hersteller: PCS Systemtechnik GmbH
NetBIOS:
Anwender:
Art:
Datum:
Kommentare:

Dienst
Ausführlich
Port 22 (TCP)
Dropbear sshd 2020.81 protocol 2.0

Ich habe ja die MAC-Adresse die mir VirtualBox anzeigt im Router die feste IP .222 gegeben und leite auch die Ports dahin weiter. Ich kann die .222 lokal aber gar nicht anpingen. Daher kann es auch überhaupt nicht funktionieren:

C:\Windows\System32>ping 192.168.178.222

Ping wird ausgeführt für 192.168.178.222 mit 32 Bytes Daten:
Antwort von 192.168.178.8: Zielhost nicht erreichbar.
Antwort von 192.168.178.8: Zielhost nicht erreichbar.
Antwort von 192.168.178.8: Zielhost nicht erreichbar.
Antwort von 192.168.178.8: Zielhost nicht erreichbar.

Ping-Statistik für 192.168.178.222:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),

Komisch auch, dass er von der .222 auf die .8 springt (Host).
Der Port-Scanner von der .222 zeigt folgendes:

virtualbox-vpn

Status: Keine Reaktion
Betriebssystem:

IP: 192.168.178.222
MAC: 08:00:27:1E:46:DB
Hersteller: PCS Systemtechnik GmbH
NetBIOS:

Anwender:
Art:
Datum:
Kommentare:

Dienst
Ausführlich

D.h die 222 ist quasi tot.
Was zeigt mir VirtualBox denn da für eine MAC-Adresse an?
Theoretisch müsste es die doch geben, sonst würde der Router die doch gar nicht vergeben und ich würde sie im Port-Scanner gar nicht finden? Oder?

Anbei noch ein Bild von der VM (ifconfig):

Also hier ist irgendwo der Wurm drin.
Für eure Hilfe bin ich nach wie vor sehr dankbar.

@omavoss schau dir diesen Beitrag nochmal an. Als du deinen geschrieben hast, hast du den hier wahrscheinlich noch gar nicht gesehen.

 

[omavoss]

Evtl. den Wireguard-Client auf einem Smartphone installieren, dann in der VM einen neuen Tunnel einrichten, es erscheint ein QR-Code, den mit der Wireguard-App auf dem Smartphone scannen, einen Namen vergeben und den Tunnel öffnen. Dann schauen, ob man sich mit dem LAN verbinden kann.

Ich weiß, das ist alles nichts neues, aber manchmal geschehen überraschende Dinge.

 

[Raijin]

Ich habe ja die MAC-Adresse die mir VirtualBox anzeigt im Router die feste IP .222 gegeben und leite auch die Ports dahin weiter. Ich kann die .222 lokal aber gar nicht anpingen.

Einfach nur im Router einer MAC eine IP-Adresse zuweisen funktioniert nur dann, wenn das Gerät mit dieser MAC auch tatsächlich via DHCP eine IP-Adresse bezieht. Wenn das Gerät jedoch eine statische IP konfiguriert hat, bekommt der DHCP-Server das gar nicht mit und wartet einfach bis zum Ende aller Tage, dass sich diese MAC jemals um eine DHCP-IP bemüht, was nie passieren wird.

Ich gehe daher einfach mal davon aus, dass deine VM eine statische IP hat, die .48, und du dich nun auf die im Router reservierte IP verlassen hast, die jedoch gar nicht verwendet wurde, weil die VM beim DHCP nie nach einer IP gefragt hat.

DietPI wird dir daher bei der Installation nicht die .48 angezeigt haben, sondern sie wurde eingestellt.
Mit dietpi-config kann man die Einstellungen prüfen bzw. ändern. Da wird bei dir jetzt mutmaßlich "static" oder dergleichen nebst der .48er IP stehen.

Wenn dem so ist, musst du natürlich bei deinen lokalen Tests sowie bei der Portweiterleitung die .48 nehmen und nicht die .222.

 

[Ray Donovan]

Macht Sinn @Raijin.

Anbei ein Screen von der config.

Der macht widerum gar keinen Sinn - mit der statischen IP hattest du recht, allerdings ist die völlig falsch? Wie kommt er denn auf die .48? Das Gateway ist auch falsch (das müsste doch 192.168.178.1 sein?).

Ah... nach Klick auf "copy current address to "Static" sieht es korrekt aus. Ich probiere das dann jetzt nochmal.

Ergänzung (5. Februar 2022)

So.

Host
ping 192.168.178.48 (VM) funktioniert

VM
ping 192.168.178.8 (Host) funktioniert
ping 10.06.0.2 (Client01) funktioniert

Die externe Verbindung in das VPN funktioniert aber nach wie vor nicht.
Wenn ich den Port 55739 mit der öffentlichen IP scanne, zeigt er mir auch immer, dass er nicht offen ist - Port 55739 wird aber an die .48 weitergeleitet im Router - laut Einstellungen.

Wo kann ich jetzt noch ansetzen?
Wie gesagt, der Test per FTP (NAS) vor ein paar Tagen hatte problemlos funktioniert (nachdem ich den Port freigegeben hatte). An der öffentlichen IP sollte es eigentlich nicht liegen können.

Per pktstat -n kommt auch keine Anfrage rein, wenn ich per externer Verbindung mich mit dem Wireguard-Clienten anmelden will.

Ist das jetzt eher ein Problem des Routers/Firewall (die habe ich am Host schon kurzzeitig ausgeschaltet, hat nichts gebracht) oder liegt noch eine Fehlkonfiguration vor?

 

[Ray Donovan]

Wenn ich das jetzt richtig verstanden habe, ist es völlig egal ob ich den Port weiterleite oder nicht - für Wireguard sind alle Ports geschlossen, sofern nicht das richtige Zertifikat vorhanden ist. D.h es bringt gar nichts extern zu checken ob der Port offen ist, weil er bei einem reinen Scan ja keine Zertifikate überträgt.

Ich probiere weiter...

 

[omavoss]

@Ray Donovan :
Es ist schon früh am Morgen und ganz frisch bin ich auch nicht mehr; aber ist der Wireguard-Standard-Port nicht 51820?

 

[Ray Donovan]

@Ray Donovan :
Es ist schon früh am Morgen und ganz frisch bin ich auch nicht mehr; aber ist der Wireguard-Standard-Port nicht 51820?

Ja, den hatte ich geändert.
Mittlerweile ist er auf 51820 aber ich bekomme trotzdem keine Verbindung zum VPN.

Langsam bin ich echt am verzweifeln...

Ergänzung (6. Februar 2022)

So Leute... ich habe das Problem gefunden.
Gefunden, nicht gelöst.

Ich habe den ganzen Rotz extern immer auf einem Notebook mit Windows 11 gemacht.
Dann habe ich das ganze mal auf meinem eigenen Rechner (auch extern) mit Windows 10 gemacht... Wireguard war sofort im VPN-Netz.

........................................................

Warum Windows 11 rumspackt, weiß ich noch nicht.

Ergänzung (6. Februar 2022)

Lösung gefunden.
Da muss man erstmal drauf kommen.

Lange Rede, kurzer Sinn... An der Firewall und an Windows 11 lag es nicht.

Als ich mir die IP-Adresse des Notebooks (Windows 11) angesehen habe, ist mir aufgefallen, dass das Notebook in einer anderen IP-Range war. Das Notebook hatte die IP-Adresse 192.168.179.XX, mein Rechner 192.168.178.XX (ich habe tatsächlich eine fritz.box). Es lag dann daran, weil das Notebook im Gast-WLAN war und mein Rechner nicht. Als ich das Notebook auch über das normale WLAN verbunden habe, ging Wireguard sofort.

Frage a.)
Warum hat die Range hier so einen Effekt? Ich hatte ja zeitweise in der Wireguard-Config alle IP-Adressen erlaubt habe (0.0.0.0/0) und es auch mit 192.168.179.0/24 probiert - ohne Erfolg. Mag mir jemand erklären, warum das so ist?

Frage b.)
Dadurch, dass im Büro die gleiche IP-range läuft (obwohl Vodafone plus.box), wie bei einer fritz.box (192.168.178.X) bei mir zu Hause, was passiert denn, wenn man sich per VPN einwählt und zwei Geräte die gleiche IP-Adresse zugewiesen bekommen? Wie umgeht man das am besten? Muss man wirklich allen Geräten eine feste IP-Adresse geben?

Frage c.)
Ohne VPN kommt man ja von außen ja nicht in das Netzwerk und die Ports für RDP werden nicht weitergeleitet. Das sollte als Absicherung doch reichen, oder? RDP ist von außen nicht ansteuerbar, korrekt?

Nochmal herzlichen Dank an alle für ihren Input. Ohne euch hätte ich das niemals geschafft. Es hat nun deutlich länger gedauert, als ich gedacht und erwartet habe und ich war auch mehrfach kurz davor entweder völlig auszurasten oder einfach aufzugeben aber ich habe dadurch auch viel gelernt.

DietPi ist in der Tat wirklich sehr einfach und das war eigentlich auch genau das, was ich gesucht habe. Aber ich hätte auch noch 500 andere Distributionen installieren können - die hätten das Kernproblem auch nicht behoben.

 

[spcqike]

A) .179. ist in der Regel das Gast wlan inkl. seiner Einschränkungen. Da kann es sein dass der Udp Port nach außen einfach blockiert ist.

B) am besten umgeht man das mit zwei unterschiedlichen IP Ranges.
Haben lokales und das entfernte Netzwerk die gleiche IP erreicht man nur das lokale. Auch wenn es die .128 remote gibt aber lokal nicht, dann erreicht man sie einfach nicht.
Ein workaround: die entfernte Adresse die man erreichen will als dedizierte Route in die config aufnehmen.

Allowedips = 10.66.66.1/24, 192.168.178.128/32

Wichtig die CIDR Angabe /32. das sagt: genau die Eine IP. (Generell werden Routen von der weitesten/allgemeinsten (/0) zur kleinsten/genausten (/32) immer stärker priorisiert. Du kannst also alle Angaben größer /24 nutzen. Also ab /25 bis /32)

Damit würdest du das Gerät aber im lokalen Netzwerk nicht mehr sehen.

Zweiter workaround: das entfernte gerät mit in das WireGuard VPN holen und über seine VPN Adresse ansprechen.

C) genau. Von außen ist nur der WireGuard Port offen. Am Server werden unterschiedliche Ports für unterschiedliche Dienste konfiguriert und man kann nur die Dienste benutzen die man erreichen kann. RDP verwendet ganz andere Ports. sie du nicht freigegeben hast und solltest da RDP nicht unbedingt als sicher gilt.

 

[Raijin]

Frage a.)
Warum hat die Range hier so einen Effekt? Ich hatte ja zeitweise in der Wireguard-Config alle IP-Adressen erlaubt habe (0.0.0.0/0) und es auch mit 192.168.179.0/24 probiert - ohne Erfolg. Mag mir jemand erklären, warum das so ist?

Ein Gastnetzwerk hat zwei essentielle Eigenschaften. Zum einen ist der gegenseitige Zugriff zwischen Haupt- und Gastnetzwerk blockiert und zum anderen ist der Internetzugriff potentiell eingeschränkt.

Frage b.)
Dadurch, dass im Büro die gleiche IP-range läuft (obwohl Vodafone plus.box), wie bei einer fritz.box (192.168.178.X) bei mir zu Hause, was passiert denn, wenn man sich per VPN einwählt und zwei Geräte die gleiche IP-Adresse zugewiesen bekommen? Wie umgeht man das am besten? Muss man wirklich allen Geräten eine feste IP-Adresse geben?

Ein Subnetzkonflikt zwischen zwei via VPN verbundenen Netzwerken ist ein Problem. Man kann mit speziellen Routen wie @spcqike sie erklärt einen Workaround schaffen, aber ich rate zu einer Anpassung der Subnetze.

192.168.0.0 - 192.168.255.25
172.16.0.0 - 172.31.255.255
10.0.0.0 - 10.255.255.255

Das sind die für private Netzwerke reservierten Bereiche und man ist bei VPN gut damit beraten, die lokalen Subnetze kreativ zu wählen. 192.168.178.0/24 ist wie alle anderen ab Werk eingestellten Router-Subnetze das komplette Gegenteil von kreativ - insbesondere wenn man dann noch anfängt, an Vodafone Routern das Fritzbox Subnetz einzustellen...

Frage c.)
Ohne VPN kommt man ja von außen ja nicht in das Netzwerk und die Ports für RDP werden nicht weitergeleitet. Das sollte als Absicherung doch reichen, oder? RDP ist von außen nicht ansteuerbar, korrekt?

Nur dann, wenn

• eine Portweiterleitung für Port X angelegt wurde
• die Firewall des Zielsgeräts die Verbindung auf Port X zulässt
• auf dem Zielgerät eine Anwendung auf Port X läuft

ist ein Zugriff von außen möglich. Mit einem VPN ist man effektiv im heimischen Netzwerk und kann dort alle Dienste inkl RDP nutzen als säße man daheim auf der Couch.

 

[Ray Donovan]

So, im Büro angekommen gibt es jetzt weitere Probleme.
Es gibt zwei Notebooks.

Problem 1.)
Notebook A (Windows 10, als Client zum verbinden), per WLAN angeschlossen, hat die IP 192.168.178.X
- funktioniert alles wie gewünscht. Sowohl lokal ohne VPN, als auch extern mit VPN
Notebook B (Windows 11 als Client zum verbinden), per WLAN angeschlossen, hat die IP 192.168.254.X
- hier funktioniert es nur extern per VPN. Sobald ich vor Ort bin, geht es nicht mehr

Es wird wohl an der IP-Range liegen. Verwunderlich ist aber, das beide Notebook per WLAN im gleichen Netz sind. Wieso gibt der Router verschiedene IP-Ranges?

Im Router ist als Range bei LAN 192.168.178.X angelegt, bei WLAN 192.168.254.X, im Gast-WLAN ist es die 172.16.94.X

Problem 2.)
Bei beiden Notebooks, kann ich mich lokal nicht ins VPN einwählen. Das macht auch keinen Sinn aber ist es normal, dass es nicht geht?

Problem 3.)
Ich habe mir ein kleines Script geschrieben, welches nach dem einwählen in das VPN und vor Verbindung per RDP prüft, ob der gewünschte Rechner überhaupt an ist und wenn nicht, weckt er ihn (WoL) per WolCmd.

@ECHO OFF

SET wolcmd="C:\WolCmd.exe"
SET destinationIp=192.168.178.50
SET macAdress=XXX
SET subNet=255.255.255.0
SET port=7

ECHO Pruefe ob der Rechner eingeschaltet ist...

:CHECK_PING
ping -n 1 %destinationIp% | find "TTL=" >nul
IF ERRORLEVEL 1 (
    ECHO Computer ist ausgeschaltet.
    ECHO WoL-Request wird gesendet.
    %wolcmd% %macAdress% %destinationIp% %subNet% %port%
    
    ECHO Pruefe nach Ablauf der Zeit erneut...
    timeout /t 30 /nobreak
    GOTO CHECK_PING
) ELSE (
    ECHO Rechner ist eingeschaltet...
    ECHO Bitte VPN Verbindung aufbauen und per RPD verbinden.
    ECHO Das Fenster wird nach Ablauf der Zeit geschlossen...
    timeout /t 30 /nobreak
)

Auf Notebook A klappt alles reibungslos. Ich kann dort jeden (!) Rechner per WoL wecken. Das klappt immer und zuverlässig.
Bei Notebook B klappt es leider nicht. Gar nicht. Lokal kann ich es gar nicht testen, wegen Problem 1 und extern per VPN geht es auch nicht.

Liegt das an Windows 11?
Die Firewall hatte ich schon testweise ausgemacht.
Als Admin starten und Kompatibilitätsmodus hat auch nichts gebracht.

Danke für eure Hilfe!

 

[Raijin]

Im Router ist als Range bei LAN 192.168.178.X angelegt, bei WLAN 192.168.254.X, im Gast-WLAN ist es die 172.16.94.X

Wie jetzt das WLAN hat ein anderes Subnetz? WLAN ist nur ein "kabelloses Kabel" und kein eigenständiges Netzwerk, da in einem WLAN-Router zumindest ohne alternative Firmware das WLAN-Interface und das LAN-Interface gebridged sind, also "ein" Netzwerk bilden.

Verschiedene Subnetze setzen voraus, dass sie untereinander korrekt geroutet werden und ggfs die Firewall dazwischen korrekt eingestellt ist.

Das klingt ehrlich gesagt ein wenig kaputtkonfiguriert, wenn ich das mal so sagen darf. Oder es wird mit VLANs und verschiedenen SSIDs gearbeitet, das kann natürlich auch sein.

 

[Ray Donovan]

Ja, das WLAN hat ein ganz anderes Subnetz, aber Notebook A bekommt das "richtige" Subnet, Notebook B eben nicht, obwohl beide das gleiche Netzwerk nutzen. Ich finde das auch total strange.

Ich habe den Router so auch nicht eingerichtet - ich hatte ihn zurückgesetzt und wieder so hergestellt wie er vorher war. Was die Person dazu bewogen hat, es so zu machen, keine Ahhnung. Die Person gibt es aber nicht mehr und ich versuche den Laden gerade aufzuräumen.

Soll ich dem WLAN das gleiche Subnetz geben? Wieso hat es überhaupt ein anderes - das habe ich gar nicht verändert.

Hast du noch einen Ansatz für Problem 2 und 3?

 

[Raijin]

Soll ich dem WLAN das gleiche Subnetz geben? Wieso hat es überhaupt ein anderes - das habe ich gar nicht verändert.

Das vermag ich nicht zu beurteilen. Dazu müsste man jetzt das komplette Setup kennen und wissen welche Gründe es dafür gibt/gab. Über ein Forum nicht zu bewerkstelligen, insbeondere nicht bei Firmennetzwerken, die generell nicht in einem Forum behandelt werden sollten, sondern von fachkundigen IT-Admins vor Ort. Mag sein, dass ich das auf mittlerweile 4 Seiten auch überlesen oder wieder vergessen habe, aber mir ist es zumindest in diesem Moment neu, dass plötzlich ein Firmennetzwerk mit von der Partie ist.

Zu 2 und 3 kann man auch nicht viel sagen, weil eben .. .. naja .. .. 1.
Unterschiedliche Subnetze können entweder quick and dirty ohne VLANs über dieselbe Infrastruktur laufen oder korrekterweise mit VLANs. Ob und wie dann geroutet wird, was die Firewall dazwischen sagt, etc. steht in den Sternen.

Was die Person dazu bewogen hat, es so zu machen, keine Ahhnung. Die Person gibt es aber nicht mehr und ich versuche den Laden gerade aufzuräumen.

Dann müssen die Anforderungen an das Netzwerk erneut aufgenommen und an einen fachkundigen IT-Admin / -Dienstleister übergeben werden. Es wird ja mutmaßlich Gründe dafür gegeben haben, das so einzurichten. Wenn du da jetzt ohne Kontext dran rumbastelst, kann es sein, dass die halbe Firme plötzlich nicht mehr arbeiten kann, weil Software XY nicht mehr funktioniert. An dieser Stelle werde ich daher auch keine weitergehenden Ratschläge geben, da dieses Forum für Heimnetzwerke da ist und ich immer Bauchschmerzen bekomme, wenn Firmennetzwerke nicht fachgerecht betreut werden. Du darfst gerne in dein Verderben reiten und die Firma mitreißen, aber ohne mich, sorry :-/

 

[uWt-oMG-UMD-YfK]

Notebook B (Windows 11 als Client zum verbinden), per WLAN angeschlossen, hat die IP 192.168.254.X
- hier funktioniert es nur extern per VPN. Sobald ich vor Ort bin, geht es nicht mehr

das hat ansich nichts mit dem Subnetz zu tun. Aus der anderen Subnetzmaske (.178) lässt sich schließen dass du eine Fritzbox verwendest. Dort kann man explizit für das Gast-Netz (wovon ich annehme dass du dich in diesem bewegst) für bestimmte Anwendungen sperren bzw. nur bestimmte Anwendeungen freigeben.

 

[Ray Donovan]

Es geht um eine kleine Flrma, die einen IT Spezi hatte, der das ganze so hinterlassen hat. Ich räume dort auf, weil es ein Freund von mir ist und mich das Thema sehr interessiert. Ausserdem hasse ich Chaos. Die Probleme die da auftreten rühren ja von einer katastrophalen Umsetzung. Er hat noch nicht nochmal aufgeschrieben welche IP für was ist. Router Passwort was hinten drauf steht, stimmt nicht. Alle Rechner haben den gleichen Benutzernamen weil immer nur geklont wurde etc. pp. Das die Firma keinen Bock mehr auf Spezialisten hat, kann ich verstehen. Das VPN war auch für mich, damit ich vieles von zu Hause machen kann. RDP war vorher ein übrigens auch offen … ohne VPN. Super. Kategorie ohne Liebe schnellstmöglich hingerotzt.

Zusätzlich teile ich meine Lösungen hier, falls sie mal jemand anderen helfen.

RDP mit VPN und WoL, sind dafür, dass ich mich mit dem Thema nie intensiv befasst habe, schon in Ordnung, in der kurzen Zeit.

das hat ansich nichts mit dem Subnetz zu tun. Aus der anderen Subnetzmaske (.178) lässt sich schließen dass du eine Fritzbox verwendest. Dort kann man explizit für das Gast-Netz (wovon ich annehme dass du dich in diesem bewegst) für bestimmte Anwendungen sperren bzw. nur bestimmte Anwendeungen freigeben.

Es ist keine fritz.box und beide Notebooks sind im gleichen WLAN Netzwerk (nicht im Gast WLAN) trotzdem unterschiedliche Subnetzte.

 

[Raijin]

Es geht um eine kleine Flrma, die einen IT Spezi hatte, der das ganze so hinterlassen hat.
[..]
Das die Firma keinen Bock mehr auf Spezialisten hat, kann ich verstehen.

Von einem "IT Spezi" - was auch immer das heißen soll - auf andere zu schließen, ist aber recht engstirnig. Und das stattdessen nem Kumpel zu übergeben, der sich dann in einem öffentlichen Forum Hilfe suchen muss, ist alles andere als ein Fortschritt.

Ich kann für dich nur hoffen, dass du dich nicht übernimmst. Auch wenn ich selbst ein artverwandtes Studium hinter mir habe, bin ich kein IT-Administrator und würde mir den Schuh auch nicht anziehen, auch nicht in einer kleinen Firma meines Kumpels. Mit der IT steht und fällt ein Unternehmen und wenn am Ende gar noch Kundendaten abhanden kommen, weil das nicht fachgerecht gesichert wurde, hat man schneller einen Brief vom Anwalt als einem lieb ist. Ich will dich nicht ärgern, aber du übernimmst da eine Verantwortung, die du augenscheinlich nicht übernehmen kannst....

Es ist keine fritz.box und beide Notebooks sind im gleichen WLAN Netzwerk (nicht im Gast WLAN) trotzdem unterschiedliche Subnetzte.

Da wäre beispielsweise der erste Ansatz, herauszufinden ob es irgendwelche VLANs gibt und/oder ob der eine DHCP MAC-spezifische Konfiguration hat. Bevor irgendwas an einem Netzwerk rumgebastelt wird, muss der status quo sauber dokumentiert bzw. aufgenommen werden.

Für weitergehende Beratung/Hilfestellung rate ich zu einem Termin bei einem Systemhaus.

 

[Ray Donovan]

Kurzes Update meinerseits, für Leute die vielleicht ein ähnliches Problem haben:

Die SSID wurde anscheinend mehrfach vergeben durch verschiedene Router.

Vodafone-Router (bei WLAN sind das die Standard-Werte, LAN war vorher 192.168.1.1):
LAN: 192.168.178.1
WLAN: 192.168.254.1 (gleiche IP-Range wie LAN lässt sich nicht einstellen)
WLAN (Gast): 172.16.94.2

Wieso das Notebook mit Windows 10 die IP 192.168.178.X und das Notebook mit Windows 11 192.168.254.1 erhält ist mir leider noch ein absolutes Rätsel. Vermutlich gibt es noch weitere Router die als AP dienen und durch den Netzwerk-Reset und wiederherstellen der alten WLAN-SSID und Passwörtern sich jetzt eben beißen.

Allerdings finde ich es auch merkwürdig, dass LAN und WLAN IP-Ranges bei bei der Vodafone-Box Standardmäßig verschieden sind - ich dachte eigentlich, dass die gleich sind.

Es führt aber so oder so aber kein Weg daran vorbei, das Netzwerk komplett neu aufzusetzen.

 

[Ray Donovan]

Von einem "IT Spezi" - was auch immer das heißen soll - auf andere zu schließen, ist aber recht engstirnig.

Das hast du falsch aufgefasst. Ich habe jetzt schon mehrfach erlebt, dass sich Firmen oder Einzelpersonen als absolute Spezialisten outen, dabei aber absolute Blender sind. So ein unfassbar verkorkstes Netzwerk habe ich in der Form wie hier so z.B noch nicht gesehen. Es gab auch eine Firma, die bei einem befreundeten Verein das RDP einfach ganz aufgemacht haben. Ohne VPN. Mit dem Standard-Port. Ich bin selbstverständlich im Bereich Netzwerk niemals so gut, wie jemand, der das gelernt/studiert hat, allerdings spornt es mich an, mich weiterzuentwickeln und neue Dinge zu lernen. Aber jetzt genug.

Anbei noch mein letztes Update in diesen Thread dann auch dem Ende zuzuführen.

Ich habe das Problem mit Wake on LAN lokalisieren und beheben können.
Wenn man sich per VPN verbindet, erreicht das Magic Packet den Computer gar nicht, weil es eine ganz andere Ebene ist. Durch den anderen IP-Bereich vermute ich, dass das Magic Packet eben deswegen nicht durchgeht.

Ich habe auf dem Dietpi nun noch ngnix mit PHP installiert und ein kleines Script geschrieben. Das Script sendet das Magic Paket quasi direkt lokal an den gewünschten Rechner per PHP und exec. Der Webserver ist nur lokal zu erreichen. Es gibt sicherlich noch andere und bessere Ansätze aber es funktioniert einwandfrei.

Falls jemand Interesse daran hat...

client.bat

@ECHO OFF

SET curl="C:\curl\bin\curl.exe"
SET subnet=192.168.178
SET server=48
SET client=50
SET destinationIp=%subnet%.%client%

ECHO Pruefe ob Computer %destinationIp% eingeschaltet ist...

:CHECK_PING
ping -n 1 %destinationIp% | find "TTL=" >nul
IF ERRORLEVEL 1 (
    ECHO Computer ist ausgeschaltet.
    ECHO "Wake on LAN"-Request wird gesendet...
   
    %curl% -d "id=%client% " -X POST http://%subnet%.%server%/wol.php

    ECHO Pruefe nach Ablauf der Zeit erneut...
    timeout /t 30 /nobreak
    GOTO CHECK_PING
) ELSE (
    ECHO Computer ist eingeschaltet...
    ECHO Bitte VPN Verbindung aufbauen und per RPD verbinden.
    ECHO Das Fenster wird nach Ablauf der Zeit geschlossen,
    ECHO es darf aber auch schon vorher geschlossen werden.
    timeout /t 30 /nobreak
)

wol.php

<?php
$subnet = '192.168.178.';
$macAddresses = array(
        50 => 'D0:50:99:0E:28:E2',
        51 => 'D0:50:99:0E:29:0A',
        52 => 'D0:50:99:0E:27:52');

$id = 0;
if (isset($_POST['id']))
$id = (int)$_POST['id'];

if ($id == 0)
{
        echo 'Identifikation nicht vollstaendig.';
        exit();
} // if ($lastBlock == 0)

if (isset($macAddresses[$id]))
{
        exec('sudo etherwake -b '. $macAddresses[$id], $output, $retval);

        if ($retval == 0)
                echo '"Wake on LAN" Signal wurde an '. $macAddresses[$id] .' ('. $subnet . $id .') gesendet.';
        else
                echo 'Beim senden des "Wake on LAN" Singals nach '. $macAddresses[$id] .' ('. $subnet . $id .')';
}
else
{
        echo 'Identifikation fehlgeschlagen.';
} // if (in_array($id, $macAddresses))
?>

Für den Befehl

exec('sudo etherwake -b '. $macAddresses[$id], $output, $retval);

Ist noch eine Änderung notwendig. Der Befehl funktioniert so nicht, da www-data keine Rechte hat um diesen Befehl auszuführen.

sudo visudo

www-data ALL=(ALL) NOPASSWD:/usr/sbin/etherwake

So darf www-data den Befehl etherwake mit root-Rechten und ohne Passwortabfrage.