Beiträge von Freigeist

  • Nach Controller-Update, kein Einloggen auf Webinterface möglich

    Hallo Profis,


    am Samstag fuhr ich übers Wochenende weg und kam gestern Abend zurück und bemerkte etwas merkwürdiges. Kurz vor Abfahrt arbeiteten mein Administrator und ich noch remote in meinem Netzwerk, so dass ich von unterwegs Zugriff auf das bekomme, was ich brauchte. Ihm ist aufgefallen, dass ich noch kein Update beim unifi Controller gemacht hatte. Also ich dann schon auf der Autobahn wahr, stieß er das noch an. Er sagte, danach ging es noch. Jetzt wo ich wieder physisch beim Netzwerk bin, kann ich mich mit dem gewohnten Benutzernamen und Passwort nicht einloggen.


    Bei meiner Internetrecherche bin ich über zwei Beiträge gestoßen, die mir Hoffnung gegeben hatten, dass ich mich doch aus dieser Situation retten kann.

    1.) teqqyde bei Youtube

    [Externes Medium: https://www.youtube.com/watch?v=Sl1RDyhRbt4]

    Da funktionieren die Befehle nicht bei mir. Da das Video von 2018 ist, hat sich da vielleicht auch schon ein wenig was verändert bei der USG bzw. dem Controller.


    2.) Ubuntuusers

    https://wiki.ubuntuusers.de/Un…-Reset-funktioniert-nicht

    Hier bin ich zu blöd zu ermitteln, wie der Nachfolgerbefehl von mkpasswd ist. Schaue ich mit "apt search" nach "mkpasswd", ist dieser "oldstable". Für meine Begriffe also veraltet und wird nicht mehr verwendet. Welchen Befehl man stattdessen verwendet, kann ich nicht ermitteln. Suche ich bei debian.org ("https://packages.debian.org/search?searchon=names&keywords=mkpasswd") nach mkpasswd, heißt das "neue" Paket wohl "libstring-mkpasswd-perl" welches aber ebenfalls "oldstable" ist.

    Der Dienst Mongo läuft und meinen Benutzernamen konnte ich mit dem Befehl aus der Anleitung erfolgreich ermitteln. Schritt 3/4 ist nicht umsetzbar für mich, somit stockt die Umsetzung an dieser Stelle.


    Weil natürlich alles schnell gehen musste und vieles nicht auf Anhieb klappte, gibt es für die VM auf der der Controller unter Proxmox installiert ist, kein Snapshot. Ich kann keine Angabe machen, von welcher Version auf welche Version geupdated wurde. Das Betriebssystem der VM ist ein Debian mit (uname -r) 4.9.0-15 amd64

    Unifi Cloud Gedöhns lehne ich ab, Zugangsdaten zu wichtiger Hardware im Unternehmensnetzwerk haben nichts im Internet zu suchen. Egal in welcher Form auch immer.


    Hat einer von euch in letzter Zeit ein Passwort nach einem Update wieder herstellen müssen? Sind meine Ansätze vielleicht doch nicht so falsch?

    Über Tipps, Tricks und alles weiterem danke ich schon Mal im voraus.


    Gruß Freigeist

  • Zu blöd um Firewall-Regel zu erstellen

    Ich freue mich, dass jetzt Regeln existieren, mit denen das Routing von der Domain bis zur richtigen Maschine im Netzwerk richtig funktioniert.


    Kurzanleitung

    Sub-/ Domain

    - Beim Domainanbieter Domains oder/oder Subdomains anlegen.

    - Ist das Ziel "Zuhause" hinter einer einem Router mit dynamischer öffentlichen IP, dann den A-Record einschalten und ...

    - ...die IP Adresse von "Zuhause" aus, beim Domainanbieter, mittels automatismus regelmäßig updaten lassen. Entweder Domainanbieter fragen (IONOS hat eine Anleitung für eine Ubuntu-VM) oder vielleicht eine Hardware nutzen wie eine Fritzbox oder ähnliches.


    Mehrere Sub-/Domains und unterschiedliche Maschinen mit verschiedenen IP's

    - Reverse Proxy im eigenen Netzwerk verwenden. In meinem Beispiel stellt ein Synology NAS ein paar Webseiten bereit und bringt von Haus aus einen Proxy-Server mit.


    USG-Firewall-Regeln

    Da ich weiss, dass nur Webseiten aus dem Internet abgefragt werden sollen, spielen die Port 80 und 443 die Hauptrolle. Daher, ungeachtet welche Subdomain aus dem Internet kommend nach der Webseite im Netzwerk fragt, werden alle 80/443 - Anfragen an den Reverse Proxy weiter geleitet. Weil ich mit der neuen Ansicht noch nicht klar komme, beschreibe ich hier das alte Menü: Setting --> Routing & Firewall

    Unter Firewall --> IPv4

    Keine Einträge. Alle hier stehenden Einträge werden vom Controller erzeugt.


    Unter Port Forwarding


    Reverse Proxy

    Beispiel Domain-Anfragen immer verschlüsselt benutzen.


    Subdomain


    Wenn man die Webseite nun aufrufen möchte, gibt es noch verschiedene Dinge zu beachten.

    - Zertifikat an allen notwendigen Stellen hochgeladen und verknüpft?

    (Bsp.: Synology, Systemsteuerung --> Sicherheit --> Zertifikat, Sub-/Domain mit Zertifikat verknüpfen)


    - Im Browser kann die Webseite intern mit der IP-Adresse angesprochen werden oder mit der Domain-Adresse. Diese Angaben werden in den entsprechenden Trusted-Domain Konfigurationsdateien eingetragen.


    - Wenn eine Nextcloud im Internet erreichbar sein soll, kann es sein das die unter Linux in /var/www/html/nextcloud abliegt. Der Webserver sucht die Webseite voreingestellt jedoch standardmäßig unter /var/www/html/ Das bedeutet, die Nextcloud wird im Browser als http(s)://IP-oder-domain/nextcloud/index.php angezeigt wird. Um http(s)://IP-oder-domain/index.php zu bekommen, muss man den Verzeichnispfad in der Konfigurationsdatei anpassen.

  • Zu blöd um Firewall-Regel zu erstellen

    Danke PeGaSuS das auch Du dich mit einbringen möchtest.

    Bezüglich den Firewall-Regeln, die wurden alle automatisch erzeugt, die sind nicht auf meinen Mist gewachsen. Das gedropt wird ist ja soweit in Ordnung. Solange die Ports freigemacht werden, die ich öffnen möchte (also 80 und 443) oben drüber stehen und somit vorrang zu drop haben, ist ja alles gut. Aber, wie wir sehen, wird die Regel unter dem drop erzeugt. uboot21 , da die Regeln nicht von mir sind und ausgegraut, kann ich die auch nicht mit dem Kreuz verschieben. Auch bearbeiten und löschen ist für mich verboten.


    PeGaSuS , beide Portweiterleitungsregeln (80, 443) sind als both (tcp und udp) eingerichtet, weil ich einfach nicht weiss, was da tatsächlich die einzelnen Dienste für Protokoll verwenden werden. Deine Absätze mit DROPZONE und Kundenzufriedenheit habe ich noch nicht verstanden. Tut mir Leid.


    uboot21 , danke für den Link bezüglich den Speicherorten. Leider tauchen in /var/log/messages keine Firewall-Einträge auf, wenn ich mit dem Smartphone über das mobile Internet auf meine Domain.de:80 zugreife. Nach kurzer Zeit erhalte ich ein Time-Out.

    Die IP-Adresse wird im übrigen regelmäßig bei meinem Domainanbieter aktualisiert. Wie bereits gesagt, an der Stelle liegt das Problem nicht. Ich sehe es nach wie vor in der Reihenfolge der Firewall-Regeln. Für mein Verständnis wird erst gedropt und die gewollte Weiterleitung ignoriert.

  • Zu blöd um Firewall-Regel zu erstellen

    Zitat von JS86

    Über "Konfigurieren" kannst du dann dem Zertifikat deinem Reverse-Proxy-Eintrag zuweisen.

    Ich habe vom Domainanbieter ein Zertifikat erhalten welches ich in die Synology geladen habe. Von daher verzichte ich an dieser Stelle auf Lets Encrypt.


    Wegen dem Reverse-Proxy hätte ich noch eine Anmerkung. Nicht für euch, aber für eventuell ein anderer unbedarfter Leser der auch nach Orientierung sucht. Unter Konfigurieren taucht der (Sub-)Domaineintrag des Reverse-Proxy nur auf, wenn man Port 443 ausgewählt hat aber nicht bei Port 80. Logisch, wenn man entspannt darüber nachdenkt und richtig schlussfolgert.

    Zitat von JS86

    Bitte möglichst https verwenden und nicht http für den Zugriff von extern!

    Ich habe jetzt zwei portforwardings eingestellt. Einen für Port 80 und einen für 443. Beide zeigen zur Synology bzw. proxy-Server.

    Und siehe da, es wird wieder automatisch zuerst gedropt, dann kommen die Weiterleitungen. Was mache ich da falsch?

  • Zu blöd um Firewall-Regel zu erstellen

    Ja, für eines nach dem Anderen wäre ich auch. Aber das hatte bisher ja auch noch nicht klappen wollen, deswegen sind so viele Fehlermöglichkeiten im Kopf.


    Also prinzipiell bin ich auch dagegen Ports nach außen auf zu machen. Daher begrüße ich den Reverse Proxy ausdrücklich. Ich dachte so etwas geht nicht, weil ich das Erkennen der Subdomain durch den "Profi-" Router (USG) nicht gefunden hatte. In meiner Vorstellung würde ich beim Port Forwarding die Subdomain eintragen und den Server als Ziel. Aber naja, is ja für Profis und nicht für Leihen wie mich gedacht.


    Warum beim letzten Konfigurierversuch die eine Regel nicht rausgelöscht wurde, obwohl alle anderen Regeln gelöscht waren, ist jetzt auch geklärt. Wenn alle Regeln gelöscht sind, muss man erst die Webseite neu laden damit unter Firewall --> Firewall --> IPv4 --> WAN in auch die ominöse Regel weg ist. Also JETZT sind gerade KEINE Regeln angelegt und es sieht "sauber" aus.


    Ich habe kein doppeltes NAT. Die USG ist mit einem Netzwerkkabel mit dem Glasfasermodem der Telekom verbunden und wählt sich mit Zugangsdaten ins Internet ein. Aktuell ist zwar noch eine Fritzbox als Client im Netz, dient aber nur als WLAN-Zugang für Smartphones oder Notebooks die kurzzeitig nichts mit Kabel verbunden sind. Spielt also keine Rolle. Und ja, ich habe keine statische IP-Adresse sondern eine VM, die ständig die aktuelle öffentliche IP-Adresse bei meinen Domains aktualisiert. Wer den Fachbegriff braucht: DNS-Record. Ich gehe also davon aus, dass wer die (Sub-)Domains aufruft auch zum WAN in der USG kommt.


    Die WLAN-MobileDaten-Problematik ist mir bekannt und beachte ich auch. Ich nutze dann tatsächlich das Smartphone und die Chrome-Browser-App oder alternativ den Firefox. Sollte mein Instinkt misstrauisch werden, dann steht auch Brave und Opera zum testen bereit. Ansonsten nutze ich auch Mal online nmap wie den hier: https://www.itexperst.at/online-portscanner-nmap Also immer schon von außen gucken was geht, ist mir klar.


    Das Logging würde ich solange machen wollen, bis ich mir sicher bin das alles so läuft, wie ich das haben will. Ein Log würde mir helfen Fehler zu suchen, bin ja schließlich kein Profi. Daher würde ich mir die Logs gerne anschauen. Wo finde ich die?

  • Zu blöd um Firewall-Regel zu erstellen

    Oh, entschuldigung. Ich habe IPv4 (zum Glück. IPv6 bin ich noch kein Freund von).

    Ich habe nun alle meine Regeln und Gruppen zu denen ich genötigt wurde anzulegen wieder gelöscht. Dabei ist aufgefallen, dass er eine Regel (auf die ich keinen Zugriff habe) nicht gelöscht hat.

    Wie lösche ich die unterste ausgegraute Regel?


    Dann habe ich im Port Forwarding die Weiterleitung zur Synology eingerichtet. Probiert hatte ich es zuerst mit Port 5000 --> 5000, das klappte nicht. Dann habe ich 80 --> 5000 eingestellt weil ich dachte im Browser mit domain.com direkt zur Synology-NAS Oberfläche zu kommen. Pustekuchen.


    Und bitte wo finde ich das logging-Protokoll ?

  • Zu blöd um Firewall-Regel zu erstellen

    Danke Uboot21 für deine Antwort.


    Weiterleiten in Firewall

    Wenn eine Anfrage aus dem Internet von sub1.domain.com:5000 kommt und möchte in dem Fall mit der Synology (DS918+) reden, wie kann ich der Firewall denn "sub1.domain.com" mitteilen? Oder in deinem Beispiel das " *.domain.com " zum Reverse Proxy weitergeleitet werden sollen? Ich sehe lediglich nur die Möglichkeit die Anfrage mittels der Portnummer zu unterscheiden. Also "Wenn Anfrage an WAN mit Port 5000 dann Destination synologyIP:5000"


    Synology und Reverse Proxy

    Ich habe eben auf der Synology DS918+ zum Testen und verstehen den "Proxy Server" installiert. In der App ist aber nichts zu sehen lesen von "Reverse". Reverse-Proxy ist doch nicht das Gleiche wie Proxy-Server oder?

  • Zu blöd um Firewall-Regel zu erstellen

    Guten Morgen zusammen,


    ich bin neu hier im Forum und habe mich erst einmal umgeschaut, ob es bereits mein Thema gab oder nicht. Ich muss gestehen, irgendwie ist das Forum unübersichtlich. Auch eine Suchfunktion habe ich nciht gefunden. Vielleicht muss ich mich nur erstmal daran gewöhnen und stolpere irgendwann durch Zufall darauf und schwupp die wupp hat sich eine neue Dimension aufgetan. Auf jeden Fall Danke das es diese Anlaufstelle und euch hier gibt.


    Mein Netzwerk-Szenario:

    Ich habe zwei Domains und beide leiten den Verkehr "zu mir nach Hause" um an die USG. Hinter der USG sollen mehrere Webseiten auf einer Synology angesprochen werden können, sowie ein paar Nextclouds als VM in einem Proxmox und ein VPN-Server.

    Zum Test habe ich eine Nextcloud aufgesetzt mit der ich Talk testen wollte. Ich Netzwerk-intern, Gesprächspartner übers Internet. Nun scheitere ich offensichtlich an der Firewall, denn ich bekomme es einfach nicht hin, dass wenn die DomainA aufgerufen wird, die Nextcloud geladen wird, damit sich der Gesprächspartner einloggen kann. Meine aktuelle IP-Adresse wird ordentlich automatisiert bei IONOS aktualisiert, daran liegt es schon Mal nicht.


    Was habe ich zu denken, wenn ich eine Regel erstelle?

    In meiner Vorstellung kommt da eine Anfrage (meine_akuelle_IP_Adresse:Portnummer80_oder443) an den WAN-Port an. Diese muss ich akzeptieren wenn es TCP-Pakete sind. Desweiteren muss ich als Destination noch die IP-Adresse der Nextcloud angeben. Hier habe ich es mit und ohne Portnummer versucht, beides gescheitert.


    Anderes Vorgehen wenn Subdomains verwendet werden?

    Ich weiß, dass ich mit Subdomains arbeiten muss. Allerdings muss ich gestehen, dass ich noch keine Vorstellung davon habe, wie da das Routing funktionieren soll. Alle Subdomains verweisen auf die gleiche IP-Adresse wo als erstes die USG lauert. Und ihr erzählt keine Anfrage, von welcher Subdomain sie kommt. Und in der Firewall habe ich auch keine Möglichkeit gesehen, dass man genau diese Subdomain als source eintragen könnte, damit man easy zur richtigen Webseite weiterleiten könnte. Was habe ich da noch zu beachten?


    Entschuldigung das es jetzt vielleicht etwas länger geworden ist, aber das sind so ziemlich alle meine Gedanken dazu und leider auch kein gelernter IT-ler. Dennoch vielen Dank im voraus.

    Freigeist