- Mitglied seit
- 28. Okt 2020
- Beiträge
- 15.029
- Punkte für Reaktionen
- 5.400
- Punkte
- 564
Da hier immer wieder die Frage aufkommt, wie man im LAN mit https arbeiten kann, erstelle ich hier mal eine Art „Guide“.
Warum braucht man das Ganze? Einfach gesagt, weil eine https Verbindung immer von einem Zertifikat abgesichert / verschlüsselt wird. Dieses ist aber nur gültig für die Domain, für die es ausgestellt wurde. Und klassischerweise erhält man für eine IP-Adresse kein Zertifikat.
Man kann es auch einfach halten, so wie in meinem anderen Thread beschrieben (mehr dazu auch hier in diesem Thread unter Punkt 1.2.1). Mit eigenem DNS-Server ist man aber flexibler, falls man mal eine Domain / einen DDNS nutzen will, bei dem diese Option nicht gegeben ist (und das ist bei den meisten der Fall). Zudem kann man noch weitere DNS-Einträge umbiegen bei Bedarf.
Hinweis vorneweg: Wenn die DS aus ist, habt ihr kein Internet! Bitte bedenken, dass ohne DNS-Server nix mehr geht. Fahrt ihr also die DS per Zeitplan runter, ist diese Vorgehensweise eher schlecht geeignet.
HINWEIS: Keine Gewährleistung auf Vollständigkeit und 100%ige Korrektheit! Wem ein Fehler auffällt, der kann das gerne (mit freundlichem Umgangston) hier melden!
Voraussetzungen:
In dieser Anleitung wird vorausgesetzt, dass der Umgang mit der FileStation und Hochladen von Dateien aufs NAS bekannt ist und auch, wie man mit Archiven umgeht.
To Do:
Eine eigene Domain / eine DDNS-Adresse (idealerweise mit Wildcard-Zertifikat)
Hierfür werden wir synology.me als DDNS-Anbieter nutzen. Und zwar aus 3 Gründen:
1.) Der Dienst bietet Wildcard DNS (alle Subdomains werden ebenfalls auf eure ext. IP aufgelöst).
->dies ist wichtig, wenn man später doch mal von extern auf einen Dienst ohne VPN zugreifen will
2.) Die DS kann für diese Adresse ein Wildcard Zertifikat erstellen (das Zertifikat ist für die Adresse selbst und für alle Subdomains gültig).
->das brauchen wir, damit wir mit dem Reverse Proxy und Subdomains anstatt Ports arbeiten können
3.) Für die Zertifikatserstellung ist keine Portweiterleitung im Router notwendig.
->bei den meisten anderen Anbietern müsste Port 80/443 im Router offen sein.
Quelle: Synology KB-Artikel
Ein eigener DNS-Server
Als DNS-Server kommt AdGuard Home zum Einsatz, der wiederum als upstream DNS-Server unbound nutzt. Warum nicht den einfachen Synology DNS-Server? Weil man mit der Kombi gleich noch einen netzwerkweiten Werbe- und Trackingblocker obendrauf hat, der sogar (die richtigen Block-Listen vorausgesetzt) in einem gewissen Umfang vor Phishing und Malware im Heimnetz schützen kann.
Was unbound genau tut, kann man z.B. in diesem Artikel nachlesen.
Genauere Infos, warum ich die Kombi aus AdGuard Home + unbound nutze, gibt's im verlinkten Installations-Thread unter Schritt 2.1.
Anleitung
Schritt 1: Anlegen der DDNS Adresse mit Wildcard-Zertifikat
Schritt 1.1: Synology Account hinterlegen
Wir melden uns bei DSM mit einem User an, der Administratorrechte hat. Zuallererst müssen wir uns mit einem Synology-Konto anmelden in der DS, damit wir die DDNS-Dienste von Synology in Anspruch nehmen dürfen. Dazu wechseln in die Systemsteuerung -> Synology-Konto und drücken auf den Link zum Anmelden mit einem Konto:
Dann sollte sich ein neues Fenster öffnen, bei dem man sich anmelden kann, falls man schon ein Konto hat. Wenn nicht, drückt man unten auf den Link „Ein Synology-Konto erstellen“.
Hinweis: Wenn sich da kein Fenster öffnet, hat entweder ein Werbeblocker oder der Popup-Blocker des Browsers zugeschlagen. Hier hilft es vielleicht, temporär auf einen anderen Browser zu wechseln und den Vorgang erneut auszuführen.
Schritt 1.2: Synology DDNS-Adresse anlegen
Umschalten auf Externer Zugriff -> DDNS. Oben auf den Button „Hinzufügen“ drücken und in dem Dropdown „Serviceanbieter“ „Synology“ auswählen. Bei Hostname den ersten Teil der gewünschten DDNS-Adresse eintragen. Im hinteren Dropdown „synology.me“ auswählen. Hint an der Stelle: Eigentlich müsste unser Vorhaben hier mit jeder Domain funktionieren laut KB-Artikel. Früher hat dies aber nur mit „synology.me“ funktioniert und auch nur damit habe ich es getestet. Unten noch den Haken für die Zertifikatserstellung setzen. Der Rest kann so belassen werden, wie er ist:
[optional] Schritt 1.2.1: DDNS mit Boardmitteln auf interne IP biegen
Man kann in diesem Fenster die Auswahlbox hinter "Externe Adresse (IPv4)" auch direkt umstellen von "automatisch" auf "LAN X". Damit löst der DDNS bereits auf die interne IP auf, ohne dass man einen DNS-Server oder AdGuard + unbound braucht. Wenn man möchte, ist man an dieser Stelle also bereits fertig (dennoch sollte man sich den folgenden Schritt 1.2.2 noch zu Gemüte führen). Kann man machen, wenn man es einfach haben will. Alle weiteren folgenden Schritte dienen dazu, das Ganze mit dem AdGuard umzusetzen. Das kann man natürlich so mit jedem anderen DNS-Server genau so machen. Mein Favorit ist aber ganz klar der AdGuard und deshalb zeige ich das hier auch damit. Wenn man das mit einem eigenen DNS-Server umsetzt, hat man nicht nur einen Vorteil:
-man kann (bei Bedarf) für internen und externen Zugriff die gleiche DDNS-Adresse nutzen
->intern löst die Adresse auf die interne IPv4 der DS auf
->extern löst die Adresse auf die exterene IPv4 des Routers auf
-man kann bei Bedarf schnell weitere Umbiegungen vornehmen
-man ist nicht auf den Synology DDNS Dienst angewiesen (nur dieser bietet m.W. die Möglichkeit, den DDNS direkt privat aufzulösen)
Wenn ein externer Zugriff auf den DDNS (also ohne VPN) nicht gebraucht wird, empfehle ich, das hier auf die interne IP zu stellen. Denn wenn ein Client im Heimnetz aus irgendeinem Grund nicht den AdGuard verwendet, ist dann dennoch eine korrekte Auflösung gegeben. Andernfalls würde der Client auf die externe IP losgehen und der Aufruf funktioniert nicht mehr. Dann geht die Fehlersuche los.
Schritt 1.2.2: Umgang mit dem neuen Zertifikat
Wenn nun eine Meldung kommt mit dem Hinweis „Dieser Hostname wird bereits verwendet“, ist die gewählte Adresse bereits in Verwendung und muss geändert werden. So war das bei mir der Fall und ich habe „test1234“ durch „12test34“ ersetzt. Daraufhin dauert es ein paar Sekunden und das DSM-Admin Interface wird neu geladen. Möglicherweise erscheint hier der Sicherheitshinweis eures Browsers, falls ihr mit https verbunden seid. Diesen kann man aber ignorieren:
Es kann sein, dass eine Fehlermeldung von DSM erscheint, dass das Zertifikat nicht ausgestellt werden konnte, weil Ports nicht offen waren. Den Fehler kann man ignorieren. Er ist eher noch als „Relikt aus alten Zeiten“ zu sehen, zu denen man immer die Ports für Zertifikate öffnen musste.
Nun sollte man in der Systemsteuerung unter Sicherheit -> Zertifikat das frisch erstellte Zertifikat sehen. Dieses ist 3 Monate gültig und wird von der DS vor Ablauf automatisch erneuert. Wenn nicht, kann man dies aber auch manuell via „Aktion“ -> „Zertifikat erneuern“ anstoßen.
Schritt 2: Installation und Konfiguration des AdGuard
Schritt 2.1: Installation von AdGuard Home und unbound via CLI
Diesen Teil der Anleitung habe ich ausgelagert in einen separaten Thread.
Ansonsten hätte dieser Thread die Begrenzungen des Forums erreicht.
Schritt 2.2: Erweiterte Konfiguration des AdGuard Home
Jetzt tragen wir endlich unseren DDNS, den wir angelegt haben, im AdGuard als DNS-Umschreibung ein. Dazu auf „Filter“ und „DNS-Umschreibungen“, „DNS-Umschreibung hinzufügen“ klicken:
Im sich öffnenden Fenster tragen wir nun unsere DDNS-Adresse ein und darunter die interne IP der DS:
Damit der Wildcard DNS im Heimnetz funktioniert, müssen wir diesen separat anlegen, indem wir das Gleiche nochmal tun, nur dieses Mal ein „*.“ vor die Domain setzen:
Schritt 2.3: Testen
Das Ganze kann man testen, wenn man eine Eingabeaufforderung öffnet und
Bei der FritzBox ist unter bestimmten Konstellationen erforderlich, den Rebind-Schutz für die entsprechende Domain zu deaktivieren, der dafür sorgen kann, dass DNS-Antworten unterdrückt werden, die auf interne Ressourcen zeigen. Das macht man so:
Man wechselt nach Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> runterscrollen bis „Hostnamen-Ausnahmen“. Dort die Domains eintragen und Übernehmen:
Hierzu noch der AVM KB-Artikel
Schritt 3: Einrichtung des ersten Reverse Proxies
Auch wenn dies eigentlich nicht dazu gehört, werde ich hier zeigen, wie man einen Reverse Proxy einrichtet. Wir richten diesen beispielsweise hier einmal ein, sodass wir mit einer FQDN auf die Admin-Seite des AdGuard kommen.
Dazu wechseln wir ins DSM, gehen in die Systemsteuerung unter Anmeldeportal -> Erweitert auf „Reverse Proxy“ und auf „Erstellen“:
In dem sich öffnenden Fenster tragen wir nun folgendes ein:
Wobei ihr den Namen frei wählen könnt. Das „ag“ könnt ihr auch frei wählen. Nur die Domain muss logischerweise auf euere DDNS-Adresse enden. Und falls ihr vorhin nicht Port 8080 für AdGuard angegeben habt, natürlich auch anpassen.
Dann auf Speichern drücken und die Fenster schließen.
Anschließend können wir den AdGuard erreichen über den soeben erstellten RP:
Wenn es hierzu fragen gibt, könnt ihr euch gerne in diesem Thread melden!
v2.1.1
Warum braucht man das Ganze? Einfach gesagt, weil eine https Verbindung immer von einem Zertifikat abgesichert / verschlüsselt wird. Dieses ist aber nur gültig für die Domain, für die es ausgestellt wurde. Und klassischerweise erhält man für eine IP-Adresse kein Zertifikat.
Man kann es auch einfach halten, so wie in meinem anderen Thread beschrieben (mehr dazu auch hier in diesem Thread unter Punkt 1.2.1). Mit eigenem DNS-Server ist man aber flexibler, falls man mal eine Domain / einen DDNS nutzen will, bei dem diese Option nicht gegeben ist (und das ist bei den meisten der Fall). Zudem kann man noch weitere DNS-Einträge umbiegen bei Bedarf.
Hinweis vorneweg: Wenn die DS aus ist, habt ihr kein Internet! Bitte bedenken, dass ohne DNS-Server nix mehr geht. Fahrt ihr also die DS per Zeitplan runter, ist diese Vorgehensweise eher schlecht geeignet.
HINWEIS: Keine Gewährleistung auf Vollständigkeit und 100%ige Korrektheit! Wem ein Fehler auffällt, der kann das gerne (mit freundlichem Umgangston) hier melden!
Voraussetzungen:
In dieser Anleitung wird vorausgesetzt, dass der Umgang mit der FileStation und Hochladen von Dateien aufs NAS bekannt ist und auch, wie man mit Archiven umgeht.
To Do:
Eine eigene Domain / eine DDNS-Adresse (idealerweise mit Wildcard-Zertifikat)
Hierfür werden wir synology.me als DDNS-Anbieter nutzen. Und zwar aus 3 Gründen:
1.) Der Dienst bietet Wildcard DNS (alle Subdomains werden ebenfalls auf eure ext. IP aufgelöst).
->dies ist wichtig, wenn man später doch mal von extern auf einen Dienst ohne VPN zugreifen will
2.) Die DS kann für diese Adresse ein Wildcard Zertifikat erstellen (das Zertifikat ist für die Adresse selbst und für alle Subdomains gültig).
->das brauchen wir, damit wir mit dem Reverse Proxy und Subdomains anstatt Ports arbeiten können
3.) Für die Zertifikatserstellung ist keine Portweiterleitung im Router notwendig.
->bei den meisten anderen Anbietern müsste Port 80/443 im Router offen sein.
Quelle: Synology KB-Artikel
Ein eigener DNS-Server
Als DNS-Server kommt AdGuard Home zum Einsatz, der wiederum als upstream DNS-Server unbound nutzt. Warum nicht den einfachen Synology DNS-Server? Weil man mit der Kombi gleich noch einen netzwerkweiten Werbe- und Trackingblocker obendrauf hat, der sogar (die richtigen Block-Listen vorausgesetzt) in einem gewissen Umfang vor Phishing und Malware im Heimnetz schützen kann.
Was unbound genau tut, kann man z.B. in diesem Artikel nachlesen.
Genauere Infos, warum ich die Kombi aus AdGuard Home + unbound nutze, gibt's im verlinkten Installations-Thread unter Schritt 2.1.
Anleitung
Schritt 1: Anlegen der DDNS Adresse mit Wildcard-Zertifikat
Schritt 1.1: Synology Account hinterlegen
Wir melden uns bei DSM mit einem User an, der Administratorrechte hat. Zuallererst müssen wir uns mit einem Synology-Konto anmelden in der DS, damit wir die DDNS-Dienste von Synology in Anspruch nehmen dürfen. Dazu wechseln in die Systemsteuerung -> Synology-Konto und drücken auf den Link zum Anmelden mit einem Konto:
Dann sollte sich ein neues Fenster öffnen, bei dem man sich anmelden kann, falls man schon ein Konto hat. Wenn nicht, drückt man unten auf den Link „Ein Synology-Konto erstellen“.
Hinweis: Wenn sich da kein Fenster öffnet, hat entweder ein Werbeblocker oder der Popup-Blocker des Browsers zugeschlagen. Hier hilft es vielleicht, temporär auf einen anderen Browser zu wechseln und den Vorgang erneut auszuführen.
Schritt 1.2: Synology DDNS-Adresse anlegen
Umschalten auf Externer Zugriff -> DDNS. Oben auf den Button „Hinzufügen“ drücken und in dem Dropdown „Serviceanbieter“ „Synology“ auswählen. Bei Hostname den ersten Teil der gewünschten DDNS-Adresse eintragen. Im hinteren Dropdown „synology.me“ auswählen. Hint an der Stelle: Eigentlich müsste unser Vorhaben hier mit jeder Domain funktionieren laut KB-Artikel. Früher hat dies aber nur mit „synology.me“ funktioniert und auch nur damit habe ich es getestet. Unten noch den Haken für die Zertifikatserstellung setzen. Der Rest kann so belassen werden, wie er ist:
[optional] Schritt 1.2.1: DDNS mit Boardmitteln auf interne IP biegen
Man kann in diesem Fenster die Auswahlbox hinter "Externe Adresse (IPv4)" auch direkt umstellen von "automatisch" auf "LAN X". Damit löst der DDNS bereits auf die interne IP auf, ohne dass man einen DNS-Server oder AdGuard + unbound braucht. Wenn man möchte, ist man an dieser Stelle also bereits fertig (dennoch sollte man sich den folgenden Schritt 1.2.2 noch zu Gemüte führen). Kann man machen, wenn man es einfach haben will. Alle weiteren folgenden Schritte dienen dazu, das Ganze mit dem AdGuard umzusetzen. Das kann man natürlich so mit jedem anderen DNS-Server genau so machen. Mein Favorit ist aber ganz klar der AdGuard und deshalb zeige ich das hier auch damit. Wenn man das mit einem eigenen DNS-Server umsetzt, hat man nicht nur einen Vorteil:
-man kann (bei Bedarf) für internen und externen Zugriff die gleiche DDNS-Adresse nutzen
->intern löst die Adresse auf die interne IPv4 der DS auf
->extern löst die Adresse auf die exterene IPv4 des Routers auf
-man kann bei Bedarf schnell weitere Umbiegungen vornehmen
-man ist nicht auf den Synology DDNS Dienst angewiesen (nur dieser bietet m.W. die Möglichkeit, den DDNS direkt privat aufzulösen)
Wenn ein externer Zugriff auf den DDNS (also ohne VPN) nicht gebraucht wird, empfehle ich, das hier auf die interne IP zu stellen. Denn wenn ein Client im Heimnetz aus irgendeinem Grund nicht den AdGuard verwendet, ist dann dennoch eine korrekte Auflösung gegeben. Andernfalls würde der Client auf die externe IP losgehen und der Aufruf funktioniert nicht mehr. Dann geht die Fehlersuche los.
Schritt 1.2.2: Umgang mit dem neuen Zertifikat
Wenn nun eine Meldung kommt mit dem Hinweis „Dieser Hostname wird bereits verwendet“, ist die gewählte Adresse bereits in Verwendung und muss geändert werden. So war das bei mir der Fall und ich habe „test1234“ durch „12test34“ ersetzt. Daraufhin dauert es ein paar Sekunden und das DSM-Admin Interface wird neu geladen. Möglicherweise erscheint hier der Sicherheitshinweis eures Browsers, falls ihr mit https verbunden seid. Diesen kann man aber ignorieren:
Es kann sein, dass eine Fehlermeldung von DSM erscheint, dass das Zertifikat nicht ausgestellt werden konnte, weil Ports nicht offen waren. Den Fehler kann man ignorieren. Er ist eher noch als „Relikt aus alten Zeiten“ zu sehen, zu denen man immer die Ports für Zertifikate öffnen musste.
Nun sollte man in der Systemsteuerung unter Sicherheit -> Zertifikat das frisch erstellte Zertifikat sehen. Dieses ist 3 Monate gültig und wird von der DS vor Ablauf automatisch erneuert. Wenn nicht, kann man dies aber auch manuell via „Aktion“ -> „Zertifikat erneuern“ anstoßen.
Schritt 2: Installation und Konfiguration des AdGuard
Schritt 2.1: Installation von AdGuard Home und unbound via CLI
Diesen Teil der Anleitung habe ich ausgelagert in einen separaten Thread.
Ansonsten hätte dieser Thread die Begrenzungen des Forums erreicht.
Schritt 2.2: Erweiterte Konfiguration des AdGuard Home
Jetzt tragen wir endlich unseren DDNS, den wir angelegt haben, im AdGuard als DNS-Umschreibung ein. Dazu auf „Filter“ und „DNS-Umschreibungen“, „DNS-Umschreibung hinzufügen“ klicken:
Im sich öffnenden Fenster tragen wir nun unsere DDNS-Adresse ein und darunter die interne IP der DS:
Damit der Wildcard DNS im Heimnetz funktioniert, müssen wir diesen separat anlegen, indem wir das Gleiche nochmal tun, nur dieses Mal ein „*.“ vor die Domain setzen:
Schritt 2.3: Testen
Das Ganze kann man testen, wenn man eine Eingabeaufforderung öffnet und
nslookup eingibt. Dort dann umschalten auf die DS als DNS-Server via "server IP_DER_DS" und dann kann man einmal die Domain und einmal eine Subdomain testen. Als Rückgabewert sollte er die IP der DS liefern:Bei der FritzBox ist unter bestimmten Konstellationen erforderlich, den Rebind-Schutz für die entsprechende Domain zu deaktivieren, der dafür sorgen kann, dass DNS-Antworten unterdrückt werden, die auf interne Ressourcen zeigen. Das macht man so:
Man wechselt nach Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> runterscrollen bis „Hostnamen-Ausnahmen“. Dort die Domains eintragen und Übernehmen:
Hierzu noch der AVM KB-Artikel
Schritt 3: Einrichtung des ersten Reverse Proxies
Auch wenn dies eigentlich nicht dazu gehört, werde ich hier zeigen, wie man einen Reverse Proxy einrichtet. Wir richten diesen beispielsweise hier einmal ein, sodass wir mit einer FQDN auf die Admin-Seite des AdGuard kommen.
Dazu wechseln wir ins DSM, gehen in die Systemsteuerung unter Anmeldeportal -> Erweitert auf „Reverse Proxy“ und auf „Erstellen“:
In dem sich öffnenden Fenster tragen wir nun folgendes ein:
Wobei ihr den Namen frei wählen könnt. Das „ag“ könnt ihr auch frei wählen. Nur die Domain muss logischerweise auf euere DDNS-Adresse enden. Und falls ihr vorhin nicht Port 8080 für AdGuard angegeben habt, natürlich auch anpassen.
Dann auf Speichern drücken und die Fenster schließen.
Anschließend können wir den AdGuard erreichen über den soeben erstellten RP:
Wenn es hierzu fragen gibt, könnt ihr euch gerne in diesem Thread melden!
Was ist hier noch geplant?
Aktuell steht nix mehr auf dem Zettel. Ich hab hier alles umgesetzt, was ich usrprünglich geplant hatte und bin sogar weit über's Ziel hinausgeschossen
. Wenn sich im Laufe der Zeit an den Gegebenheiten was ändert, aktualisiere ich natürlich den Thread. Genau so, wenn mir mal wieder was Neues dazu einfällt. Wenn ihr noch Anregungen habt, natürlich auch gerne vorschlagen!
Aktuell steht nix mehr auf dem Zettel. Ich hab hier alles umgesetzt, was ich usrprünglich geplant hatte und bin sogar weit über's Ziel hinausgeschossen
. Wenn sich im Laufe der Zeit an den Gegebenheiten was ändert, aktualisiere ich natürlich den Thread. Genau so, wenn mir mal wieder was Neues dazu einfällt. Wenn ihr noch Anregungen habt, natürlich auch gerne vorschlagen!v2.1.1
24-04-17 | v2.1.1
-Hinweis, dass Anleitung Fehler enthalten kann
24-01-22 | v2.1
-Layout-Anpassungen (alle "Best Practice Threads" haben nun ungefähr die gleiche Struktur)
-Fehler in der Gliederung behoben
-Beschreibungen teils verbessert
-Punkt "DDNS auf interne IP zeigen lassen" deutlich ausgebaut
24-01-09 | v2.0.3
-Agenda hinzugefügt
23-12-01 | v2.0.2
-Ergänzt: "Bei Fragen bitte melden"
23-11-02 | v2.0.1
-Grammatikfehler ausgebessert (Konkret: Fehlende Worte ergänzt )
23-07-29 | v2
-kleinere Verbesserungen
-Auslagerung Einrichtung der Docker Container wegen Übersichtlichkeit und Beschränkungen
-Bilder wieder in den Thread
-OneDrive wieder entfernt, da alle Anhänge nun hier drin sind
23-07-28 | v1.1
-Formatierungen und Formulierungen angepasst
-beide Posts zu einem zusammengefasst (damit Editierbarkeit erhalten bleibt)
-Bilder aus Post entfernt; diese befinden sich nur noch im Anhang (weil sonst zu lang)
-Link zu OneDrive Share mit Dateien eingefügt
-Hinweis, dass Anleitung Fehler enthalten kann
24-01-22 | v2.1
-Layout-Anpassungen (alle "Best Practice Threads" haben nun ungefähr die gleiche Struktur)
-Fehler in der Gliederung behoben
-Beschreibungen teils verbessert
-Punkt "DDNS auf interne IP zeigen lassen" deutlich ausgebaut
24-01-09 | v2.0.3
-Agenda hinzugefügt
23-12-01 | v2.0.2
-Ergänzt: "Bei Fragen bitte melden"
23-11-02 | v2.0.1
-Grammatikfehler ausgebessert (Konkret: Fehlende Worte ergänzt
)23-07-29 | v2
-kleinere Verbesserungen
-Auslagerung Einrichtung der Docker Container wegen Übersichtlichkeit und Beschränkungen
-Bilder wieder in den Thread
-OneDrive wieder entfernt, da alle Anhänge nun hier drin sind
23-07-28 | v1.1
-Formatierungen und Formulierungen angepasst
-beide Posts zu einem zusammengefasst (damit Editierbarkeit erhalten bleibt)
-Bilder aus Post entfernt; diese befinden sich nur noch im Anhang (weil sonst zu lang)
-Link zu OneDrive Share mit Dateien eingefügt
Zuletzt bearbeitet:
