Beiträge von psychofaktory

Zitat von DeBaschdi

Was ist da recht / Unrecht ?

Das gibt eigentlich immer die jeweilige Rechtssprechung des Landes vor in dem man eben ansässig ist.

In China können grundsätzlich ja ganz andere Dinge illegal sein als in Deutschland.
Ob Dinge rein durch demokratische Politik, Diktatur, oder durch feinste Lobbyarbeit für illegal erklärt werden spielt dabei keinerlei Rolle.

Und dann gibt es da eben noch diese Grauzonen...
Wenn etwas nicht ganz klar oder eindeutig gesetzlich geregelt ist, es aber zumindest moralisch oder aus Sicht einzelner Interessengruppen (wie z.B. die Content-Rechte-Inhaber) laut AGB unzulässig ist, aber unklar ist ob die entsprechenden Passagen der AGB hier überhaupt rechtlich bindend sind.

Die Grenze lässt sich leider oftmals nicht eindeutig ziehen.
Wenn eine Technik (wie z.B. VPN) genutzt wird um generell kostenpflichtige Dienste - wie auch immer - kostenfrei zu erhalten, dann kann man denke ich schon von einer illegalen Handlung sprechen.
Wenn es darum geht Dienste die in Deutschland durch die Rechteinhaber kostenpflichtig angeboten werden und im ausland (aus welchen Gründen auch immer) gratis angeboten werden, dann scheint das derzeit noch eine dieser Grauzonen zu sein.

Edit:
Wenn Kodi.tv sich (sicherheitshalber) von Grauzonen distanziert, bzw. das Thema VPN grundsätzlich verachtet um nicht in Verbindung mit Themen wie Urheberrechtsverletzungen etc. gebracht zu werden (die ja oft mit VPN in Verbindung gebracht werden), dann ist das nachvollziehbar.

Zitat von johnny depp

gibt es schon eine repo zip für Nexus?

Ich würde sagen das Kodinerds-Repo ist bereits Nexus-Kompatibel, allerdings ist das Add-On-Angebot noch etwas dünn:
https://repo.kodinerds.net/index.php?acti…&version=nexus/

Hallo,

Wenn an der Netzwerkinfrastruktur Anpassungen durchgeführt werden, oder man neue Dienste in Betrieb nimmt, ist es immer sinnvoll zu überprüfen ob auch alles richtig konfiguriert wurde.
Gerade dann, wenn es um den Zugriff aufs Internet, oder die Bereitstellung im Internet geht.
Dazu haben sich Online-Testtools bewährt.

Ich möchte hier eine Sammlung an Test-Tools vorstellen, die ich hier sehr hier hilfreich fand.

SSL-Zertifikate überprüfen:
https://www.ssllabs.com/ssltest/
https://tls.imirhil.fr/
https://www.immuniweb.com/ssl/

E-Mail-Sicherheit testen:
https://mecsa.jrc.ec.europa.eu/de/

Webseite-Sicherheit testen:
https://observatory.mozilla.org/

Datenschutzmaßnahmen einer Webseite testen:
https://webbkoll.dataskydd.net/de/

Bewertung der eigenen Internetverbindung (Bufferbloat, Speed, etc.)
https://speed.cloudflare.com/

Bufferbloat testen:
https://www.ssllabs.com/ssltest/
https://www.waveform.com/tools/bufferbloat

IPv6:
https://www.ipaddressguide.com/ping6
https://ipv6-test.com/
https://test-ipv6.com/index.html.de_DE
https://ready.chair6.net/

DNS:
https://www.dnsleaktest.com/
https://dnschecker.org/domain-health-checker.php

DNSSEC:
https://www.rootcanary.org/test.html
https://dnssec-debugger.verisignlabs.com/

DNS-Zone und DNSSEC prüfen:
https://dnsviz.net/
https://zonemaster.iis.se/en/

Adblocker testen:
https://d3ward.github.io/toolz/adblock.html

Tracking im Browser:
https://coveryourtracks.eff.org/

Microsoft-Dienste prüfen:
https://testconnectivity.microsoft.com/tests/o365

Website-Performance prüfen (hier kann man auch HTTP/2 und Brotli testen, sowie den HTTP-Header checken):
https://tools.keycdn.com/http2-test

Nextcloud Security Scan:
https://scan.nextcloud.com/

DANE prüfen:
https://www.huque.com/bin/danecheck

Stun- und Turn-Server testen:
https://webrtc.github.io/samples/src/co…on/trickle-ice/

Universelle Tests die mehrere Bereiche abdecken:
https://www.hardenize.com/
https://internet.nl/
https://check-your-website.server-daten.de/

Headers einer Webseite überprüfen:
https://securityheaders.com/

OpenPGPKey-DNS-Eintrag prüfen:
https://openpgpkey.info/

Prüfen ob eine Webseite umgeleitet wird:
https://redirectdetective.com/

Testen welche ausgehenden TCP-Ports erlaubt sind:
http://portquiz.net/

Toolsammlung zur Überprüfung von E-Mail-Servern:
https://mxtoolbox.com/

Webseiten überprüfen ob sie nur für mich offline sind:
downforeveryoneorjustme.com/

Minecraft-Server prüfen:
https://mcsrvstat.us/

Matrix-Server überprüfen:
https://federationtester.matrix.org

Checken ob der Mailserver auf einer Blacklist steht:
https://www.dnsbl.info/

Überprüfen ob am Internetanschluss in verschiedenen Konstellationen Paketverluste auftreten:

Packet Loss Test – Testen Sie Ihre Verbindungsqualität

Damit verbunden gibt es noch praktische Helferlein:

Die passenden Cipher Suites kann man sich hier aussuchen:
https://ciphersuite.info/cs/?tls=tls12&…singlepage=true

ein BB Code Editor:
https://www.systutorials.com/tools/bbeditor/

TLSA-DNS-Einträge generieren lassen:
https://www.systutorials.com/tools/bbeditor/

die IP des eigenen Mailservers für den Verand an Microsoft-Adressen freischalten lassen:
http://go.microsoft.com/fwlink/?LinkID=614866

Ich würde mich über Ergänzungen dazu freuen.

Bitte, kein Problem

Was ich zum Mail-Server noch anmerken wollte:
Es kann Sinn machen den nicht am eigenen Anschluss zu betreiben, sondern dafür einen VPS zu mieten.
Einfach wegen der Ausfallsicherheit und Erreichbarkeit deines Mail-Systems.
Zudem: eine feste öffentliche IP ist bei einem Mail-Server praktisch pflicht und auch ein Reverse-DNS-Eintrag ratsam.

Zitat von raabenaas

Dazu nur ein gedanke der mich schon seit ner Weile interessiert und neugierig macht den eigenen kleinen email Server
aufziehen.

Dazu kann ich nur zu Mail-in-a-Box bzw. dessen Fork raten!
Easy einzurichten, unterstützt alles was man so braucht und ist hinsichtlich der verwendeten Standards usw absolut up-to-date.

Ich erreiche damit beim MECSA-Test die maximal mögliche Wertung:
https://mecsa.jrc.ec.europa.eu/

Kann übrigens auch nur empfehlen den MECSA-Test mal auf das eigene E-Mail-Postfach anzusetzen um zu sehen wo man da so steht und was hier potentielle Nachteile sein können.
E-Mail-Spoofing z.B. wird damit komplett eliminiert, und man selbst landet praktisch nie mehr bei anderen im Spam-Ordner da man als absolut vertrauenswürdiger Absender gilt.

Puh, da bin ich leider raus.

@DeBaschdi

Tricky..
Aber ich würde das auch hier wieder eher von infrastruktureller Seite aus aufziehen als von den Clients aus.

Woher bekommen denn die Clients die IPv6-Adresse?
Ich schätze mal der Router weißt die Adresse zu.
Unter OPNsense würde ich das wohl so lösen, dass an der Schnittstelle an der die betreffenden Clients hängen IPv6 über ein Skript erst aktiviert wird wenn der Tunnel gestartet ist.
Ist jetzt zwar nur Theorie, aber ich denke das sollte so funktionieren.
Eine elegantere Lösung fällt mir zumindest jetzt auf die Schnelle nicht ein.

Zitat von DaVu

Für mich war aber an dieser Stelle viel wichtiger, dass ich ein Gerät habe, welches meine VPN Verbindung entgegen nimmt und ich von dort aus alle Geräte in meinem Netzwerk ansprechen kann.

Dann brauchst du an sich ja nichts anderes wie einen VPN-Server. Entweder direkt auf dem USG (ich kenn den Funktionsumfang des Gerätes hier leider nicht), oder auf einem anderen Gerät im Netzwerk für das du eingehende Anfragen an den VPN-Server dann in der USG freigibst.
Ich habe den VPN-Server direkt auf der OPNsense aktiv, was es mir deutlich leichter macht die Zugriffe über VPN ins Netzwerk oder auch in meine verschiedenen Subnetze granular zu reglementieren.

Zitat von DaVu

Ich habe einen 56er Präfix bei mir einetragen. Nur sagtest du ja, dass ich mehr ale eine öffentliche IPv6 am Interface angezeigt bekommen soll. Und das ist nicht der Fall.

Du hast also eien 56er Präfix von deinem Provider? Ich hatte Dich jetzt so verstanden, dass du vom Provider nur eine einzige Adresse erhalten hast.

Mit einem 56er-Präfix stehen dir eigentlich alle Möglichkeiten offen. Dein Router nimmt den vom Provider entgegen und kann die Adressen aus dessen Bereich nach deinen Vorgaben an die Clients delegieren.
Wenn du am Client nur eine öffentliche IPv6 angezeigt bekommst, würde ich darauf tippen, dass dein Router die Adressen mittels SLAAC zuweist und am Client die PrivacyExtensions nicht aktiv sind.
Wenn du die PrivacyExtensions aktivierst und z.B. noch DHCPv6 am Router, hättest du schon 3 öffentliche IPv6-Adressen am Client.

Zitat von DaVu

Es gibt also kein NAT.

Zumindest ist das standardmäßig nicht vorgesehen. wie @te36 ja auch schon geschrieben hatte kann man das dennoch abbilden wenn man denn möchte.

Zitat von DaVu

Somit muss ich meine Geräte selbst schützen und kann das keinem zentralem Gerät überlassen.

Die Firewall spielt bei IPv6 eine deutlich gewichtigere Rolle als noch bei IPv4. Ich denke das kann man definitiv so sagen.
Die Netzwerksicherheit würde ich aber nicht von Client-Seite aus aufziehen, sondern sehe hier eher den Router mit seiner integrierten Firewall als zentrales Gerät.

Ich kenne jetzt die USG nicht im Detail, aber bei einer OPNsense z.B. ist per default erst einmal alles dicht und man kann absolut Zugriffe vollkommen granular über Regeln festlegen.
Auch die interne Adresszuweisung. Hatte jetzt tatsächlich noch keinen Fall den ich damit nicht umsetzen konnte.

Zitat von DaVu

Es sei denn, ich setze einen intenen VPN Server auf.

Wenn ich deinen Gedankengang jetzt richtig verstehe würde ein interner VPN dir bzgl. dem Mehr an Sicherheit durch NAT intern nur dann etwas bringen, wenn die internen Clients ihren ausgehenden Traffic über den VPN tunneln und damit quasi ein NAT erzwungen wird.
Das wäre aber einfacher über entsprechende Einstellungen am Router zu bewerkstelligen.

Zitat von DaVu

In dem Fall tatsächlich nur eine öffentlcihe.

Das ist natürlich sehr ärgerlich!
Es wäre gerade im Hinblick auf die schier unendliche Anzahl an verfügbaren Adressen wirklich wünschenswert, wenn alle Provider ihren Kunden sowohl eine WAN-IPv6-Adresse, als auch einen IPv6-Präfix zuweisen würden. Wahlweise statisch oder dynamisch. Das würde so vieles einfacher machen.
Ich meine mich daran zu erinnern, irgendwo auch gelesen zu haben, dass das eigentlich seitens der IANA so in den 1995 erlassenen Richtlinien so vorgegeben wurde.

Zitat von DaVu

Wie immer...an einem Tisch mit nem Bier wäre vieles einfacher

Da stimme ich dir voll und ganz gut
Aber wir kommen schon klar hier

Zitat von DaVu

Da scheint, dass jede IPv6 IP, die ich intern im Netzwerk habe auch die ist, die als WAN IP für das jeweilige Gerät gilt. Da scheint bei IPv6 anders zu sein oder mir fehlt ein grundlegendes Verständnis von IPv6

Nein, nicht ganz.
Du musst dich da etwas von der "klassischen" Denkweise der IPv4-Adresszuordnung verabschieden.

Bei IPv6 gibt es im Gegensatz zu IPv4 einen erheblich größeren Bereich verfügbarer Adressen. Folglich kann man damit auch deutlich großzügiger sein, und ist nicht auf Hilfsmittel wie NAT und PAT angewiesen.
Wenn du IPv6 im LAN aktiv hast, wirst du feststellen, dass du an deinem Client höchstwahrscheinlich mehrere IPv6-Adressen aktiv hast. Sicherlich eine Link-Local die mit fe80:.. anfängt, sowie 2 oder mehr aus dem öffentlichen Adressbereich.
Das hängt u.A. mit dem "Privacy Extensions" zusammen.
Vom Provider bekommst du dann auch nicht nur eine WAN-IP zugewiesen, sondern einen ganzen Präfix aus dem weitere IPs generiert werden können, oder sogar ganze Subnetze.
Hier ist z.B. ein Einstieg mit dem man sich ein bisschen einlesen kann:
https://www.elektronik-kompendium.de/sites/net/0812201.htm

Zitat von DaVu

Warum? Warum wird bei IPv6 nicht mehr geNATet? Kannst du mir das erklären? Ich weiß es einfach nicht.

Weil es genug Adressen gibt und NAT damit einfach nicht mehr nötig ist.

Zitat von DaVu

Wollen wir an dieser Stelle man ganz klar von einem VPN und von Portweiterleitung differenzieren? Ein VPN ist keine Portweiterleitung. Ein VPN ist ein "virtuelle Verbindung zu einem privaten Netwerk". Das hat erstmal nichts mit einer Portweiterleitung zu tun. Bei einer Portweiterleitung öffne ich an meinem Router Anfragen an Port 30022 und leite diese nach innen in mein Netzwerk an ein bestimmtes Gerät an den Port 22 weiter um dann SSH machen zu können.

Bei einem VPN verbinde ich mich zwar auch gegen einen Port (443 z. B.). Dort findet dann aber eine Authentifizierung statt und kann ich danach, weil ich eine IP aus einem anderem Netzwerk bekommen habe (nämlich eine aus dem Netzwerk gegen das ich mich verbinde) JEDES Gerät unabhängig vom Port ansprechen.

Der Unterschied ist mir bewusst.
Dein Beispiel eines VPN-Zugangs in ein Netz ohne Portweiterleitung funktioniert nur, wenn der VPN-Server auf dem Router läuft.
Der VPN-Server kann aber durchaus auch auf einem anderen Client im Netzwerk laufen.
In meinem Beispiel hatte ich das so vorausgesetzt, um die Unterschiede zwischen IPv4 und IPv6 besser hervorheben zu können.

Zitat von DaVu

Wäre das jetzt nur eine Portweiterleitung, dann könnte ich mich nur gegen ein Gerät verbinden. Nämllich gegen das, gegen das weiter geleitet werden würde.

Nein, das ist nicht richtig
Auch mit einer Portweiterleitung zu einem VPN-Server kann ich Zugriff auf das komplette Subnetz erhalten. Das ist dann Einstellungssache des VPN-Servers.
Wir hatten hier im Forum z.B. schon mehrfach das Szenario diskutiert: Fritzbox-integrierter VPN vs. Portweiterleitung auf VPN-Server auf QNAP oder Synology. Aus Performancegründen kann hier die Portweiterleitung auf die NAS sinnvoll sein. Aber in beiden Fällen wäre ein Zugriff auf das gesamte Subnetz möglich.

Zitat von mireki1975

aber wireguard sollte dies doch lösen, oder?

Wireguard ist jetzt erstmal nur ein VPN-Dienst.
Mit dem funktioniert die VPN-Verbindung von extern ins Netzwerk sowohl unter IPv4 als auch IPv6. Sogar beides gleichzeitig.

Das geht aber auch mit anderen VPN-Diensten.

Zitat von DaVu

Die IPv4, die dort gelistet wird, ist die vom CGN meines Providers, die IPv6 ist haargenau die von meinem Laptop.

Das ist richtig und soll auch ganz genau so sein.
Entscheidend ist nicht ob die IPv4-Adresse von deinem WAN-Anschluss oder die IPv6-Adresse von deinem Client angezeigt war, sondern die Tatsache, dass die Webseite die Adresse nur anzeigen kann, weil du zuerst eine Anfrage an die Seite gerichtet hast und die Seite nur darauf geantwortet hat.

Zitat von DaVu

Daher auch meine Vermutung, dass bei IPv6 kein NAT mehr statt findet, so wie es bei IPv4 der Fall ist.

So wie du vermutest soll es auch hier sein.

Zitat von DaVu

Eine Verbindung gegen eine Stelle, wo ich mich dann in meinem LAN befinde und dort das gleiche machen kann, als wäre ich zu Hause (wie bei einem herkömmlichen VPN).

Das funktioniert ja bei IPv4 ebenso wie bei IPv6.
Bei IPv4 sagst du über eine Portforwarding-Regel, dass alle Anfragen von extern an die WAN-IP die an einen bestimmten Port gerichtet sind intern an deinen VPN-Server weitergeleitet werden sollen.
Bei IPv6 sagst du über eine Firewall-Regel, dass alle Anfragen an die WAN-Schnittstelle die an einen bestimmten Port gerichtet sind intern an die IPv6-Adresse deines VPN-Server durchgelassen werden.

Ist eigentlich sogar viel einfacher.

Zitat von DaVu

Freigaben zu jedem meiner einzelnen Rechner.

Die bekämst du nur, wenn du das explizit so im Regelwerk angeben würdest.
Dazu müsstest aber schon ziemlich viel falsch konfigurieren

Zitat von DaVu

Ich finde es ja schon merkwürdig, dass bei IPv6 wohl offensichtlich kein NATing mehr stattfindet. Zumindest sehe ich, wenn IPv6 aktviert ist, die IPv6 meines Laptops auf "whatismyip". Das finde ich schon gruselig, wenn ich dann dafür sorgen muss, dass mein Laptop entsprechend geschützt ist.

Mit wäre es viel lieber, wenn es geNATet wäre und ich meinen Router sehen würde. Dann würde sich mir ein VPN über IPv6 auch eher erklären

Praktisch jeder handelsübliche Router für den Heimbereich nutzt SPI.
Das heißt ohne eine explizit gesetzte Firewall-Regel, die Datenverkehr vom WAN ins LAN erlauben würde, kommt erstmal garnichts von außen nach innen.
Lediglich dann, wenn von innen aus einen Anfrage gesetzt wird (der Aufruf von "whatsmyip" von deinem Client aus ist so eine Anfrage), werden die zugehörigen Antworten auf diese Anfragen von der Firewall durchgelassen.
Das ist aber nicht nur bei IPv6 so, sonder war auch schon immer mit IPv4 so.

Ob nun die Webseite deinen Router oder die (durch die Privacy-Extensions nur) temporäre IPv6-Adresse deines Clients sieht macht dabei sicherheitstechnisch eigentlich keinen Unterschied.

Zitat von AcidRain

Gibt es denn Anbieter / Möglichkeiten, damit man subdomains auf Ports weiterleiten kann?Also… grübel… Beispiel:
emby.meinedomain.de soll auf meineIPv6-Adresse-Port:8096 oder so verweisen…

Versteht man einigermaßen was ich meine?
sonst hab ich wieder das Thema, dass ich mir zigtausend Ports merken muss

Was du suchst ist ein Reverse-Proxy

Zitat von kingbuzzzo

Klar geht das alles, muss aber auch alles konfiguriert werden etc., also braucht es jemanden der Ahnung davon hat.

Da gebe ich dir recht. Allerdings trifft das wohl auf alle möglichen Lösungsansätze zu. Bei einer Aufgabenstellung wie dieser ist nun mal naturgemäß ein etwas komplexerer Weg sowie etwas Know-How erforderlich.
Die DHCP Server Port-Based Address Allocation ist sicher auch eine elegante Lösung. Setzt aber auch entsprechende Hardware sowie die Kenntnis davon diese zu bedienen voraus.

Vorteil bei der OPNsense-Variante wäre halt dass es ohne zusätzliche Hardware oder Lizenzkosten auskäme, und gleichzeitig die Anforderung wer in welchem Umfang Zugriff aufs Internet hat und wer nicht mit abdecken würde.
Aber gibt natürlich auch andere Wege das umzusetzen. Bzw. falls kein Know-How vorhanden ist oder keine Bereitschaft oder Zeit sich das anzueignen lässt sich das Prinzip sicher auch mit anderen Firewall-Lösungen umsetzen.

Zitat von kingbuzzzo

Das Problem mit den VLANs ist aber, dass du dann auch routen musst und je nach dem was auf den Geräten läuft, kann das problematisch werden (Broadcast, Multicast, mDNS, etc.).

Das lässt sich bei Bedarf mit OPNsense ebenfalls regeln.
Entweder durch entsprechende Firewall-Regeln, Port-Forwarding, oder Plugins wie dem mDNS-Repeater oder ubpbroadcastrelay.

Zitat von AcidRain

ein günstiger tp Link switch (Managed, glaube sg1016de) von nem Kollegen

Mit dem sollte das Vorhaben so wie beschrieben funktionieren. Außer VLAN-Fähigkeit (802.1q) werden da keine besonderen Funktionen benötigt.

Zitat von AcidRain

Das was du als Steuerungs-PC bezeichnest, wäre dann der Prüf-PC?

Ja genau den meinte ich.

Zitat von AcidRain

Könnte man die Firewall dann auch z.B. in einer VM auf dem Prüf-PC laufen lassen?

Ja, das geht auch. Hab OPNsense selbst in einer VM laufen hier.

Musst nur gut aufpassen dass die Netzwerkkarten dann den richtigen Schnittstellen zugewiesen sind.

Zitat von AcidRain

Und der DHCP Server, bzw. die (sind ja mehrere, wenn ich es richtig verstanden habe), würden dann auch auf dem Prüf-PC (oder ein oder mehrere extra Geräte) laufen?

Die DHCP-Server sind einfach ein Dienst der auf der OPNsense läuft und die du für jedes Subnetz/VLAN einzeln konfigurieren kannst.

in der Praxis hättest du dann z.B. die Subnetze 172.16.101.1/30 bis 172.16.110.1/30 für die zu flashenden Geräte.
Die xxx.xxx.xxx.1 ist jeweils das Gateway und zugleich die Schnittstellenadresse auf der OPNsense. Der DHCP-Server im jeweiligen Subnetz vergibt jeweils die xxx.xxx.xxx.2

Am Switch ist dann Port 1 VLAN101 zugewiesen und das angeschlossene Gerät erhält immer die 172.16.101.2. Bei Port 2 im VLAN102 immer die 172.16.102.2. usw.
Am letzten Port hängt der Prüf-PC in seinem eigenen VLAN.

Das sollte sich lösen lassen mit einer Firewall (z.B. OPNsense) und einem VLAN-fähigen Switch.

Man erstellt 11 Subnetze mit jeweils unterschiedlichem Subnetzbereich in jeweils einem eigenen VLAN.
10 Subnetze haben einen eigenen DHCP-Server mit extrem niedriger Lease-Time und nur einer einzigen Adresse im Adressraum.
Für diese 10 Subnetze werden dann entsprechende Firewall-Regeln angelegt die einen Internetzugriff ermöglichen.
Das 11. Subnetz ist das Steuerungs-Netz. In dem sitzt der Steuerungs-PC.
Über entsprechende Routing-Regeln hat der PC Zugriff auf jedes VLAN und dort jeweils auf die eine IP die der DHCP-Server den zu flashenden Geräten vergibt.

Auf deiner Grafik würde die Firewall dann zwischen LTE-Router und Switch hängen.

IPv4 und IPv6 auch in lokalen Netzen gleichzeitig aktiv zu haben macht schon Sinn.
Ist oftmals ja auch per default so.
Z.B. in der häufigen Kombination Telekom VDSL-Anschluss und Fritzbox.
Bei den ganzen Anleitungen die man so zu PiHole und dergleichen findet, wird oftmals nur IPv4 behandelt.

Wenn also z.B. Werbung auf einem Smart-TV blockiert werden soll, und dieser sowohl über IPv4 als auch IPv6 Internetzugriff hat, und dann mit einem PiHole alle IPv4 DNS-Anfragen gefiltert werden, braucht die Werbung vom Anbieter nur via IPv6 ausgeliefert werden. Die Werbung würde dann nicht rausgefiltert, da gemäß RFC 3484 IPv6 gegenüber IPv4 bevorzugt wird, und die DNS-Anfragenvia IPv6 garnicht am PiHole ankommen würden.

Von daher halte ich es schon für sinnvoll am PiHole sowohl IPv4 als auch IPv6 einzurichten.
Da sich in den meisten Fällen der IPv6-Präfix aufgrund der dynamischen Adresszuweisung des Providers ändern dürfte würde ich dabei jedoch (wie hier ja bereits angesprochen wurde) mit der LinkLocal-Adresse arbeiten.
Eine ULA-Adresse sollte nicht extra dafür generiert werden müssen.

Erfahrung mit dem Gerät hab ich persönlich keine.
Aber rein vom Datenblatt her sollte Kodi grundsätzlich damit funktionieren.

Leistungstechnisch ist hier aber nicht unbedingt mit viel zu rechnen.
Vor allem die Mali-G31 GPU dürfte nochmal deutlich schwächer sein als die in deinem KD-75XG9505 verbaute Mali-G71.
Das kann sich dann z.B. dadurch zeigen dass die Bedienung in den Menüs von Kodi schon hakelig ist. Musikvisualisierung wird möglicherweise auch nicht flüssig laufen.
Und 8 GB Flash-Speicher sind auch nicht gerade die Welt. Android zickt doch schon sehr wenn der Speicher knapp wird.

Dafür ist sie wohl Widevine L1 zertifiziert und ermöglicht damit das Streamen von Inhalten u.A. von Netflix, Amazon und Disney+ in höheren Auflösungen.

Ich möchte hier nochmal auf dieses Skript verweisen mit dem alles was man am Sony TV nicht essentiell benötigt erstmal deaktiviert wird.

Außerdem empfehle ich nach Ersteinrichtung bei einem Gerät generell mal alle Einstellungen durchzugehen.
Und natürlich bei der Inbetriebnahme nicht zu allem "Ja und Amen" zu sagen was einem da vorgesetzt wird