OPNsense Forum
International Forums => German - Deutsch => Topic started by: Marcel_75 on August 11, 2020, 01:20:08 pm
-
Hallo zusammen,
ich versuche mich mal an diesen Empfehlungen zu orientieren:
https://forum.opnsense.org/index.php?topic=12697.0
Folgender Fehler tritt auf: Die lokale Namens-Auflösung funktioniert nur, wenn auch mein Pi-hole als DNS-Server eingetragen ist, nicht jedoch wenn ich die OPNsense als alleinigen DNS-Server definiere.
Aufgefallen ist mir das leider erst jetzt bei einer manuellen Netzwerkeinstellung, denn per DHCP werden am Client als DNS-Server 10.89.89.11 (mein Pi-hole) und 10.5.5.1 (meine OPNsense) eingetragen (und damit funktioniert es wie gesagt auch).
D.h., wenn ich die Netzwerkeinstellungen per DHCP empfange, kann ich z.B. meinen iMac lokal auflösen (denn im Pi-hole sind diese als "Local DNS Records" eingetragen, siehe Screenshot "pi-hole-local-dns-records.gif"):
nslookup imac.localdomain
Server: 10.89.89.11
Address: 10.89.89.11#53
Name: imac.localdomain
Address: 10.5.5.199
Auch die Rückwärtsauflösung klappt problemlos:
nslookup 10.5.5.199
Server: 10.89.89.11
Address: 10.89.89.11#53
199.5.5.10.in-addr.arpa name = imac.localdomain.
Wenn als DNS-Server bei einer manuellen Netzwerkeinstellung jedoch ausschließlich meine OPNsense (10.5.5.1) als DNS-Server eingetragen ist, klappt es leider nicht:
nslookup imac
Server: 10.5.5.1
Address: 10.5.5.1#53
** server can't find imac: NXDOMAIN
nslookup imac.localdomain
Server: 10.5.5.1
Address: 10.5.5.1#53
** server can't find imac.localdomain: NXDOMAIN
nslookup 10.5.5.199
Server: 10.5.5.1
Address: 10.5.5.1#53
** server can't find 199.5.5.10.in-addr.arpa: NXDOMAIN
In Services / Unbound DNS / Overrides ist natürlich ein entsprechender Eintrag vorhanden (siehe Screenshot "OPNsense-Unbound-Overrides.png").
Da ich auch BIND mit DNSBL nutze, steht in den "Custom options" unter Services / Unbound DNS / General folgendes:
forward-zone:
name: „.“
forward-addr: 127.0.0.1@53530
D.h., den bis vor kurzem dort noch vorhandenen Eintrag
do-not-query-localhost: no
habe ich entfernt, aufgrund dieses Hinweises (ganz unten im Bereich "Advanced"):
https://docs.opnsense.org/manual/how-tos/bind.html
Aber vermutlich habe ich das einfach noch nicht korrekt verstanden und umgesetzt?
Anbei auch mein Netzwerkplan als Grafik (netzaufbau-double-nat.gif).
Danke vielmals im Voraus für Eure Unterstützung.
-
Frage 1: wer ist den forwarder für wen?
Frage 2: welcher DNS hält die lokalen DNS-Einträge?
Frage 3: hast Du mal die Reihenfolge (im dhcp) der dns-Server umgedreht und dann getestet?
-
Noch ne Frage: welchen Grund hat es, das Du den pihole vor der opnsense an der fritzbox betrteibst?
-
Noch ne Frage: welchen Grund hat es, das Du den pihole vor der opnsense an der fritzbox betrteibst?
Das hatte ganz einfach den Grund, dass auch Gäste in den Genuss eines Werbe- und Tracking-Blockers kommen sollten, aber ohne Zugriff auf mein 10.5.5.0/24-Netzwerk und vor allem die damit verbundenen Geräte.
D.h., Gäste bekommen Wi-Fi nur von der Fritzbox und sind somit im 10.89.89.0/24-Netzwerk, DNS macht dort ausschließlich der Pi-hole mit der 10.89.89.11.
-
Frage 1: wer ist den forwarder für wen?
Frage 2: welcher DNS hält die lokalen DNS-Einträge?
Frage 3: hast Du mal die Reihenfolge (im dhcp) der dns-Server umgedreht und dann getestet?
Frage 1: Wo/wie kann ich das prüfen? Bin leider kein Netzwerk-Experte … Danke für präzisere Erläuterung der Frage.
Frage 2: Wie schon eingangs beschrieben sowohl der Pi-hole (durch manuell hinzugefügte "Local DNS Records"), als auch die OPNsense (durch manuell hinzugefügte "Overrides" Einträge im Unbound DNS).
Frage 3: Das habe ich noch nicht gemacht.
Mag zwar sein, dass er so dann erst bei der OPNsense gucken würde, dort nichts findet und dann auf dem Pi-hole schaut und die entsprechenden "Treffer" liefert …
Aber das ist ja nicht mein Ziel!
Ich möchte, dass die lokale DNS-Auflösung auch komplett ohne Pi-hole funktioniert und korrekte Werte zurückliefert.
Also mit meiner Unbound DNS + BIND Variante.
Ergänzung: Ich habe die Reihenfolge zum Test jetzt mal kurz umgedreht, sprich 10.5.5.1 (OPNsense) als 1. DNS und 10.89.89.11 (Pi-hole) als 2. DNS eingetragen. Da kommt es genauso zum Abbruch, als wenn nur 10.5.5.1 (OPNsense) drin stehen würde, d.h. es wird leider gar nicht erst versucht, noch zusätzlich auf der 10.89.89.11 (Pi-hole) zu schauen.
Nur wenn ich die Reihenfolge so lasse, also 10.89.89.11 (Pi-hole) als 1. DNS und 10.5.5.1 (OPNsense) als 2. DNS, bekomme ich die gewünschten Ergebnisse der lokalen DNS Auflösung.
-
So, nun ich wieder ;D :
zu Frage 1:
Wie sind die Systeme "kaskadiert" - d.h. wen fragt der pihole als übergeordneten DNS und wen fragt die opnsense als übergeordneten DNS?
Wenn du also den pihole immer als primären DNS haben möchtest, muß dieser die fritzbox als primäfren DNS nutzen. Die opnsense nun muß wiederrum den pihole als DNS eingetragen haben.
Dann sollte die opnsense bei Anfragen, die sie ncht selber beantworten kann, den pihole fragen und der leitet die Anfrage dann an die fritzbox weiter, wenn er auch keine Informationen zu der Anfrage hat.
Ich hoffe, ich konnt meine Frage etwas mit den Ausführungen bessser formulieren.
zu Frage 2:
vom Sicherheitssapekt sicher ok. Das unangenehme an Deiner Config ist, das Du an zwei Stellen lokale Einträge pflegen mußt.
zu Frage 3:
Eine Sache habe ich vorhin überlesen - sorry: Du nutzt unbound und bind gleichzeitig? Beide Dienste lauschen auf dem gleichen Port (TCP 53) Kann es sein, das keiner von beiden sauber läuft?
Das würde erklären, warum die opnsens so gar nicht auf DNS-Anfragen reagiert, was Deine Tests ja zeigen. Ich denke, Deine lokale Auflösung kommt rein vom pihole - kann das sein?
Deaktiviere doch mal zum testen den bind und versuche dann eine DNS-Anfrage gegen die opnsense. im unbounf hast Du auch die Möglichkeit, unter "Blacklists" eine ähnliche Funktionalität des pihols zu implementieren.
Und noch eine Idee: sind Deine Netze in den Access Lists des unbound eingetragen? Wenn nicht, nimmt dieser keine Anfragen an.
-
Mmh, das hätte ich vllt. extra erwähnen sollen:
Die DNS-Auflösung "nach draußen" funktioniert eigentlich in der OPNsense, Unbound DNS auf Port 53 und BIND ist zusätzlich auf Port 53530 für DNSBL vorgesehen (also als DNS blacklist, eine Art Pi-hole Ersatz mit verschiedenen Blocklisten).
dig @10.5.5.1 -p 53 heise.de
; <<>> DiG 9.10.6 <<>> @10.5.5.1 -p 53 heise.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34533
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;heise.de. IN A
;; ANSWER SECTION:
heise.de. 6397 IN A 193.99.144.80
;; Query time: 30 msec
;; SERVER: 10.5.5.1#53(10.5.5.1)
;; WHEN: Tue Aug 11 17:25:42 CEST 2020
;; MSG SIZE rcvd: 53
sowie
dig @10.89.89.11 -p 53 heise.de
; <<>> DiG 9.10.6 <<>> @10.89.89.11 -p 53 heise.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28930
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;heise.de. IN A
;; ANSWER SECTION:
heise.de. 16376 IN A 193.99.144.80
;; Query time: 30 msec
;; SERVER: 10.89.89.11#53(10.89.89.11)
;; WHEN: Tue Aug 11 17:26:05 CEST 2020
;; MSG SIZE rcvd: 53
funktionieren also.
Was mir jedoch auffällt – auf Port 53530 klappt das so nicht …
dig @10.5.5.1 -p 53530 heise.de
; <<>> DiG 9.10.6 <<>> @10.5.5.1 -p 53530 heise.de
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Wobei das aber mal funktioniert hatte, soll heißen, die Domains die mit Hilfe der DNSBL Blocklisten blockiert werden, wurden eigentlich blockiert (und auch zusätzliche Sonderfunktionen wie z.B. "Enable Google SafeSearch", "Enable DuckDuckGo SafeSearch", "Enable Youtube Adult Restrictions" und "Enable Strict Bing Search" waren aktiv und konnten nicht umgangen werden).
Korrektur: Habe das gerade noch einmal getestet – also den Pi-hole aus gemacht – das "blocking" dank der DNSBL klappt. Nur die Abfrage per dig auf Port 53530 nicht, da das dann "intern" in der OPNsense gemacht wird.
D.h., außen fragt er natürlich nur auf DNS Port 53, intern gibt es dann noch die "custom option" im Unbound DNS per
forward-addr: 127.0.0.1@53530
(siehe auch mein Eingangs-Post, da habe ich dies ja schon erwähnt)
-
Ich glaube nach wie vor, der entscheidende Punkt ist bei den "Custom options" von Unbound DNS versteckt:
https://docs.opnsense.org/manual/how-tos/bind.html (https://docs.opnsense.org/manual/how-tos/bind.html)
Anbei auch noch einmal ein Screenshot, damit ihr besser versteht wovon ich rede (Unbound_DNS_Custom_Options.png).
Es gibt übrigens schon seit einigen OPNsense-Versionen folgenden Hinweis bei den "Custom options" von Unbound DNS: "This option will be removed in the future due to being insecure by nature. In the mean time only full administrators are allowed to change this setting".
Aktuell ist als "Listen IPs" bei mir in Services / BIND / Configuration noch die 127.0.0.1 eingetragen (was ja der localhost wäre, richtig?).
Wenn ich die Anmerkung (siehe Screenshot) richtig verstehe, soll ich unter "Listen IPs" in Services / BIND / Configuration statt der 127.0.0.1 meine "LAN IP" eintragen, das wäre in meinem Fall dann also die 10.5.5.1 meiner OPNsense?
Und in den "Custom options" unter Services / Unbound DNS / General sollte dann statt
do-not-query-localhost: no
forward-zone:
name: „.“
forward-addr: 127.0.0.1@53530
noch noch folgendes stehen:
forward-zone:
name: „.“
forward-addr: 10.5.5.1@53530
Sonst hätten meine "Host Overrides"-Einträge unter Services / Unbound DNS / Overrides keine Funktion?
Oder missverstehe ich das immer noch?
Danke für weitere Hilfe!
-
Habe das jetzt mal wie beschrieben angepasst (also statt der 127.0.0.1 nutze ich jetzt die 10.5.5.1 bei BIND).
Dann funktioniert DNS aber gar nicht mehr …
Deshalb habe ich das jetzt doch wieder auf 127.0.0.1 gestellt.
Also entweder missverstehe ich diese Hinweise völlig, oder aber das funktioniert so mit der aktuellen OPNsense 20.7 gar nicht mehr?
Wer kann helfen?
-
Versuchs mal mit TCP an Stelle von UDP
-
Versuchs mal mit TCP an Stelle von UDP
Hallo Rainer,
an welcher Stelle genau meinst Du?
Muss jetzt leider erst mal los und kann mir das erst abends ansehen …
Danke & beste Grüße,
Marcel
-
Du hast in Deinem Screenshot ipV4 und V6 auf udp stehen - DNS möchte gerne auf UDP und TCP hören - das könnte es sein
-
Das ändert leider nichts, auch wenn TCP/UDP auf Port 53 und 53530 erlaubt ist.
Es hätte mich ehrlich gesagt auch gewundert – denn grundsätzlich klappte DNS ja schon, wenn nur UDP auf Port 53 und 53530 erlaubt war.
-
Das ändert leider nichts, auch wenn TCP/UDP auf Port 53 und 53530 erlaubt ist.
Schade....
-
Aber ich lasse das trotzdem mal auf TCP/UDP stehen, denn dazu habe ich das hier gefunden:
https://www.infoblox.com/dns-security-resource-center/dns-security-faq/is-dns-tcp-or-udp-port-53/ (https://www.infoblox.com/dns-security-resource-center/dns-security-faq/is-dns-tcp-or-udp-port-53/)
War also grundsätzlich ein guter Hinweis.
Bin trotzdem mal gespannt, wie das Problem letztlich zu lösen ist. Die erfahreneren Leute aus diesem Forum sind glaube ich aktuell alle noch in ihrem wohlverdienten Ulraub. Es sei ihnen natürlich gegönnt. :)
-
Vorweg: Wie schon erwähnt, externe Adressen werden sowohl per Pi-hole als auch per OPNsense wie gewünscht aufgelöst, das ist nicht das Problem.
Wenn ich an einem Rechner in meinem Netzwerk den Pi-hole nach dem iMac (also einer internen Maschine) frage, bekomme ich folgende Antwort (das klappt also):
dig @10.89.89.11 -p 53 imac.localdomain
; <<>> DiG 9.10.6 <<>> @10.89.89.11 -p 53 imac.localdomain
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41291
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;imac.localdomain. IN A
;; ANSWER SECTION:
imac.localdomain. 2 IN A 10.5.5.199
;; Query time: 29 msec
;; SERVER: 10.89.89.11#53(10.89.89.11)
;; WHEN: Wed Aug 12 22:46:09 CEST 2020
;; MSG SIZE rcvd: 61
Und auch die Rückwärstauflösung klappt (da kommt die Antwort jedoch definitiv nur vom Pi-hole, nicht von der OPNsense):
host 10.5.5.199
199.5.5.10.in-addr.arpa domain name pointer imac.localdomain.
Wenn ich mich per SSH auf meiner OPNsense einlogge, kann ich auch dort den iMac erfolgreich abfragen:
dig @127.0.0.1 -p 53 imac.localdomain
; <<>> DiG 9.16.5 <<>> @127.0.0.1 -p 53 imac.localdomain
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58368
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;imac.localdomain. IN A
;; ANSWER SECTION:
imac.localdomain. 3600 IN A 10.5.5.199
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 12 22:46:48 CEST 2020
;; MSG SIZE rcvd: 61
Und auch direkt auf der OPNsense klappt die Rückwärtsauflösung:
host 10.5.5.199
199.5.5.10.in-addr.arpa domain name pointer imac.localdomain.
Was jedoch nach wie vor nicht klappt, ist die Abfrage von einem beliebigen Rechner im Netzwerk aus direkt auf der OPNsense:
dig @10.5.5.1 -p 53 imac.localdomain
; <<>> DiG 9.10.6 <<>> @10.5.5.1 -p 53 imac.localdomain
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42381
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;imac.localdomain. IN A
;; AUTHORITY SECTION:
. 9563 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020081202 1800 900 604800 86400
;; Query time: 31 msec
;; SERVER: 10.5.5.1#53(10.5.5.1)
;; WHEN: Wed Aug 12 22:57:44 CEST 2020
;; MSG SIZE rcvd: 120
:(
-
Ok, bin mittlerweile einen entscheidenden Schritt weiter … aber leider immer noch nicht am Ziel.
Aber immerhin – externe DNS-Auflösungen funktionieren jetzt auch mit dem Eintrag meiner LAN IP (statt der 127.0.0.1) unter Services / Unbound DNS / General / Custom options
forward-zone:
name: „.“
forward-addr: 10.5.5.1@53530
Entsprechende steht nun unter Services / BIND / Configuration / Listen IPs ebenfalls meine LAN IP (statt der 127.0.0.1)
10.5.5.1
Mein Fehler beim vorherigen Versuch war folgender: Ich hatte lediglich unter Firewall / Rules / Floating die Destination von 127.0.0.1 auf 10.5.5.1 für den Port 53530 angepasst.
Zusätzlich musste ich aber auch noch unter Firewall / NAT / Port Forward die Regel anpassen!
(siehe Screenshot Firewall-NAT-PortForwarding.png)
Das heißt also, die Notizen ganz am Ende dieser Dokumentation habe ich jetzt korrekt am laufen:
https://docs.opnsense.org/manual/how-tos/bind.html (https://docs.opnsense.org/manual/how-tos/bind.html)
Und eigentlich sollten mit genau dieser Einstellung dann ja auch die Unbound DNS Overrides funktionieren, richtig?
Leider werden lokale Host-Namen bei mir aber immer noch nicht aufgelöst (da ist der Stand also immer noch wie zuvor beschrieben). :-[
Woran liegt das? Danke für Ideen und Vorschläge!