Beiträge von frank_m

    Müsste ich die TCP Dumps in der Openwrt VM oder auf dem Proxmox Host

    So nah wie möglich an der Hardware. Also auf dem Host und dann direkt auf das eth device (oder wie auch immer es bei dir heißt). Nimm es vorher aus der Bridge raus.

    Da die DG mittlerweile im Kundenportal die Möglichkeit bietet, einen eigenen ONT zu aktivieren, sollte man diese Möglichkeit auch nutzen, anstatt zu versuchen, den DG-ONT zu "klonen".

    Spielverderber. 8o

    In welchem Gerät betreibst du das SFP Modul denn? Da wird ja irgendein Windows oder Linux drauf sein, und dann wäre tcpdump oder Wireshark das Mittel der Wahl. Router Advertisements müssten ja kommen, und dann kann man analysieren, ob irgendwelche VLAN Tags gesetzt sind.

    Wenn Glasfaser von der Installation eine zu große Herausforderung wird, könntest du natürlich über Telefonleitungen nachdenken, die du dann "G.hn" Modulen bestückst. Man wird wohl nicht auf 1 GBit/s kommen, aber ich denke, über eine dedizierte Telefonleitung sind mehrere 100 MBit/s recht stabil drin, jedenfalls deutlich stabiler, als über Stromkabel.

    Ich habe für deine EInstellung und deine Äußerungen wirklich keinerlei Verständnis. Da muss ich die Anbieter einfach mal in Schutz nehmen.


    ann soll der Laden doch erstmal ds fertig machen, was er (die UGG) angefangen hat, statt immer mehr Baustellen aufzumachen, aber nichts wirklich fertig zu stellen? - Was soll das?

    Unsinn! Das sind doch vollkommen unterschiedliche Gewerke. Soll der Tiefbautrupp 9 Monate in der Pausenhalle versauern, während man auf die Fertigstellung der Vermittlungstechnik eines Ausbaugebietes wartet? Nein, natürlich ziehen die schon ins nächste Gebiet. Und Planung und Antragsverfahren laufen schon fürs übernächste. Also da ist deine Vorstellung von der Vorgehensweise einfach nur naiv. Sorry, anders kann man es nicht sagen.


    Man könnte das auch in Nachhinein klären, aber so läuft die UGG, bzw die Porenziellen-Neukunden sehenden Auges im schlimmsten Fall in eine Unterversorgung (alter Anbieter weg, da gekündigt - Glasfaser aber noch nicht da.)

    NEIN! Einen Tarifwechsel macht man AUF JEDEN FALL so, dass man den neuen Anbieter beauftragt und ihn die Kündigung beim alten Anbieter machen lässt. Sonst funktioniert die Rufnummernportierung möglicherweise nicht, und auch die Übergabe nicht. Das steht so in jedem Ratgeber, und auch bei der BNetzA. NIEMALS selber kündigen!!!


    Es ist kein Wunder, dass ihr unzufrieden seid, wenn ihr mit so merkwürdigen Vorstellungen und Annahmen an die Sache herangeht.

    Der Stern ist dazu da, die IP-Adresse und den Port des Verbindungsursprungs nicht einzuschränken

    Ja, aber seine Eingabe wird standardmäßig von der Adressvalidierung des Webfrontends abgelehnt, zumindest bei IPv6. Warum also nicht mal eine gültige IPv6 Adresse probieren? ::0/0 oder sowas? Oder meinetwegen auch ausgeschrieben.


    Und bei den Ports wird die Eingabe augenscheinlich durch eine "0" ersetzt, was zumindest bedenklich stimmt. Wenn das 1:1 an die Generierung der Regel übergeben wird, dann kann da sonstwas rauskommen, weil ein angeforderter Port "0" durchaus zu einem ein zufällig zugewiesenen Port führen kann - je nach Implementierung.

    Wie sicher sind wir uns denn, dass die in der GUI eingegebenen Regeln zu dem passen, was dann im System erzeugt wird?

    es sieht ja wohl so aus denke ich, als ob das dg netz den dg router nach ablauf kurzer zeit nicht mehr versorgt.

    Danach sieht das für mich überhaupt nicht aus. Ich würde sagen, dass die connection tracking Tabelle Zeit ihre Gültigkeit verliert. Das erklärt die temporären Einflüsse, die du siehst, am besten. Da ihr durch Manipulation Einträge erzeugt habt, die die GUI eigentlich nicht zulassen will, kam mir der Verdacht, dass es daran liegen könnte. Deshalb der Versuch ohne Regeln.

    Warum macht der Laden (die UGG) dann Versprechnungen, die nicht zu halten sind

    Weil die das zu dem Zeitpunkt selber noch geglaubt haben. Die dramatische Entwicklung der letzten Monate in der Versorgung mit Rohstoffen und Elektronik konnte niemand voraussehen. Du erwartest morgen eine Lieferung und bekommst heute die Nachricht, dass nur die Hälfte kommt - oder auch gar nichts.


    Und jetzt schenkt euch die UGG reinen Wein ein, und was ist die Konsequenz? Eben. Und wie wäre sie gewesen, wenn sie das früher getan hätten? Genau so. Ich kann den Frust verstehen, aber mit der Situation kann man nur konstruktiv vorgehen. Die sind bei der UGG auch frustriert. Dein Verhalten bescheunigt gar nichts, eher im Gegenteil. Da sollte man sich als Kunde fragen, was man will: Meckern oder schnellstmöglich einen Glasfaseranschluss. Das schließt sich schnell mal gegenseitig aus.

    Ich installiere zwei WG Clients, einer auf dem Handy, einer auf dem RP im Heimnetz.

    Bei WG gibt es diese strikte Trennung in Server und Client nicht. Es gibt zwei Knoten, die miteinander kommunizieren können. Je nach Konfiguration kann es dann auch Knoten geben, die Datenverkehr zwischen anderen Knoten weiterleiten.

    Ich installiere einen WG Server auf dem VPS und das nicht unter root

    Doch, unter root. Alles andere funktioniert nicht.

    und wie schließe ich den SSH zugang?!

    Hoffentlich gar nicht. Sicher ihn ab, verlege ihn auf einen zufälligen Port, aber deaktiviere ihn niemals. Er kann im Zweifel die letzte Möglichkeit sein, den VPN Tunnel wieder zum Leben zu erwecken.

    Ich denke ich würde hier auf einen Strato Server im Moment mit für 5 Euro setzen... der hat auch PLESK

    Der Server ist ungeeignet.

    Man kommt deutlich günstiger an hinreichende Produkte, bei 1&1 oder netcup zum Beispiel. Wichtig ist: Du brauchst echten root Zugang mit der Möglichkeit, Kernelmodule zu kompilieren. Sonst läuft wireguard nicht vernünftig. Achte also auf Begriffe wie "KVM Virtualisierung", das ist gut. Schlecht sind hingegen Technologien wie "Virtouzzo" oder "OpenVZ". Letztere werden häufig zusammen mit Plesk angeboten und kommen auch auf deinem verlinkten Produkt zum Einsatz.

    Aber wie sage ich dem Server das er quasi durchrouten soll?!

    Er muss IP forwarding aktiviert haben, ggf. für IPv4 und IPv6, falls du beides nutzen willst. Außerdem müssen die Firewall Regeln ggf. entsprechend ausgelegt werden.

    Auf dem RP Client muss ich dann noch wie bei Tailscale das interne Netzwerk freigeben

    Wenn du es selber einrichtest, musst du auf dem VPS und dem Handy dafür sorgen, dass sie das Netz finden, aber nicht auf dem Raspi. Der Raspi muss ähnlich wie der VPS IP Forwarding machen, da er zum Router wird. Das muss er jetzt für Tailscale auch schon.

    Bei Tailscale kann man einfach den DNS der Frizbox angeben und dann lüppt das für alle Clients...

    Einen DNS Server kannst du auch bei wireguard direkt mitkonfigurieren. Aber sei dir bewusst, dass das dann für alle DNS Anfragen gilt, und damit ggf. "normale" Internetverbindungen zeitlich negativ beeinflusst, weil die DNS Auflösung länger dauert (sie muss ja durch den Tunnel). Das ist bei Tailscale übrigens auch so.

    Was brauch ich noch?!!!

    Im Heimnetz müssen die Clients wissen, dass das VPN Netz auf dem Raspi erreichbar ist. Tailscale scheint mit NAT zu arbeiten, weil das offenbar "einfach so" funktioniert. Darum musst du dich bei wireguard selber kümmern.

    Ja, die Beschreibung bestätigt im Grunde meine schlimmsten Befürchtungen. Es sind genau die sensiblen Informationen, die zum Verbindungsaufbau nötig sind, die bei denen hinterlegt sind. Da wage ich in aller Form zu bezweifeln, dass ein offener IPv6 Port im Heimnetz das größere Sicherheitsrisiko ist.


    Since users do not have a separate Tailscale account, there is no way for it to be hacked, adding an extra layer of security.

    Ah, ok, der Account kommt über Google, also kann man ihn nicht hacken. Der Schluss ist ... mutig. Vielleicht kann der individuelle Account bei denen nicht direkt gehackt werden, aber dann arbeiten sie mit SSO Methoden und Authentifizierungstoken. SSO ist komfortabel für den Benutzer, weil er sich nur einmal Zugangsdaten merken muss. Ein zusätzliches Sicherheitsmerkmal ist es nur bedingt. Auch ein Server, in den man sich per SSO einloggt, kann unsicher sein, und damit können sensible Nutzerinformationen im Falle einer Attacke abfließen.


    Also durch das Doppelte NATen bei eiem DG-Anschluss, also einmal die öffentliche IP der DG ins DG Netzwerk und dann nochmal das NATen ins Heimnetz über die Fritzbox... sollte das Endgerät nicht scanbar sein... und damit auch nicht anfällig auf Attacken...

    Du vergisst IPv6, da ist nichts mit NAT. Aber auch da hilft eine geeignete Firewall. Das ist verhältnismäßig einfach, und vor allem: Du hast es selbst in der Hand.


    Wie gesagt, ich starte einen Client auf dem Raspi und keinen Server und da ich auch kein Port-Freigegeben habe kann man da auch nix scannen...

    Wenn die Verbindung Peer-to-Peer abläuft, dann ist einer von beiden ein Server und öffnet auch einen Port. Auch wenn die Ports natürlich nur temporär offen sind, und möglicherweise auch nur für das jeweilige Gegenüber. Was mir da eher zu denken gibt, sind diese "DERPs". Die haben ggf. permanent Zugriff auf dein Netz, je nachdem, wohin deine Clients ihre Verbindung aufbauen.


    Ich will tailscail hier nicht unnötig runter machen. Es ist unglaublich komfortabel, und ich denke auch, dass die alles dafür tun, dass die Kundendaten sicher sind. Ebenfalls werden die nicht unnötig auf Kundenendgeräte zugreifen oder Daten abfließen lassen. Andernfalls wären die schneller vom Markt verschwunden, als man "Piep" sagen kann.


    Man wird das Produkt sicher nutzen können. Aber wenn es eine harte Securitiy Analyse gibt und Sicherheit ein hohes Ziel ist, dann ist tailscail raus. Da ist eine eigene Lösung ohne Cloud Einbindung garantiert sicherer.

    Ums ganz deutlich zu sagen: Ich halte die Konfiguration an mehreren Stellen für kompletten Unsinn und bin sicher, dass man sie anders eingerichtet auch zum Laufen bekommt, und dann auch so, wie von der DG vorgesehen. Das oben beschriebene ist definitiv nicht deren angedachter Weg.

    Die Kommunikation läuft nicht direkt und nicht über deren Server.

    Das verstehe ich nicht. Wenn sie nicht direkt läuft und nicht über deren Server, woher läuft sie denn dann?


    Ich vermute, die Nutzdaten werden direkt übertragen, aber die Vermittlung läuft sehr wohl über deren Server. Heißt: Die verschlüsselten Nutzdaten laufen direkt, während die sensiblen Infos über offene Ports, IP-Adressen und Zugangsinformationen bei denen bekannt sind. Ich kenne das Produkt nicht, aber so sieht es von außen aus.


    Was die generelle Bedrohungslage angeht: Da dein VPS eine öffentliche IPv4 hat, ist er natürlich deutlich exponierter Im Netz, als dein heimischer Internetanschluss, der lediglich über eine öffentliche IPv6 verfügt. Auf meinem VPS kann ich auf IPv4 ca. 50 - 100x so viele Portscans und PHP Attacken sehen, als auf IPv6. Irgendwo muss der ServerPort für die Verbindung ja offen sein: Entweder auf deinem VPS oder im Heimnetz. Und du musst bedenken: Wenn der Hacker auf dem VPS ist, ist er in deinem Heimnetz, die haben eine uneingeschränkte VPN Verbindung.


    Also wenn größtmögliche Sicherheit das Ziel ist, dann sollte die Umsetzung ohne VPS erfolgen. Allerdings ist die Umsetzung mit einem VPS natürlich deutlich komfortabler, spätestens dann, wenn mehr als ein Netz erreicht werden soll (deshalb mache ich es auch so). Aber man sollte sich der Risiken bewusst sein. Das heißt, dass man vor allem sehr genau weiß, wie man einen VPS von außen zuverlässig verriegelt.