Beiträge von 00philip

    Windows Server 2025 hat nicht die gleichen Platformbeschränkungen wie Windows 11.

    Die Server Version läuft ohne TPM und auch ohne Secure Boot.

    Interessanter ist eher, dass auch Legacy-BIOS nach wie vor unterstützt wird. (siehe https://learn.microsoft.com/en-us/answers/…ver-2022-suppor)

    Ich habe die Standard Version schon einige Monate im Test, auf Proxmox mit alter Hardware, ohne TPM, Secure Boot, aber mit UEFI.

    Konnte noch keine Probleme, oder Einschränkungen feststellen.

    Danke dir erstmal für die Aufklärung.

    Ich habe via. SystemRescue mal die Festplatte zwischen 2 Surface Laptops mit dd kopiert.

    Damit lässt sich der Laptop dann normal in Windows booten.

    Sobald das Gerät einmal eine Internetverbindung hat, kommt beim nächsten Start ein Bootfehler.

    Das Gerät könne kein Device finden von dem es booten könne... ja ja - ging ja 1min vorher auch.

    Da müsstest du dich an die Leute von Atriva wenden und darum bitten, das Gerät aus dem Device Management raus zu nehmen.

    Na klasse...

    Dann kann das Gerät zurück an den Händler und ich muss mich wohl mal mit ihm unterhalten.

    Geräte gebraucht verkaufen, die noch an eine Organisation gebunden sind, ist fraglich...

    Ich google mir schon die Finger wund... es gibt wohl keine Alternative die Geräte ID zu spoofen

    und den Check an MS zu unterbinden, sprich das ganze zu umgehen?

    (edit)

    Ich habe gerade gelernt, dass der hinterlegte Installationsschlüssel im BIOS das Problem ist,

    keine Hardware ID oder Geräte ID, die man spoofen könnte.

    Tja, nun müsste man halt das BIOS flashen (können).

    Ich habe die Vermutung, das wird nicht ohne weiteres gehen... ;(

    Guten Abend!

    Ich kämpfe gerade mit einem Surface Laptop 4 und der Windows 10/11 Installation.

    Das Gerät ist gebraucht vom Händler mit Rechnung etc.

    Also Windows 10/11 ISO auf dem USB Stick (mit Rufus) und vom Stick gebooted.

    Screenshot 2025-10-07 195652.png

    Der Installer startet, ich lösche alle Partition, wähle die Festplatte, die Daten werden kopiert,

    der PC rebooted und danach start OOBE (out of the box experience).

    Ich wähle Sprache und Land, skippe Tastaturlayouts und prompt werde ich aufgefodert mich

    mit einem Netzwerk zu verbinden.

    Tue ich das, deaktiviere Pihole und lasse Windows seine Requests machen, lande ich folgenden
    Bildschirm:

    IMG_3043.jpg

    Bedeutet für mich, der Laptop war früher offenbar mit einem Geschäftskonto der Firma "Atriva Therapeutics" verbunden.

    Selbstverständlich habe ich keinen Zugriff auf die Organisation, Emails oder sonstiges.

    Ich komme also an der Stelle nicht weiter...

    Jetzt gibt's bekannte Tricks wie "OOBE bypassNRO", sprich den Internet-Zwang via. Registry Eintragung zu entfernen.

    Ich kann auch OOBE überspringen (SHIFT + F10)...

    IMG_3044.jpg IMG_3045.jpg

    ... und diese Funktion im UI auslösung.

    Ich dachte zwar, dass RUFUS dies eigentlich schon getan hätte.

    Aber leider werde immer aufgefordert wieder mich mit einem Netzwerk zu verbinden.

    Was ich auch tue, ich kann komm nicht an dem Schritt vorbei.

    Netzwerkadapter deaktivieren und sonstiges habe ich bereits probiert.

    Eine Installation via. autounattend.xml File habe ich auch schon probiert.

    Sogar das Anlegen des Benutzeraccounts, Löschen der Default-Apps etc. klappt im Hintergrund.

    Aber ich komme nicht weiter - ich lande immer wieder hier...

    (Beispielbild)

    connect-to-network-screen.jpg

    Ich habe auch bereits mit SystemRescue die Festplatte komplett gelöscht.

    Es scheint so, als verhindert irgendwas die Neuinstalltation des OS, ohne Anmeldung bei der Organisation.

    Ist das irgend eine Art von Branding - vielleicht im BIOS?

    Die Option "Ich habe kein Internet" existiert nicht, egal was ich tue auch via. Bypass-Methode.

    E G A L ob Windows 10 1909, 22H2, Windows 11 etc, Version Pro, Home, Enterprise etc.

    Wenn es nur das ist: Wie sagst du dem VPN Server denn, dass er die Pakete für die Fritzbox zur Fritzbox schicken soll, und nicht zu einem seiner anderen VPN Peers?

    Ja, kein Zweifel du hattest schon Rest.

    Eure Antworten überschneiden sich nur immer, mit dem was ich gerade schreibe - da sehe ich die Antwort noch nicht.

    Das ist doppelt gemoppelt, schadet aber auch nicht.

    Ja, es ging nur darum den Tunnel zum Laufen zu bringen.

    Die Clients von außen sind dann sowieso in einem anderen Subnetz, nämlich 172.16.0.0/24.

    Ich musste jetzt nur in der FRITZ!Box die Verbindung nochmal neu anlegen.

    Angepasst wurde AllowedIPs = 172.16.0.0/24 und passt nun zum Subnetz der Clients.

    ---

    Mal noch nebenbei eine Frage.

    Ausgehend davon, dass es mehrere Client gibt...

    Ist es in der Server Config relevant für die Peers die genaue Adresse zu bestimmen?

    Code
    [Peer]
    AllowedIPs = 172.16.0.1/32
    
    [Peer]
    AllowedIPs = 172.16.0.2/32
    
    [Peer]
    AllowedIPs = 172.16.0.3/32

    Oder soll ich bei den Peers 172.16.0.x/24 festlegen?

    Die FRITZ!Box schreibt ja in ihre eigene Interface Adresse auch 192.168.1.1/24 statt /32 Subnetzmaske.

    Jawohl, jetzt funktioniert die Verbindung wie erwartet.

    Tja... wenn sich zwei "streiten", ist der Dritte überfordert. :S

    wg server config

    FRITZ!Box config

    Code
    [Interface]
    Address = 192.168.1.1/24
    
    # wg server
    [Peer]
    AllowedIPs = 10.0.0.0/24

    iPhone config

    Code
    [Interface]
    Address = 10.0.0.2/32
    
    # wg server
    [Peer]
    AllowedIPs = 192.168.1.0/24

    Kommando zurück... funktioniert nicht - das Telefon war versehentlich im WLAN :pinch:

    Zitat

    The AllowedIPs entry means what IP addresses do we accept from this Peer (client)- if a network packet arrives from this peer via the wg0 interface the source IP address is checked- if it is not in this list it is dropped

    AllowedIPs im Wireguard Server ist tatsächlich die Source IP des Peer.

    Demnach müsste ja die Server-Config richtig sein.

    Code
    # FRITZ!Box
    [Peer]
    AllowedIPs = 192.168.1.1/32
    
    # iPhone
    [Peer]
    AllowedIPs = 10.0.0.2/32


    Das Subnetz der FRITZ!Box ist 192.168.1.0/24.

    Jetzt hat das iPhone folgende AllowedIPs = 10.0.0.0/24, 192.168.1.0/24
    Die FRITZ!Box hingegen folgende AllowedIPs = 10.0.0.0/24

    Das iPhone spricht in den Tunnel in ins private Netz der FRITZ!Box.
    Die FRITZ!Box spricht natürlich nur in den Tunnel.

    Habe ich das jetzt bis hier hin richtig verstanden?

    Dann liegt der Fehler in Firewall-Regeln?

    1. Wofür brauchst du die MASQURADE Regel? Es geht doch um einen Heimnetz-Zugang. Dafür brauchst du eigentlich gar kein NAT.
    2. Zur Fritzbox erlaubst du nur eine IP mit /32. Gehen wir davon aus, dass das die IP der Fritzbox ist, dann kannst du nur auf die Fritzbox zugreifen, aber nicht aufs Heimnetz

    Ich maskiere die IP damit, um nicht die öffentliche IP des Peers (als Source IP) im Tunnel zu haben.

    Das erleichert mir nachgelagerte Firewall Regeln, auf den Servern der Dienste.

    2. Genau - das war der Fehler.

    Umgekehrt müssen die AllowedIPs des Servers als Peer der Fritzbox die Adressen umfassen, die du von der Fritzbox bzw. aus dem Heimnetz erreichen möchtest (iPhone und ggf Server. Erreichen ist auch im Sinne von Antwortpaketen gemeint, nicht nur, wer eine Verbindung wohin aufbauen darf).

    Ahh natürlich, da liegt der Fehler.

    Die FRITZ!Box antwortet und sendet ein Paket an 10.0.0.2 (iPhone).

    Das Paket wird aber verworfen, da der Tunnel für den Peer nur allowed ips: 192.168.1.1/32 gesetzt hat.

    Ich habe für den Peer (FRITZ!Box) jetzt allowed ips: 192.168.1.1/32, 10.0.0.0/24 gesetzt.
    Damit kann sie ihre Antworten ins Netz 10.0.0.0/24 senden und folglich 10.0.0.2 erreichen.

    Funktioniert!

    Ich danke euch beiden...  :thumbup:

    Anbei die Konfiguration des Peers (iPhone):

    IMG_2986.png

    Anbei die Konfiguration des Peers (FRITZ!Box):

    Code
    [Peer]
    PublicKey = ...
    PresharedKey = ...
    AllowedIPs = 10.0.0.0/24
    Endpoint = ...
    PersistentKeepalive = 5

    Die AllowedIPs eines Peers sind nicht die Adressen, die der Peer ansprechen darf, sondern die, die er selbst verwenden darf, die also als Source-Adresse in Paketen vom Peer durch den Tunnel kommen dürfen.

    Wie müssten demnach die AllowedIPs der Geräte so aussehen?

    Hallo in die Runde.

    Ich liede unter ständigem Kabelinternetausfall; ist nix neues in Deutschland...

    Als Ausfallschutz fungiert Mobilfunk.

    CGNAT ist aber natürlich ein Problem, wenn ich paar Dienste (Zuhause) trotzdem unterwegs erreichen möchte.

    Ich betreibe eigene DNS-Server und habe somit DynDNS bereits eingerichtet.

    Als Gateway möchte ich einen Wireguard Server benutzen.

    Der Server dafür ist via. IPv4 und IPv6 ständig erreichbar und innerhalb des Tunnels wird nur IPv4 gesprochen.


    Schema:

    FRITZ!Box <> Wireguard Server <> iPhone (oder jegliches andere Gerät)

    Ich habe Probleme mit dem Routing.

    wg show

    Die Verbindung zu beiden Peers steht und funktioniert.

    Vom iPhone aus kann ich aber keinen Dienst im Heimnetzwerk erreichen.

    tcpdump -i wg0 (Wireguard Server)

    Code
    18:21:49.363383 IP 10.0.0.2.51741 > 192.168.1.25.http: Flags [S], seq 312869043, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 135182193 ecr 0,sackOK,eol], length 0
    18:21:57.363623 IP 10.0.0.2.51741 > 192.168.1.25.http: Flags [S], seq 312869043, win 65535, options [mss 1240,nop,wscale 6,nop,nop,TS val 135190198 ecr 0,sackOK,eol], length 0

    Hinter 192.168.1.25 steht ein Server auf dem ein Webserver läuft, zu Testzwecken mit offener Firewall.

    Der Webserver erhält keine Anfrage.

    Was ist denn falsch?

    Das iPhone soll Zugriff auf das (gesamte) Heimnetz bekommen. Dies kann ich später noch einschränken... AllowedIPs = 10.0.0.2/32, 192.168.1.0/24

    Hallo in die Runde.

    Mich beschäftigt derzeit die Smarthome-Automation bzw. dessen Datenanalytik.

    Neben PV-Analytik via. Telegraf (HTTP requests zur Wechselrichter API/Smartmeter API), betreibe ich

    auch kleine Helferchen wie Stromleser (Tasmota) am intelligenten Messsystem und am Gaszähler.

    Soweit so gut...

    Der Gaszähler sendet seine Daten an den MQTT Server.

    Topic: tasmota/gas/data/# bzw. tasmota/gas/json

    Screenshot 2025-06-04 164758.png

    Die Struktur der Daten lege ich selbst fest.

    Jene Daten ausschließlich als Objekt (JSON) an MQTT zusenden, wäre mir bzgl. der Weiterverarbeitung am liebsten.

    Zum Problem...

    Das Abrufen und Einlesen der Daten in InfluxDB 2 via. Telegraf, geschieht mit folgender Config:


    Die Struktur in der Datenbank sieht wie folgt aus:

    pasted-from-clipboard.png

    Sofern ich versuche das Objekt (JSON) einzulesen, wird einfach nichts draus...
    Entweder speichert die Datenbank die Daten gar nicht oder völlig falsch formatiert.

    Ändere ich das data_format von inputs.mqtt_consumer auf json_v2 klappt nichts mehr.

    inputs.mqtt_consumer.topic_parsing müsste doch eigentlich gleich bleiben oder nicht?

    Mit den Optionen inputs.mqtt_consumer.json_v2.object und inputs.mqtt_consumer.json_v2.field konnt ich nichts so richtig anfangen, beim herumprobieren.

    Ich möchte das (flache) Objekt (JSON) einfach nur via. Telegraf, exakt wie beide anderen Felder, in die Datenbank importieren.

    Leider verzweifle ich daran...

    (EDIT) Ein bisschen weniger kompliziert ausgedrückt...
    Ich möchte die Keys im Objekt (counter_m3, total_m3) als field in der Datenbank.
    Die Topic der Daten bleibt entsprechend gleich (tasmota/data/json).

    Vielleicht gibt's einen findigen Helfer oder mehrere :)

    Danke vorab.

    Besten Dank an euch beide.

    Die Regeln habe ich entsprechend ergänzt bzw. korrigiert.

    In der MAILCOW Chain existiert seit Anfang Februar eine Regel, die genau diesen Zugriff verhindern soll: https://mailcow.email/posts/2024/rel…d-february-2024

    Danke für den Hinweis, das ist mir wohl entgangen.

    Ich habe DISABLE_NETFILTER_ISOLATION_RULE in der Config angepasst und die entsprechende Regel in der Kette DOCKER-USER eingefügt.

    Nach dem Stoppen aller Container wurden alle Standardregeln (inkl. der neuen/notwendigen) via. Paket iptables-persistent (rebootsicher) gespeichert.

    Damit gibt's auch keine Probleme und Unstimmigkeiten durch die von Docker kontrollierte Firewall und weiterer meiner Regeln.

    Problem gelöst! :thumbup:

    Einen schönen guten Tag in Runde,

    ich betriebe eine Mailcow Instanz und habe ein kleines Routing-Problem.

    Gewünscht ist eine Verbindung zum Container "mysql-mailcow" (MariaDB) von einer externen Quelle (Server).
    Dazu habe ich dem entsprechenden Container eine statische IP Adresse zugewiesen (172.22.1.99).
    Der Zielport ist Standard - 3306.

    Standardmäßig werden jene Verbindungen zum Mailcow-Server verweigert.

    Zum Port-Forwarding habe ich folgende iptables Regel hinzugefügt:

    -I PREROUTING -s 1.2.3.4/32 -p tcp -m tcp --dport 3306 -j DNAT --to-destination 172.22.1.99:3306

    Die Source IP (1.2.3.4) habe ich zensiert.

    Entsprechend habe ich eine weitere Regel in die FORWARD Tabelle (DOCKER-USER) hinzugefügt:

    -I DOCKER-USER -p tcp -m tcp --dport 3306 -j ACCEPT

    Leider bekomme ich nun eine Timeout bei Verbindungsversuch, anstatt dass die Verbindung wie zuvor verweigert wird.

    Was habe ich denn übersehen?

    Besten Dank vorab! :S

    Anbei eine Übersicht der aller Regeln: