Gespräch:DNS Server dnsmasq FritzBox

Über diese Seite Gespräch

Server dnsmasq FritzBox
ChatGPT Sophos GPT-4
7. März 2025 n. Chr. erst.
Ausgabe 00
Ausgabe 00
unüberarbeitet ungeprüft
keine Datei

Hilf mir bei der Installation

Sophos:

Gerne, welche Installation möchtest du ausführen?

Nikolaos:

Wir haben meinen Mac mini M1 als DNS Server mit dnsmasq eingerichtet. Im LAN funktioniert es offenbar jedoch über WLAN nicht. Muß dazu ide Fritz!Box als Mesh Repeater umgestellt werden?

IN der Fritzbox finde ich keine Einstellungen dafür das WLAN und LAN unterschiedliche IP Bereiche haben.

scutil --dns

DNS configuration

resolver #1

nameserver[0] : 192.168.2.3

flags : Request A records

reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

resolver #2

domain : local

options : mdns

timeout : 5

flags : Request A records

reach : 0x00000000 (Not Reachable)

order : 300000

resolver #3

domain : 254.169.in-addr.arpa

options : mdns

timeout : 5

flags : Request A records

reach : 0x00000000 (Not Reachable)

order : 300200

resolver #4

domain : 8.e.f.ip6.arpa

options : mdns

timeout : 5

flags : Request A records

reach : 0x00000000 (Not Reachable)

order : 300400

resolver #5

domain : 9.e.f.ip6.arpa

options : mdns

timeout : 5

flags : Request A records

reach : 0x00000000 (Not Reachable)

order : 300600

resolver #6

domain : a.e.f.ip6.arpa

options : mdns

timeout : 5

flags : Request A records

reach : 0x00000000 (Not Reachable)

order : 300800

resolver #7

domain : b.e.f.ip6.arpa

options : mdns

timeout : 5

flags : Request A records

reach : 0x00000000 (Not Reachable)

order : 301000

resolver #8

domain : aewi

nameserver[0] : 127.0.0.1

flags : Request A records, Request AAAA records

reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

DNS configuration (for scoped queries)

resolver #1

nameserver[0] : 192.168.2.3

if_index : 6 (en0)

flags : Scoped, Request A records

reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

dnsmasq Einstellungen:

# Setze die DNS-Anfragen für die internen Domains auf den Server 192.168.2.3

address=/aewi.de/192.168.2.3

address=/wiki.aewi.de/192.168.2.3

address=/api.aewi.de/192.168.2.3

address=/pma.aewi.de/192.168.2.3

dhcp-range=192.168.2.100,192.168.2.200,12h

dhcp-option=15,aewi.de

listen-address=127.0.0.1,192.168.2.3,10.0.0.1

# Verwende die Fritz!Box als Upstream-DNS-Server

server=192.168.2.1

# Aktiviere Caching für DNS-Anfragen

cache-size=1000

# Log-Datei für Debugging

log-queries

log-facility=/var/log/dnsmasq.log

2/2

Sophos:

Das Problem scheint darauf hinzudeuten, dass DNS-Anfragen über WLAN nicht ordnungsgemäß weitergeleitet werden, während es über LAN funktioniert. Hier sind einige Punkte, die du prüfen und anpassen kannst:

1. Prüfen, ob LAN und WLAN im selben Subnetz sind

Du sagst, dass in der Fritz!Box keine Trennung zwischen LAN und WLAN zu sehen ist, aber um sicherzugehen:
Gehe in die Fritz!Box Oberfläche (192.168.2.1) → Heimnetz → Netzwerk → Netzwerkeinstellungen.
Überprüfe, ob „Die Geräte dürfen untereinander kommunizieren“ aktiviert ist.
Falls die Fritz!Box Mesh aktiviert hat und der Repeater-Modus genutzt wird, sollte das Netzwerk für WLAN und LAN identisch sein.

2. Prüfen, ob DNS-Anfragen über WLAN blockiert werden

Über Terminal auf einem WLAN-Gerät (z. B. Mac oder iPhone): sh KopierenBearbeiten nslookup wiki.aewi.de 192.168.2.3
- Falls keine Antwort kommt, wird die DNS-Anfrage nicht an dnsmasq auf dem Mac mini weitergeleitet.
- Falls eine Antwort kommt, aber die Seiten trotzdem nicht aufrufbar sind, könnte es ein Caching- oder Routing-Problem sein.

3. Sicherstellen, dass dnsmasq auf allen Interfaces lauscht

In deiner dnsmasq-Konfiguration steht:

ini

KopierenBearbeiten

listen-address=127.0.0.1,192.168.2.3,10.0.0.1

Ändere das auf: ini KopierenBearbeiten listen-address=0.0.0.0
Das sorgt dafür, dass dnsmasq auf allen Interfaces (WLAN und LAN) lauscht.
Danach dnsmasq neu starten: sh KopierenBearbeiten sudo brew services restart dnsmasq

4. WLAN-Clients dazu bringen, den richtigen DNS-Server zu nutzen

Falls WLAN-Clients trotzdem noch nicht deinen DNS-Server 192.168.2.3 nutzen:

Prüfe in Systemeinstellungen → Netzwerk auf dem Mac oder in der Fritz!Box unter Heimnetz → Netzwerk → Netzwerkeinstellungen → DHCP-Server.
Falls die Fritz!Box die DNS-Servereinstellungen überschreibt, kannst du unter Netzwerkeinstellungen explizit 192.168.2.3 als primären DNS-Server setzen.

5. DNS-Log prüfen

Falls es immer noch nicht geht, schau in das dnsmasq-Log:

sh

KopierenBearbeiten

tail -f /var/log/dnsmasq.log

Siehst du dort Anfragen von WLAN-Clients? Falls nicht, blockiert die Fritz!Box möglicherweise DNS-Weiterleitungen.

6. Mesh oder Repeater-Modus?

Falls die Fritz!Box als Mesh-Repeater läuft und eine eigene IP-Adresse aus einem anderen Subnetz vergibt, kann das Problem verursachen.
Falls die Fritz!Box als „IP-Client“ oder Bridge-Modus konfiguriert ist, sollten alle Geräte im gleichen Netzwerk bleiben.
Falls du einen zusätzlichen Repeater hast, stelle sicher, dass „WLAN-Clients unterschiedliche IP-Adressen erhalten“ deaktiviert ist.

Fazit

Teste zuerst mit nslookup, ob Anfragen über WLAN deinen Mac mini erreichen. Falls nicht, ändere die dnsmasq-Einstellungen auf listen-address=0.0.0.0 und prüfe, ob die Fritz!Box DNS-Anfragen für WLAN-Clients umleitet.

Falls nötig, kannst du in der Fritz!Box explizit deinen Mac mini als DNS-Server hinterlegen. Falls du einen Fritz!Repeater verwendest, sollte er sich im Bridge-Modus befinden.

Lass mich wissen, ob es danach klappt! 🚀

Nikolaos:

vom M2 über WLAN getestet: nslookup wiki.aewi.de 192.168.2.3

Server: 192.168.2.3

Address: 192.168.2.3#53

Name: wiki.aewi.de

Address: 192.168.2.3

Ich kann schon auf Webseiten wie Wikipedia zugreifen, jedoch funktioniert SSO und oAuth nicht

2/2

Sophos:

Da dein DNS-Server (dnsmasq auf dem Mac mini M1) korrekt funktioniert und Anfragen über WLAN richtig aufgelöst werden, scheint das Problem mit SSO (Single Sign-On) und OAuth eher ein Cross-Origin- oder Netzwerkproblem zu sein. Lass uns das strukturiert analysieren:

1. Prüfen, ob die richtige URL verwendet wird

OAuth- und SSO-Systeme verwenden oft Redirect-URIs, die exakt übereinstimmen müssen.
Falls du z. B. https://wiki.aewi.de als OAuth-Redirect-URI nutzt, stelle sicher, dass:
- Dein lokaler DNS diese Domain wirklich auf 192.168.2.3 auflöst.
- Dein OAuth-Provider dieselbe Redirect-URI erwartet (nicht http://192.168.2.3 statt https://wiki.aewi.de).

Teste auf dem Mac mini M2:

sh

KopierenBearbeiten

curl -v https://wiki.aewi.de

Falls es einen SSL-Zertifikatsfehler gibt, könnte dies die Ursache sein.

2. Überprüfung von SSL-Zertifikaten

Falls OAuth oder SSO HTTPS benötigt, aber dein wiki.aewi.de ein selbstsigniertes Zertifikat hat, dann:

Browsere blockieren solche Anfragen oft stillschweigend.
OAuth-Dienste wie Google oder Microsoft lehnen Anfragen von nicht-verifizierten Domains ab.

Lösung: LetsEncrypt-Zertifikat für wiki.aewi.de generieren

Falls du ein selbstsigniertes Zertifikat hast, kannst du LetsEncrypt mit DNS-Verifikation nutzen:

sh

KopierenBearbeiten

sudo certbot certonly --manual --preferred-challenges=dns --email deine@email.de -d wiki.aewi.de

Falls du bereits ein Zertifikat hast, prüfe, ob es korrekt eingebunden ist.

3. Ist wiki.aewi.de intern und extern gleich erreichbar?

Falls OAuth ein externes System nutzt (z. B. Google, Keycloak, Auth0), dann:

Prüfe, ob die öffentliche IP von wiki.aewi.de von außen auf die gleiche Webseite zeigt wie im internen Netz.
Falls nicht, dann kann der OAuth-Provider Redirects ablehnen, weil wiki.aewi.de von innen und außen unterschiedliche Antworten gibt.

Lösung:

Falls wiki.aewi.de öffentlich nicht existiert oder eine andere IP hat:

Füge wiki.aewi.de in /etc/hosts aller betroffenen Rechner ein.
Falls du von außen erreichbar sein möchtest, setze eine Portweiterleitung in der Fritz!Box für HTTPS (Port 443).

4. DNS-Cache leeren & Browser-Cache prüfen

Falls Änderungen gemacht wurden, stelle sicher, dass keine alten DNS- oder Browser-Caches stören:

Auf macOS: sh KopierenBearbeiten sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
In Chrome/Firefox/Edge: Öffne Developer Tools (F12) → Reiter Netzwerk → Häkchen bei Cache deaktivieren.

5. OAuth-Fehlermeldungen prüfen

Falls OAuth nicht funktioniert:

Schau in den Browser-Logs (F12 → Konsole) nach Fehlern.
Falls du einen 403 oder 400 OAuth-Fehler siehst:
- Prüfe, ob der OAuth-Provider das Protokoll (http vs. https) und den Hostnamen (wiki.aewi.de) akzeptiert.
Falls CORS-Fehler auftreten:
- Prüfe, ob der Webserver CORS (Access-Control-Allow-Origin) richtig setzt.

6. Apache/Nginx Logs prüfen

Falls dein Webserver die Authentifizierung ablehnt, prüfe die Logs:

sh

KopierenBearbeiten

sudo tail -f /var/log/apache2/access.log

sudo tail -f /var/log/apache2/error.log

Oder falls du Nginx nutzt:

sh

KopierenBearbeiten

sudo tail -f /var/log/nginx/access.log

sudo tail -f /var/log/nginx/error.log

Fazit

✅ Dein DNS funktioniert bereits, da nslookup wiki.aewi.de die korrekte Antwort gibt.

🚨 Das Problem liegt vermutlich an:

OAuth Redirect-URI-Fehler (falsche URL hinterlegt)
SSL-Zertifikatsproblemen (OAuth benötigt oft gültige HTTPS-URLs)
Unterschiedlichen internen/externen DNS-Auflösungen (wiki.aewi.de intern ≠ extern)
Cache oder CORS-Problemen

Teste mal Punkt 1-3 und gib mir Bescheid, was du herausfindest! 🚀

Nikolaos:

Test Mac mini M2 WLAN:

1. curl -v https://wiki.aewi.de

* Host wiki.aewi.de:443 was resolved.

* IPv6: (none)

* IPv4: 192.168.2.3

* Trying 192.168.2.3:443...

* Connected to wiki.aewi.de (192.168.2.3) port 443

* ALPN: curl offers h2,http/1.1

* (304) (OUT), TLS handshake, Client hello (1):

* CAfile: /etc/ssl/cert.pem

* CApath: none

* (304) (IN), TLS handshake, Server hello (2):

* (304) (IN), TLS handshake, Unknown (8):

* (304) (IN), TLS handshake, Certificate (11):

* (304) (IN), TLS handshake, CERT verify (15):

* (304) (IN), TLS handshake, Finished (20):

* (304) (OUT), TLS handshake, Finished (20):

* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF

* ALPN: server accepted http/1.1

* Server certificate:

* subject: CN=aewi.de

* start date: Feb 28 13:11:30 2025 GMT

* expire date: May 29 13:11:29 2025 GMT

* subjectAltName: host "wiki.aewi.de" matched cert's "wiki.aewi.de"

* issuer: C=US; O=Let's Encrypt; CN=E6

* SSL certificate verify ok.

* using HTTP/1.x

> GET / HTTP/1.1

> Host: wiki.aewi.de

> User-Agent: curl/8.7.1

> Accept: */*

>

* Request completely sent off

< HTTP/1.1 301 Moved Permanently

< Date: Fri, 07 Mar 2025 12:42:01 GMT

< Server: Apache/2.4.63 (Unix) OpenSSL/3.4.1

< Location: https://de.wikipedia.org/w/index.php

< Content-Length: 248

< Content-Type: text/html; charset=iso-8859-1

<

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<title>301 Moved Permanently</title>

</head><body>

<h1>Moved Permanently</h1>

<p>The document has moved <a href="https://de.wikipedia.org/w/index.php">here</a>.</p>

</body></html>

* Connection #0 to host wiki.aewi.de left intact

2. sudo certbot certonly --manual --preferred-challenges=dns --email deine@email.de -d wiki.aewi.de

Password:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Requesting a certificate for wiki.aewi.de

Successfully received certificate.

Certificate is saved at: /etc/letsencrypt/live/wiki.aewi.de/fullchain.pem

Key is saved at: /etc/letsencrypt/live/wiki.aewi.de/privkey.pem

This certificate expires on 2025-06-05.

These files will be updated when the certificate renews.

NEXT STEPS:

- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

If you like Certbot, please consider supporting our work by:

* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate

* Donating to EFF: https://eff.org/donate-le

2/2

Sophos:

Analyse der aktuellen Ergebnisse

✅ DNS und SSL-Zertifikat funktionieren korrekt

curl zeigt, dass wiki.aewi.de korrekt auf 192.168.2.3 aufgelöst wird.
Das Let's Encrypt-Zertifikat wurde erfolgreich ausgestellt und ist gültig.
Die Umleitung auf https://de.wikipedia.org/w/index.php funktioniert ebenfalls.

🚨 Problem: SSO & OAuth funktionieren nicht

Da DNS und SSL korrekt sind, müssen wir uns jetzt auf folgende Fehlerquellen konzentrieren:

OAuth-Redirect-URI-Probleme
CORS-Fehler oder SameSite-Cookie-Probleme
Apache- oder MediaWiki-Konfiguration
Firewall oder Netzwerkprobleme mit OAuth-Providern

1. OAuth-Redirect-URI prüfen

Viele OAuth-Provider (Google, Microsoft, Keycloak etc.) blockieren Anfragen, wenn die Redirect-URI nicht exakt mit der in der OAuth-Konfiguration hinterlegten URL übereinstimmt.

Teste mit einem Webbrowser

Öffne die Developer Tools (F12) → Reiter Netzwerk
Filtere nach „oauth“ oder „redirect“ und prüfe:
- Wird eine falsche Redirect-URI verwendet?
- Gibt es eine 403 Forbidden oder 400 Bad Request-Fehlermeldung?

Lösung

Falls die Redirect-URI anders ist als erwartet, dann:

Gehe zur OAuth-Konfiguration deines Anbieters (z. B. Google Developer Console oder Keycloak).
Stelle sicher, dass die URI exakt so eingetragen ist, wie sie im Fehler steht.
Falls du http://192.168.2.3 statt https://wiki.aewi.de siehst, dann prüfe LocalSettings.php (siehe Punkt 3).

2. CORS oder Cookie-Probleme

OAuth benötigt oft Cross-Origin-Anfragen, die blockiert werden können.

Prüfe Fehler in der Browser-Konsole

Öffne die Konsole (F12) und prüfe auf CORS-Fehlermeldungen:

Fehlermeldungen wie „CORS policy: No 'Access-Control-Allow-Origin' header is present“? → Lösung: In Apache oder LocalSettings.php CORS aktivieren.
Fehlermeldungen zu SameSite oder Blocked third-party cookie? → Lösung: Falls der OAuth-Provider SameSite=Strict oder Lax erwartet, könnte das ein Problem sein.

Lösung: CORS in Apache aktivieren

Falls CORS-Probleme auftreten, ergänze in der Apache conf-Datei (/etc/apache2/sites-available/wiki.aewi.de.conf):

apache

KopierenBearbeiten

Header always set Access-Control-Allow-Origin "*"

Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS"

Header always set Access-Control-Allow-Headers "Authorization, Content-Type"

</IfModule>

Danach Apache neu starten:

sh

KopierenBearbeiten

sudo systemctl restart apache2

Lösung: Cookies mit SameSite=None; Secure setzen

Falls OAuth SameSite-Probleme macht, setze in LocalSettings.php:

php

KopierenBearbeiten

$wgCookieSameSite = "None";

$wgCookieSecure = true;

3. Apache & MediaWiki Konfiguration prüfen

Falls OAuth nach dem Login auf eine falsche URL weiterleitet, prüfe LocalSettings.php.

Check: Ist die $wgServer-Einstellung korrekt?

Öffne LocalSettings.php und stelle sicher, dass:

php

KopierenBearbeiten

$wgServer = "https://wiki.aewi.de";

Falls du noch http://192.168.2.3 siehst, dann ändere es zu https://wiki.aewi.de, damit OAuth-Redirects korrekt funktionieren.

4. Firewall oder Netzwerkfilter blockieren OAuth?

Falls dein OAuth-Provider außerhalb deines Netzwerks liegt (Google, Microsoft, Keycloak), prüfe:

Teste die Erreichbarkeit des OAuth-Providers

sh

KopierenBearbeiten

curl -v https://accounts.google.com

curl -v https://keycloak.deinserver.de

Falls diese Anfragen fehlschlagen:

Prüfe die Firewall der Fritz!Box (eventuell blockiert sie ausgehende OAuth-Anfragen)
Falls du eine zusätzliche Firewall auf macOS oder iptables nutzt, deaktiviere sie testweise: sh KopierenBearbeiten sudo pfctl -d # (Falls pf aktiv ist)
sudo iptables -F # (Falls iptables aktiv ist)

Zusammenfassung & Nächste Schritte

✅ Dein SSL-Zertifikat und DNS sind korrekt eingerichtet.

🚨 Das Problem liegt wahrscheinlich an einer falschen Redirect-URI, CORS-Problemen oder Cookie-Restriktionen.

Schritte zur Lösung:

1️⃣ Prüfe die OAuth-Redirect-URI in der Developer-Konsole (Google/Microsoft/Keycloak).

2️⃣ Falls CORS-Fehler auftreten, setze Access-Control-Allow-Origin in Apache.

3️⃣ Falls OAuth nach http://192.168.2.3 statt https://wiki.aewi.de umleitet, korrigiere $wgServer in LocalSettings.php.

4️⃣ Teste, ob die Firewall OAuth-Anfragen blockiert (curl -v https://accounts.google.com).

🔎 Falls das Problem weiterhin besteht, poste die genaue Fehlermeldung von OAuth! 🚀

Nikolaos:

Danke für all diese Informationen. Es scheint ein Cookie Problem gewesen zu sein. Ich habe die Webseiten Daten gelöscht. Vielleicht komme ich doch wieder darauf zurück weil es nicht mein iPad war, daß nicht ging, bei dem waren Cookies generell abgeschaltet.

Sophos:

Gern geschehen! 😊 Es klingt ganz danach, dass das Problem mit den Cookies und deren SameSite-Einstellungen zusammenhing – besonders, wenn OAuth involviert ist. Wenn Cookies deaktiviert sind oder alte, inkonsistente Daten gespeichert sind, kann das schnell zu Authentifizierungsproblemen führen.

Falls es auf anderen Geräten (wie dem iPad) weiterhin nicht funktioniert, prüfe:

Sind Cookies dort wirklich erlaubt? → Einstellungen → Safari → „Alle Cookies blockieren“ deaktivieren → Falls du Chrome nutzt: chrome://settings/cookies prüfen
Private Browsing/Inkognito-Modus? → Safari blockiert Drittanbieter-Cookies im privaten Modus, was OAuth brechen kann.
Ist wgCookieSameSite = "None"; und wgCookieSecure = true; noch gesetzt?
Sind Browser-Addons aktiv, die Cookies oder Tracker blockieren? → uBlock Origin, Brave Shields oder Firefox Enhanced Tracking Protection könnten Probleme machen.

Falls das Problem auf dem iPad bleibt, kannst du dort mal in Entwicklertools (macOS) → Safari → Entwickler-Menü → Web-Inspektor schauen und prüfen, welche Cookies oder Anfragen fehlschlagen.

Melde dich gerne, wenn es wieder zickt! 🚀