Beiträge von frank_m

    Ich gehe davon aus, dass er es mit den vorhandenen 12V Betreibt und deshalb eh keine Potentialtrennung braucht.

    Das würde gehen? ich hatte es so gelesen, dass der Shelly mindestens 24 V braucht.


    Bei 230V "dürfte" er ja eh nicht dran rummachen, wenn er kein "Gelernter" ist.

    Naja. Ich hab Anfang der 90er eine Telekomausbildung zum Kommunikationselektroniker erfolgreich absolviert. Da war auch so ein VDE 0100 Wisch dabei. Ich sag mal so: Für einen Lichtschalter reicht es noch, auch wenn ich das Thema seit dem nie mehr aktiv verfolgt habe, sondern in ein Informatikstudium abgedriftet bin.

    Hier scheinen sich ja Experten zu tummeln, deshalb stelle ich hier mal meine Frage.

    Meine Rollläden werden momentan gesteuert mit Hilfe von Komponenten der Baureihe 14 von Eltako. Für jeden Rollladen hab ich also einen Doppeltaster im jeweiligen Raum: Einer für rauf, einer für runter. Dazu gibt es einen zentralen Doppeltaster, der alle Rollläden auf bzw. zu fährt.

    Zu jedem Doppeltaster führt vom Schaltschrank ein Telefonkabel. Die Spannung für die Taster beträgt nur 12V.

    Nun würde ich den zentralen Doppeltaster gern "Smart" machen. Für die einzelnen Räume brauche ich das nicht, da bin ich eh, wenn ich dort die Rollläden fahren will. Aber ab und zu kommt der Wunsch auf, alle Rollläden vom Sofa oder aus der Ferne zu bedienen.

    Es gibt meines Erachtens zwei Möglichkeiten: Eltako unterstützt Enocean Funkmodule. Da könnte man wahrscheinlich eine Fernbedienung oder auch ein Modul mit Internetverbindung ins System integrieren. Problem: man müsste dieses Funkmodul anlernen, und dazu fehlt mir die Kenntnis und vermutlich auch die erforderliche Software. Die Installation hat damals ein Elektriker gemacht, ich kenne also die exakte Konfiguration aus Sensor und Aktor und die damit verbundenen RS485 Telegramme nicht.

    Aber ich könnte ja auch den zentralen Doppeltaster "Smart" machen. Ich bräuchte vermutlich einen potentialfreien Doppelaktor, um die 12V zu schalten, für Standard Unterputz Dosen mit Energieversorgung (Batterie oder direkt daneben ist ein Lichtschalter, 230V wären also ggf. da). Ich vermute, die Leistung des Eltako Netzteils reicht nicht, um dort irgendwelche Funkkomponenten raus zu speisen.

    Der Doppelaktor müsste sich als "Taster" konfigurieren lassen, also eine automatisierte "Zu"-"Auf" Folge mit maximal 1 Sekunde Aktivzeit würde ich mal sagen. Wenn die vorhandenen Taster sich noch anschließen lassen, wäre das nett, ist aber kein Muss.

    Frage: Gibt es sowas? Vielleicht von Homematic? Ich bin aber in Bezug auf die Technologie noch offen. Mein Büro hab ich mal spaßeshalber mit Tradfri Komponenten ausgerüstet, aber das ist kein Muss (es schadet aber auch nicht, wenn es sich da einbinden lässt, Zigbee wäre ok).

    Hat jemand einen Vorschlag?

    Denkfehler! dann hat der Admin nicht verstanden ein ordentliches Sicherheitskonzept durchzusetzen. ohne einem ordentlichen Sicherheitskonzept nützt Dir eine ordentliche Firewall auch nichts - um in deinem Jargon zu bleiben und was auch immer Du als ordentliche Firewall verstehst;

    Du spielst auf einen Proxy an? Kann man machen. Und der geht auch mit IPv6, und schon wieder viel einfacher und besser, als mit IPv4.

    jetzt musst nur noch erklären wieso etwas das man als Hochsicherheit betrachtet vom Internet aus erreichbar sein soll?

    genau das soll es ja eben nicht sein, dass unbefugten ein Zugriff auf eine (Überwachungs-)Kamera ermöglicht wird;

    Wer redet von unbefugt oder Hochsicherheit? Es ging in deiner Aussage um dyndns und um den Zugriff von außen. Darauf zielt das Beispiel ab. Und das geht eben mit IPv6 schon wieder einfacher und komfortabler, als bei IPv4, auch bei dynamischen Prefixes, vor allem, wenn viele gleichartige Geräte benutzt werden sollen. Unbefugt ist der Zugriff deshalb ja noch lange nicht. Und es sind ja auch nicht nur Banken im Internet unterwegs.

    Fehler im Standard; das wurde sehr bald besiegelt dass dem so ist mit einem /64; (Stichwort EUI-64)

    Ja, genau. Wie gesagt, das stört mich ein wenig. Ich könnte mir einige Anwendungsfälle für ein /80 Prefix vorstellen, wenn es z.B. sowas wie EUI-48 gäbe (Ooops - gibts ja =O). Würde die Flexibilität für kleine Netze halt noch mal vergrößern, wenn man wirklich mal nur ein /64 zur Verfügung hat. Naja, geht auch so.

    die Geschichte mit den Link-Localen IPv6 Adressen fe80::/10 suggeriert einem aber was anderes ...

    Wie kommt man denn von "link-local" auf Layer 1??? 8| Praktisch jedes Netz hat doch schon mindestens zwei Physical Layer (Ethernet und WLAN), und es ist trotzdem eine Broadcast Domain.

    jedes Unternehmen, welches bei IPv4 hinter einem NAT alle Mglkt.en aus RFC1918 ausgeschöpft hat, würd ich mal sagen ...

    Braucht vor allem erst mal IPv6, würde ich sagen 8o8o8o

    (Und wäre dann mit einem /64, aufgeteilt in viele /80 mit EUI-48, eigentlich mehr aus ausreichend bedient. :saint:)

    genau das ist aber das Problem; das physikalische Netzwerk ist aber das selbe und die Anforderungen auch;

    Mit dem physikalischen Netz hat IPv6 nichts zu tun. Die Anforderungen lassen sich meistens mit beiden Technologien erfüllen, bis auf wenige, die mit IPv4 einfach nicht gehen.

    und NAT ist kein Klimmzug, sondern hat seinen Snn;

    NAT ist einer der schlimmsten Klimmzüge, die es je gab, und der vermeintliche Sicherheitsgewinn ist nur ein (fahrlässiges) Argument, nicht eine ordentliche Firewall konfigurieren zu müssen.

    und ehrlich würdest Du ein Unternehmen, z.B. eine Bank so konfigurieren,

    dass jeder Client direkt vom Internet aus erreichbar ist?

    Er muss ja nicht erreichbar sein, aber er kann. Ob und wie er es ist, hängt von der Firewall ab, und kann erheblich flexibler und präziser konfiguriert werden. Oder eben einfach so wie bei IPv4.

    Und wenn die 65.000 Ports auf der öffentlichen NAT IP langsam knapp werden, dann ist jeder Admin froh über die Endgeräte, die in den Antworten direkt adressierbar sind.

    nein nicht jedes Ding macht sein eigenes DDNS des muss zentral z.B. vom Router aus gesteuert werden

    und genau da scheitert es ...

    dynv6 und ab dafür. Wo ist das Problem? Ein Prefix-Update durch den Router, und alle Geräte fliegen. Wer schon mal 25 Portweiterleitungen einrichten musste, um Kameras von außen erreichbar zu machen, und dabei für jede Kamera einzeln erst mal passende Ports identifizieren musste, die in der Client Firewall auch zulässig sind, wird es lieben.

    IPv6 ist aus Sicht heute - dem fast zu Ende gehenden Jahr 2021 - immer noch unvollständig;

    Das einzige, was ich bislang vermisse, ist eine flexible Prefix Länge bei SLAAC.

    od. will mir jetzt jemand erklären, IPv6 hat sich sogar um den Layer 1 Gedanken gemacht;

    das wäre der Oberquark;

    Nein, natürlich nicht, da hat IPv6 auch gar nichts verloren. IP ist Schicht 3, nichts anderes, und kann auf nahezu beliebige Physical Layer und MAC Konstrukte aufsetzen. Ethernet in allen Derivaten, WLAN, Bluetooth, ZigBee, ... alles möglich.

    alleine das mit den Prefixen gefriert mir den Grinser ein;

    wie käme man auf die Idee z.B. ein /60 zu vergeben?

    würdest gleich in Richtung /48 gehen dann kannst gleich IPv8 designen,

    Das längste sinnvolle Prefix ist momentan natürlich /64, wegen SLAAC. Aber bei kürzeren Prefixes bist du recht flexibel. Aber mal ehrlich: Wer außer Infrastrukturbetreibern braucht mehr als /48? Die kannst du an einer Hand abzählen.

    Da bin ich anderer Meinung.

    Die Herangehensweise ist natürlich völlig anders, als bei IPv4. Und durch die Ignoranz IPv6 gegenüber hat man sich so an die (hässlichen) Klimmzüge gewöhnt, die man für IPv4 eingeführt hat (NAT), dass man ihr Fehlen nun IPv6 anlastet und den Luxus, den IPv6 bietet, nicht mehr zu schätzen weiß.

    IPv6 ist anders, aber keinesfalls mehr Aufwand, als IPv4. Im Gegenteil, einmal eingerichtet lassen sich die meisten Dinge mit erheblich weniger Aufwand realisieren, als bei IPv4. Was es schwierig macht, ist die fehlende Unterstützung oder mangelhafte Umsetzung vor allem in vielen SoHo Produkten. Das ist dann gefühlte Mehrbelastung, das kann man aber kaum dem Standard anlasten. Ich möchte IPv6 nicht mehr missen.

    Kann ich ebenfalls nicht bestätigen. Ich hab Verbindungen von außen per Wireguard angebunden, davon benutzt eine Verbindung ausschließlich IPv6 und eine andere ausschließlich IPv4. Gäbe es auf einer der beiden Verbindungen ein Problem, würde ich es relativ schnell bemerken.

    Seit der Behebung der letzten Störung mit dem stark schwankenden Ping (https://forum.netcup.de/netcup-intern/…eme/#post169811) sind bei mir auch die kleineren Schwankungen zu den Abendstunden (18 - 22 Uhr) weg (die sah man sonst fast täglich). Die Verbindung ist sehr stabil und gleichmäßig seit dem.

    Port 80 ist schon in Benutzung auf deinem Host System. Gib mal als root "netstat -tulpen" ein, dann kannst sehen, welcher Prozess dafür verantworlich ist. Anschließend musst du dann entscheiden: Was ist wichtiger? Prinzipiell kann man Dienste ja auch auf anderen Ports als 80 laufen lassen. Vielleicht bietet sich 443 als verschlüsselte Alternative an.

    Theoretisch vielleicht. Praktisch aufgrund administrativer Hürden vermutlich unmöglich oder nur mit hohem Aufwand realisierbar. Die IP-Adressen, auch für IPv6, mit den jeweiligen Gateways und so werden ja nicht zufällig verteilt. Nicht umsonst kannst du eine IP von einem VPS oder RS nicht zu einem anderen mitnehmen.

    Die Trennung wäre einfach: Du bist gelistet, dann kommst Du in den anderen AS. ;)

    Genau das geht technisch ja nicht. In den Listen werden ja nicht einzelne IPs, sondern immer alle IP-Bereiche eines AS gelistet. Wenn also nur eine IP spammt, müsstest du das ganze Subnetz zum "bösen" AS verschieben. Innerhalb von Tagen wären alle IP-Bereiche wieder im "bösen" AS und damit die gleiche Situation wie jetzt.

    Das Problem sehe ich vor allem darin, wenn ich mal den Provider wechseln sollte.

    Na ja,

    - wie oft kommt das vor?

    - Warum betreibt man überhaupt den Server am heimischen DSL Anschluss und nicht im Rechenzentrum?

    Man stelle sich das mal vor... alle DNS Einträge ändern, rDNS Einträge ändern, ggf. statisch konfigurierte IPs in gewissen Use Cases ändern, Firewall komplett überarbeiten und und und...

    Wenn tatsächlich so viele Abhängigkeiten an den IPs dran sind, dann sollte man über ein eigenes PI Netz nachdenken.

    Die komplette IP Vergabe kann automatisch ablaufen. Aber für die Firewall muss sich wieder jeder Router Hersteller was eigenes ausdenken. Absurd.

    Es gibt halt unterschiedliche Implementierungen von Firewalls. Da ist es schwer bis unmöglich, etwas zu standardisieren. Letztlich ist es doch auch hier nur eine Frage, wer sich die Mühe macht, und mal was dafür aufsetzt. Wenn es dann einmal was gibt für iptables, nftables, ufw oder was auch immer, dann können wieder alle davon profitieren. Die grundsätzlich erforderlichen Mechanismen bringen ja alle mit.

    Das ist bei er Umsetzung der Adressierung ja auch nicht anders, nur dass dort eben viele auf die bereits vorhandenen Implementierungen setzen und deshalb der individuelle Implementierungsaufwand sinkt.

    Der Grund ist, dass IPv6 niemals dafür vorgesehen war, die Cashcow von dynamisch wechselnden Prefixen + Business-Tarif Aufpreis wenn du static willst weiter zu melken.

    Ich glaube kaum dass damals bei der Standardisierung bereits diese spezifischen kommerziellen Modelle der ISPs eine Rolle gespielt haben. Zumal die Standardisierung eher von Unternehmen wie HP, Alcatel und Cisco vorangetrieben wurde, weniger von Telekom, Verizon oder AT&T.

    Ich verstehe halt nicht wie ich damit Firewall Regeln für einen einzelnen Client machen soll, ohne den in ein separates VLAN zu stecken

    Ist die OpenSense Firewall nicht letztlich iptables basiert? Dann verstehe ich nicht, warum dafür ein VLAN nötig sein sollte.

    Es ist doch so, dass man ein Prefix vom Provider bekommt und das Gerät hat eine statische Host-ID. Aus Prefix und Host-ID ergibt sich die Zieladresse, die auch Bestandteil der Firewall Regel sein muss. Beispiel:

    Code
    ip6tables -A FORWARD -i eth0 -p tcp -d <prefix1>::1 --dport 8080 -j ACCEPT

    Jetzt bekommt man ein neues Prefix vom Internetprovider, folglich bekommt das Gerät eine neue IP: <prefix2>::1. Vermutlich werden sich durch das neue Prefix diverse Firewallregeln ändern. Da bei iptables die Reihenfolge der Regeln ja wichtig ist, würde ich jetzt erwarten, dass der Router einmal den kompletten Regelsatz löscht und alle Regeln neu anlegt und dabei das neue Prefix beachtet. Wenn der Router das nicht selber kann, kann man sich auch auf Basis eines Scriptes selber was bauen.

    wenn man einen dynamisch wechselnden Prefix hat, ist dies natürlich ein Problem. Dann muss doch wieder prefix translation ran, sprich du kannst intern die ULA (Unique Local Adressen) vergeben, und nach außen hin auf den dynamischen Prefix mappen (sofern opnsense das schon kann, pfsense kann es noch nicht).

    Warum ULA? Gibt es eine Einschränkung bei OpenSense, dass es nicht mit dynamischen Prefixes zurecht kommt? Die Firewall muss bei einem neuen Prefix ggf. umkonfiguriert werden, aber das sollte man automatisieren können (das kann ja heute schon jede Fritzbox). Für die Benutzung von ULAs sehe ich da im Moment keinen Grund.

    Da Netcup aber wie ich in diesem Thread schonmal breit erörtert habe, seine Hausaufgaben bzgl. IPv6 nicht richtig gemacht hat

    Wie beschrieben kann man darüber sehr geteilter Meinung sein. Wenn man die Definition der RFCs in Bezug auf "Site" und "Host" akribisch auslegt, dann macht Netcup exakt das, was in den Standards empfohlen wird. Auch wenn ich zugebe, dass zusätzliche /64 Netze auf einem VPS oder RS zuweilen hilfreich wären, aber auch dann hat man kostenlose Möglichkeiten, wie ich im verlinkten Thread ja auch ausgeführt habe.

    philmor: Bei dir gibt es ja kein Problem, der letzte Hop ist ja in Ordnung. In einem Traceroute liegt nur dann ein Problem vor, wenn ab einem spezifischen Hop alle Folgehops auch eine erhöhte Latenz aufzeigen.

    Wenn einfach nur ein Hop zwischendurch eine erhöhte Latenz aufweist, dann heißt das einfach nur, dass dieser Hop ICMP Nachrichten mit geringer Priorität erzeugt.

    How to read a traceroute