OPNsense Forum
International Forums => German - Deutsch => Topic started by: ole on July 04, 2020, 10:46:03 am
-
Hallo OPNsense Freunde,
aktuell versuche ich für mein Gäste WLAN den DSNMasq Forwarder per NAT auf das Interface los zu lassen - und bin gescheitert :(
Unter Services/Dnsmasq habe ich diesen enabled und den Port auf 5335 mit strict Binding gesetzt, da ich Unbound für die anderen Interfaces verwende. Für den 5335 ein Alias eingerichtet und NAT Regeln erzeugt, die NAT Rule als ersten Match plaziert. Dennoch zeigt mir das Log, dass die Clients auf Port 53 zugreifen und entsprechend abgewiesen werden. Wie bekomme ich das hin? IMO habe ich mich an die OPNsense Doku gehalten ...
-
moin, warum sollen deine gäste nicht auch den unbound dns nutzen, was ist genau dein ziel und welche doku beschreibt das du es so machen sollst (bitte mal einen link).
ich habe auch ein gäste lan/wlan und alle nutzen den unbound dns.
-
moin, warum sollen deine gäste nicht auch den unbound dns nutzen, was ist genau dein ziel und welche doku beschreibt das du es so machen sollst (bitte mal einen link).
ich habe auch ein gäste lan/wlan und alle nutzen den unbound dns.
Quelle: https://forum.opnsense.org/index.php?topic=9245.0
und teilweise: https://nguvu.org/pfsense/pfsense-baseline-setup/
Der Sinn ist, dass keiner die interne Namensauflösung verwenden kann. Das gleiche Konzept möchte ich auch für das DMZ verwenden. Das WLAN für vertrauenswürdige Gäste bekommen natürlich unbound Port 53 verpasst :) Weiterhin habe ich am Unbound eine BlackList (unbound+)
-
also wenn du deine firewall regeln so erstellst das keiner auf dein lan vom gäste lan kommt, ist es doch kein problem die ip/dns zu kennen. ich persönlich sehe da kein problem (in meinem netzwerk)
-
So, ich habs:
Destination / Invert: *NOT* Checked
so recht verstehe ich es nicht. Im original HauZu wurde ja so verhindert, das localhost rekursiv auf #53 weiter ge-NAT wird (so habe ich es zumindest verstanden), aber hier gilt plötzlich ein anderen Konzept?
-
Ich weiß nicht auf welches Howto du dich damit beziehst, aber du brauchst generell eigentlich gar keine NAT Regel für 53, sondern nur dann, wenn du bspw. ausgehend alles DNS umleiten willst auf die Sense damit diese bspw. irgendwas blocken oder anders beantworten kann oder um DNS Leaks zu verhindern wenn Software direkt mit bspw. google.dns reden möchte. Da du das meinem Verständnis nach gerade für WiFi nicht willst, sondern genau alles rausschicken und eben nichts lokal beantworten möchtest, braucht es da auch keine NAT Regel. Alles was es braucht (um sicher zu stellen, dass keiner den internen DNS nutzt) ist ein Block auf udp/tcp 53/853 auf "This Firewall" (da dies jegliche Adressen der Firewall einschließt) und ein Allow udp/tcp 53 auf die DNSe die per DHCP gepusht werden :)
-
ich beziehe mich auf [HOWTO - Redirect all DNS Requests to Opnsense](https://forum.opnsense.org/index.php?topic=9245.0). Meine Idee ist, dnsmasq als DNS cache (1ms vs. ~20ms) einzusetzen und entsprechend alle DNS Abfragen auf diesem umzuleiten.
Evtl. werde ich zB. im LAN für mich neben unbound+#53 auch dnsmasq#5335 nehmen, da manche Webseiten einfach diesen blöden Werbekram benötigen (zB. https://mydealz.de)
-
OK das verstehe ich nun aber nicht. Da kollidieren doch zwei Sachen miteinander. Einerseits willst du das Gäste WLAN disjunkt haben und völlig getrennt vom LAN, auch deinen DNS schützen - ob sinnvoll oder nicht. Andererseits hältst du dich an ein Howto was das genaue Gegenteil macht und fragst dich dann, warum die Regeln dann nicht gebraucht werden oder nicht genutzt werden bzw. nicht funktionieren ;) Widerspricht sich schon, oder?
> Evtl. werde ich zB. im LAN für mich neben unbound+#53 auch dnsmasq#5335 nehmen, da manche Webseiten einfach diesen blöden Werbekram benötigen (zB. https://mydealz.de)
Und was nützt dir dafür ein zweiter DNS Service obendrauf der lediglich forwarding macht - was unbound auch kann?
-
OK das verstehe ich nun aber nicht. Da kollidieren doch zwei Sachen miteinander. Einerseits willst du das Gäste WLAN disjunkt haben und völlig getrennt vom LAN, auch deinen DNS schützen - ob sinnvoll oder nicht. Andererseits hältst du dich an ein Howto was das genaue Gegenteil macht und fragst dich dann, warum die Regeln dann nicht gebraucht werden oder nicht genutzt werden bzw. nicht funktionieren ;) Widerspricht sich schon, oder?
Irgendwie raff ich es wohl nicht. Im besagten HowTo wird im LAN und Wireless Netzwerk alles auf unbound#53 gezwungen, dass bei mir auch so funktioniert, wie ich bisher in den logs so gesehen habe. Nun soll aber das Gäste-WLAN einen eigenen DNS bekommen; unfiltered, ohne die Blacklist aus dem LAN und ohne Namensauflösung des internen Netzwerkes. Letzteres mag evtl. sinnfrei sein, da die FW Regeln den Zugang eh unterdrücken würden (was Du wohl mit sinnvoll oder auch nicht umschrieben hast). Aber in einigen Web quellen wird (ohne zu begründen) darauf verwiesen, das interne LAN nicht unfreiwillig über den DNS offen zu legen, was IMO zB. auf das DMZ zielt. Ich bin da zu wenig Hacker ....
-
> Im besagten HowTo wird im LAN und Wireless Netzwerk alles auf unbound#53 gezwungen, dass bei mir auch so funktioniert, wie ich bisher in den logs so gesehen habe.
OK. Macht Sinn/kann Sinn machen, wenn man DNS zentral nur über sein Gerät rausgeben will und ggf. filtert und daher nicht möchte, dass irgendwas dran vorbei DNS macht. Check :)
> Nun soll aber das Gäste-WLAN einen eigenen DNS bekommen; unfiltered
Okay
> Letzteres mag evtl. sinnfrei sein, da die FW Regeln den Zugang eh unterdrücken würden (was Du wohl mit sinnvoll oder auch nicht umschrieben hast).
Jup, habe ich so salopp und frech umschrieben ;) Ja macht für mich nicht so viel Sinn, da der Gast bei dir ist und es dann nur logisch ist, dass man dann ggf. auch interne Namen hat und auflösen kann. Wer die aber nicht kennt, würde kaum danach suchen/drauf kommen und selbst wenn wäre der Zugriff geblockt. Somit halte ich den Privacy/Informationsgewinn/-schutz für gering, dafür aber den Gewinn an Bandbreite/Sicherheit höher, wenn ich das Gäste WLAN über einen gefilterten DNS schicke, der ggf. Ads blockt oder Malware Domains ausfiltert etc. Daher meine Rand-Bemerkung.
> Aber in einigen Web quellen wird (ohne zu begründen) darauf verwiesen, das interne LAN nicht unfreiwillig über den DNS offen zu legen, was IMO zB. auf das DMZ zielt.
Ich kenne die Quellen nicht, daher kann ich schlecht die Intention einschätzen oder was dazu sagen. Es kann durchaus Hintergrund haben. In den meisten Fällen zielt es aber eher darauf ab, dass man extern keine internen Services propagiert um keine Struktur oder Dienste zu entblößen. Gilt ggf. auch in einem größeren WiFi Netz. Für zu Hause zwischen LAN, WLAN und Gäste-WLAN halte ich da den Gewinn von oben für höher als eine theoretische Gefahr von meinem Gast.
Aber ich persönlich habe deshalb auch zwei Raspis mit PiHole laufen. Nicht weil die Sense nicht auch IP und DNS Blocking machen könnte, sondern weil das PiHole Package einfach eine komplette und runde Sache ist und die Oberfläche auch meine Frau oder meine Große bedienen können um mal was auf die Block oder Permit Liste zu setzen. Und meine Geräte sowie Gäste freuen sich immer wenn sie bei mir surfen und werden nicht mit Werbung zugeworfen :)
Grüße
-
vielen Dank für die ausführliche Antwort. Inzwischen habe ich mit der Blacklist von unbound+ auch so meine Erfahrung gesammelt. Mit der WindowsSpyBlocker List konnte ich mich zB. nicht einmal mehr bei M$ live.com einloggen bzw. (andere Listen) bei mydealz.de keinen affiliate link zum Objekt der Begierde öffnen (spart Geld ...). Effektiv sind nur die Malware, Ransomware, NoCoin und easyList übrig geblieben, den Rest muss uBlock & Co. machen. Urspünglich war die Idee, den Gästen ein "ursprüngliches", aber komfortables (DNS Cache, ggf. Squid) WLAN zur Verfügung zu stellen und die gleichen Konzepte auch für den IOT Dreck zu verwenden, der auch bei mir so langsam um sich greift ....
PiHole soll bei mir später im Docker laufen (wäre hier in Verbindung mit OPNsense OT), auf dessen Host auch dockerized NextCloud läuft. Hier sind wir bei einem der Dienste, die ich auch für die Familie WAN-wide "anbieten" will. U.U. "muss" ich auch die pubertierenden Freunde von meinen Kids diesen Service anbieten (legale use wäre Group-Homework als CoviD-19 Bespaßung seitens der Schule aus, abuse use anschließend mit "Hack den Alten - der darf mich nicht schlagen").
-
> . Mit der WindowsSpyBlocker List konnte ich mich zB. nicht einmal mehr bei M$ live.com einloggen bzw. (andere Listen) bei mydealz.de keinen affiliate link zum Objekt der Begierde öffnen (spart Geld ...).
Sicher, wenn man die Listen eben alle nur mit der groben Kelle zusammenkippt passiert das ;) Da muss man dann eben selbst entscheiden was man doch braucht oder nicht und ggf. doch durchlässt. Muss man dann eben auf eine access Liste packen. Macht man ja auch bei PiHole ständig.
Und warum irgendwelche Affiliate Links nicht funktionieren - zum Teil sind da einfach auch nur Mistdienste dazwischengeschaltet. Da bin ich nicht böse, dass die nicht gehen. Der Jüngste hier meckert dann auch mal wenn er nen Minecraft Mod oder Map nicht laden kann weil adfly und der Schmutz geblockt wird - kommt man dann aber auch drumherum und muss andere Mirrors nehmen oder kreativer werden. Besser als schon wieder den x-ten komischen Huckepack Installer oder DriveByAd Download abzubekommen. Die nerven mehr als das bisschen Einschränkung.
Da stimmt eben doch "wenn man nichts zahlt, zahlt man mit den eigenen Daten (oder Nerven)" :)
-
Weiß jemand, wie man eine PHP-Funktion schreibt, mit der Sie den ausgewählten Link umleiten können?. (https://rabatt-guru.de)