Wartunng DG 28.05.2020

Aus Windeln Wiki
Zur Navigation springen Zur Suche springen

Anfrage 27.05.2020

Gegen 16 Uhr den DG Support gebettet den Anschluss in den BridgeMode zu versetzen. Dies geht laut Mitarbeiter nur Nachts. Zudem hat er mehrfach versichter, dass man am Router nichts einstellen muss. Lediglich Lan 1 des DG Modems mit WAN (1) des Routers verbinden. Recht kommt von alleine. Auch ipv6 soll einfach so funktionieren, ohne VLAN ID oä Die SIP Zugangsdaten sollten am nächsten Tag erfragt werden.

Vorbereitungen 27.05.2020

Installation der Hardware

Der Unifi USG wurde hier bereits an Port LAN 1 des DG Modems gesteckt, damit die Konfiguration in der Nacht bereits klappt. Ebenfalls wurde direkt die USV, der Cisco SPA 112 und der Switch installiert. Der Fernseher wurde am DG Router ausgezogen und dort wie bereits erwähnt die USG eingesteckt. ALle übrigen Kabel blieben bis zum nächsten morgen im DG Router. Naming: Der DG Router wurde über Nacht zum DG Modem.

Vorbereitung der Software

Da ich dem Mitarbeiter nicht vertraut habe, habe ich die VLAN ID, welche ich laut Internet gefunden habe. VLAN ID 362. Ebenfalls wurde einige Wochen zuvor in der Firewall der Server freigeschaltet & Netzwerke mit DHCP hinzugefügt.

Umstellung am 28.05.2020

Lage am Morgen

Wie erwartet kein Internet, da noch kein Gerät mit der USG verbunden ist. Die USG hatte ebenfalls kein Internet. Es stellt sich raus, dass die VLAN ID falsch ist. Nach dem entfernen der VLAN ID hat die USG sehr schnell eine IPv4 Adresse bekommen und auf dem WAN Port auch eine IPv6 Adresse. Nun funktioniert das Internet IPv4 only.

DHCPv6

Hier wurde mehrfach mit Mitarbeitern von DG gesprochen. Der erste sagte, es muss so klappen, keine Ahnung. Der zweite gab mir die VLAN ID 362, wie im Internet. Nach dem Eintragen der VLAN ID war direkt das Internet weg. Also wieder entfernt. Der dritte Mitarbeiter hat mir eine IPv6 Adresse gegeben: 2a00:6020:15e8:bf00::/56 (Okay es ist ein ganzes Netz, aber er sagte Adresse :-D ). Diese solle ich eintragen. Wo auch immer. Es wurde sich immer rausgeredet mit wir leisten keinen Support für Kunden Router. Das ist ja auch verständlich. Ich möchte nur eine Erklärung haben wie ich das ganze Konfiguriere wenn ich keine Fritz!Box besitze (diese Supporten sie ein bissen, da viele diese haben). Konnte mir keiner geben. Daher wurde die Konfigurationsdatei (Unifi-ipv6-gateway-json) genutzt. Dies gab meinen beiden Dell Notebooks mit etwas Verzögerung eine IPv6 Adresse. Hier stellte sich heraus, dass IPv6 RA (Router Advertisement) gebraucht wird. Dies ist in Unifi für das Lokale Netzwerk zu aktivieren. Hier werden 2 Arten von IPv6 Adressverteilungen erklärt. Anscheinend geht es auch ohne IPv6 RA, daher ist es wohl in Unifi optional zu aktivieren. Wenn ich alles Richtig verstanden habe, nutzen wir jetzt SLAAC, hier bekommt ein Gerät den Prefix und berechnet mir der MAC-Adresse zusammen die IPv6 Adresse für sich selbst und KEIN DHCPv6(?!).

Diese Datei ist aktuell ohne die Firewall Einstellungen deployt. Diese waren alle Standardmäßig aktiv, bis auf icmpv6. Diese wurden manuell hinzugefügt. Zukünftig soll eine Konfiguration ohne Datei versucht werden.

Unifi nutzt "nur" ein /64 Netzwerk bei IPv6 Prefix Delefation. Dies ist soweit ich das beurteilen kann nicht schlimm. ALlerdings bekommt zB der Server so eine andere Adresse als wenn ein /56 Netz in der Gateway konfig steht.

Der lokale DHCP(v4) vom Server hat Probleme gemacht. Zuerst falscher Gateway, später falsche / nicht existente DNS Server. Schlussendlich wurde er deaktiviert, da ein stoppen nach einen Neustart erneut ausgeführt werden müsste.

Lage Mittags

Gegen 11.30 fühlte sich das Netzwerk soweit halbwegs stabil an. Es werden IPv6 und IPv4 Adressen vergeben. Auf den DG Support wurde verzichtet. Ebenfalls war der Server erreichbar (lokal). DNS Einträge, Apache IP konfiguration und die Feste-IP Konfiguration wurde angepasst. Der RDP Server wurde komplett ausgelassen, da nicht so relevant.

Zwischenzeitlich habe ich ein "sudo ifdown enp7s0 && sudo ifdown enp7s0" auf dem Server abgesetzt, anschließend diesen abgeschossen. Keine Probelem anschließend. Einzig nahezu alle Docker Container sind aus mir unerklärlichen Gründen nicht gestartet, ist aber unproblematisch.

Der Server war nicht von außerhalb erreichbar. Ab hier wurde es sehr zäh. Gegen 14 Uhr bemerkte ich, dass die Firewall nicht auf dem Gerät genutzt wird: mca-ctrl -t dump-cfg

show liefert ganz nebenbei sehr coole Informationen vom USG, alles per Tab zur Autovervollständigung.

Hierzu wurde wie oben erwähnt die Firewall aus dem config-gateway.json entfernt. Anschließend hätte die Firewall funktioniert. Aber durch das entfernen der Firewall aus der konfig hat sich Unverständlicherweise auch das Subnetz für IPv6 PD auf /64 geändert (dank Unifi). Dadurch auch die IP vom Server, da sich nur 2 zeichen geändert haben, wurde dies erst spät bemerkt. Nach Anpassung der Firewall, des DNS, Apache IP config, und Feste-IP ging es dann.

Aktuell sind 22, 80, 443, 3389, 15922 (git ssh), 25565, 25566 freigeschaltet auf TCP und UDP (evtl kann man das noch aufsplitten. Um noch weniger Ports zu öffnen. Ebenso ist 10533 offen solange es keinen lokalen DNS als Abkürzung gibt. Dort läuft ein Node.js Programm für Alexa.

Zuvor wurde auf Docker ein sudo docker system prune ausgeführt. Dies hat alle gestoppten Container und alles zugehörige gelöscht. Kein Problem, da es das docker.sh Skript gibt. Welches Wöchentlich fast alle Container pullt und neu startet. Hier stellte sich heraus welche fehlen:

  • duplicati
  • rclone
  • alle aus Gitlab (aktuell min. 2)

folgende fehlten unerwartet und müssen angepasst werden:

  • gitlab (in docker.sh)
  • minecraft (in docker.sh)
  • minecraft rcon (restart always)
  • torrent (in docker.sh)
  • phpmyadmin (in docker.sh)

Lage Nachmittags

Gegen 17.00 Uhr wurden Speedtest vollzogen. Hier fiehl aus dem Keller eine 100Mbit Begrenzung auf. Zunächst hatte ich Angst, dass der Anschluss zurück gestellt wurde auf 100/100 da ein Support Mitarbeiter etwas komisches diesbezüglich sagte. Ein Speedtest auf der USG selber ergab ca. 200/200. Das ist aber immer noch nicht 400/200. Die USG schafft leider einfach nicht mehr. Später stellt sich heraus, dass das Kabel zwischen Wohnzimmer Switch und Anbau Switch auf "Pin" 7 kein Signal bekommt und auch die Switche nur 100Mbit durchlassen/erkennen. Nach austausch des Kabels wurde mittels Iperf 1000/1000 zwischen Wohnzimmer und Server festgestellt. Ebenso bestätig Iperf zwischen Server und Contabo Server einen 200Mbit Upload und einen 400 Mbit download.

Ein weiteres Telefonat mit einem DG Mitarbeiter sollte mir die SIP Zugangsdaten erbringen. Diese sollten laut Mitarbeiter am morgen erst gegen Mittag vorliegen. Dieser konnte mir den bereits erhaltenen Username bestätigen und das Passwort durchgeben (hat gut geklappt, wirkte aber umständlich gekrampft). Nun brauchte ich noch einen Proxy (so heißt es im SPA 112). Letzendlich eine URL für SIP. Mit URL oder Proxy konnte der Mitarbeiter nicht anfangen. Wollte meinen Router wissen, dieser kann aber kein SIP, also erklärte ich und nannte den Cisco SPA 112. Der Mitarbeiter setze mich auf Musik und kam nach einigen Minuten mit einer Rückfrage zurück was genau ich nun von ihm haben wolle. Eine URL eben. Da wo sich das Geröt mit Username / Passwort anmeldet. Er setzt mich auf Musik. Ich habe inzwischen die DG Doku durchforstet und die URL gefunden (dg.voip.dg-w.de). Ich dachte halt, dass der Mitarbeiter mir diese kurz hätte nennen können wenn ich ihn einmal am Apparat habe, dem scheint nicht so. Der Mitarbeiter meldet sich wieder und sagt, dass er mir nicht helfen kann. Ich frage ihn ob ich dann nicht telefonieren kann? Seine Antwort war dass er nur bei einer Fritz!Box weiter wüsste. Ich stellte nochmal klar, dass ich keinen Support für meinen eigenen Router haben möchte sondern nur die Zugangsdaten brauche. Er verschwand wieder in der Musik. Nach ca 15 Minuten brach, wie bereits jedes Mal zuvor, das Gespräch ab, ich erkenne langsam ein Schema DG!! Zusammenfassend habe ich den DG Support Mitarbeitern alles aus der Nase gezogen und der einzig Hilfreiche war der am 1. Tag er sagte ich brauche keine VLAN ID oder andere Einstellungen -> stimmt es geht ohne, mit kriege ich keine IP. Leider hatte er nicht ganz Recht damit, dass ich um 9 Uhr locker mit dem Home Office starten kann. Das ist aber mehr mir und dem komplexen Netzwerk zu Schulden. Ansonsten war nur die Übermittlung der Zugangsdaten hilfreich, bei allem anderen ist keine Information raus gekommen die mir weiter hilft. Leider sehr schwach. ABER für den 0815 Fritz!Box Kunden würde es reichen. Ebenso konnte man sich mit den Mitarbeitern gut unterhalten. Alle haben akzentfrei und deutlich gesprochen.

Lage Abends

Die Zugangsdaten fürs Telefon wurden eingegeben und es klappt auf Anhieb. Vorwahl musste keine Konfiguriert werden. Das Gerät bzw. die Webseite soll noch genauer unter die Lupe genommen werden hinsichtlich Konfigurationsmöglichkeiten. Der RDP Server musste manuell gekillt und neugestartet werden. Er bekam neue IPs und wurde mittels IP Scanner gefunden. Als erstes Gerät wurde die IP statisch in den USG dhcp eingetragen und sowohl Feste-IP als auch der DNS mit der neuen IPv6 Adresse gefüttert.

Nun läut erstmal alles und ich kann aufatmen. Einige Dingen fehlten aber immer noch. Zunächst wurde die Gesamte Verkabelung geordnet und das Ausgetauschte Kabel richtig verlegt. Hier werden in den Kommenden Tagen noch Kabelkanäle angebracht. Ebenso wurde die GPU, Bildschirm, Tastatur wieder vom Server entfernt. Dieser hatte zwischenzeitlich Probleme, da /etc/network/interfaces angepasst wurde. Dies war nicht nötig und wurde zurück geändert.

Gegen 22.30, nach guten 16 Stunden ... Stimmt ich denke es klappt auf anhieb.

Und so bin ich immer noch mit einer Liste an TODOs ins Bett gegangen.

Hier wollte Alexa weder mit Harmony noch mit Hue reden, das Problem lag aber wahrscheinlich auf der Seite von Amazon.

Nacharbeiten 29.05.2020

Der ESP an der Haustüre / Wlan Bewegungsmelder hat sich wohl selbst wieder gefangen und musste nicht angefasst werden. Nextcloud hat ein neues Docker Netzwerk bekommen, damit musste sowohl die WhiteList als auch die Samba IP Freischaltung angepasst werden.

Was hat das ganze jetzt gebracht?

  1. Ich kann mein Subnetzerweitern (weils geht, nicht weil ichs brauch!)
  2. Mehr Sicherheit und eine gut Konfigurierbare Firewall
  3. Bei dem genexis live titanium gibt es sehr hohe Speicherzeiten und eine noch langsamere GUI mit deutlich weniger Konfigurationsmöglichkeiten gerade hinsichtlich Firewall
  4. Ebenso gabe es keine Statistik oder Analyse Möglichkeiten
  5. Vorbereitungen für die Mitnutzung des Internets von Haarener Straße 31
  6. Bilder sagen mehr als 1000 Worte:

Traffic Stats Chromecast Chromecast Apps Chromecast

Ausblick

Was steht noch an:

  • Webseite (Windeln.nrw) bzgl. der IP Adressen anpassen (vielleicht kann man hier einen DNS nutzen?)
  • Docker konfiguration überarbeiten
    • fehlende bereits erwähnte Container
    • Das Interface mac0 muss immer noch manuell angepasst werden, da zum Zeitpunkt @reboot von cron noch kein Netzwerk zur Verfügung steht, ein sleep 15s in Bash half spontan auch nicht.
  • IP Zuweisungen


  • Firewall noch weiter optimieren
  • Frage prüfen: "Brauche ich komplett gemanagte Switche für die UAP APs für VLANs)
  • Einführen eines IOT Netzwerks
  • Erweitern der Subnetzmaske (weils geht!)
  • Tests für die Erweiterung des Netzwerks (wie viel kann ich mit den 5 Port Unifi flex Switchen machen?)
Abgerufen von „https://wiki.windeln.nrw/index.php?title=Wartunng_DG_28.05.2020&oldid=65“