(gelöst) DNS-Auflösung im LAN

[BenutzerGa4gooPh]

Bevor ich weiter mache
Das Netz 192.168.1.0/24 muss im Objekt "loc" enthalten sein.
Diese Überlegung begleitet mich von Anfang an. Aber ich sehe unter /etc/shorewall nichts, wodurch ich feststellen könnte, welcher IP-Bereich denn nun tatsächlich von "loc" abgedeckt wird.

Habe nachgeschaut: Die Zonen werden über Interfaces/Ports definiert (/etc/shorewall/interfaces), nicht über IP-Netze. Mit VLANs wirst du nicht arbeiten. Demzufolge beinhaltet "loc" alles am von dir definierten Port. Rules können sich um IPs kümmern, müssen aber nicht (IP=ANY).
http://shorewall.org/manpages/shorewall-interfaces.html
Also sollten die von mir vorgeschlagenen Regeln funktionieren - so denen nicht andere Regeln "im Wege" stehen.

Deine Routen stimmen. Hinweis zur künftigen Adressvergabe: Routern gibt man zur besseren Übersicht die x.x.x.1 und dem Nachbarn im gleichen Netz die x.x.x.254 - so man /24er Netze als Transfernetz nimmt. Daran dann angeschlossen Bereich für Server und Netzkomponenten (Switches) mit festen IPs. Also Bereich von .5 bis .50 oder/und .200 bis .250 reserviert. Von .101 bis .199 DHCP-Clients. Hat man immer Platz für Unvorhergesehenes.
Muss man aber nicht genauso machen.

Der hintere Router am 1er Netz müsste eigentlich schon immer NAT durchführen, sonst hätten dessen Clients keinen Internetzugang. (Dein alter Speedport hatte mit Sicherheit keine Rückroute darauf, in den Archer hast du keine eingetragen, das wüsstest du noch. In der etc/network/interfaces des hinteren Routers müssten entsprechende Einträge fuer NAT sein. Oder du schaust einfach mal auf dem letzten Router:

Code: Alles auswählen

iptables -L -t nat

Vgl. a. https://wiki.debian.org/DebianFirewall zu den NAT-Eintragungen in etc/network/interfaces.

[guennid]

Problem gelöst (hoffe ich):
Statt uns auf den Shorewall zu fixieren, hätten wir besser den "hinteren" Router unter die Lupe genommen (dessen /etc/network/interfaces hatte ich zwar schon mal gepostet, aber an der lag's nicht). Ausgehend von MSfrees Hinweis, ob der überhaupt NAT macht, habe ich mich dann mal auf den konzentriert und das Modul ip_tables in den Kern kompiliert und versucht, die Maschine damit zu konfigurieren. Das war wohl auch eine Sackgasse. Aber:
Sämtliche hosts im lan waren auf diesem Router, der das Netz 192.168.1.0/24 mit dem 192.168.100./24 (besser so? ) verbindet, in /etc/hosts gelistet und in der /etc/resolv.conf war die interne IP des shorewall eingetragen. Das genügte aber nicht. Nachdem ich jetzt auch auf diesem Router dnsmasq nachinstalliert habe und den clients in 192.168.1.0/24 in ihrer /etc/resolv.conf die interne IP dieses Routers als nameserver eingetragen habe, funktioniert jetzt die Namensauflösung (mit Kern ohne ip_tables getestet) wie gewünscht.

So Jana und MSfree, jetzt dürft ihr mich hauen, aber auch nachdem ich den kompletten Thread heute morgen noch mal durchgegangen bin, habe ich keine Rückfragen gefunden, die mich in diese Richtung geschubst hätten. Das ist bitte absolut nicht als Kritik zu verstehen, sondern nur als Entschuldigung meinerseits, warum ich auf diese Idee nicht schon früher gekommen bin. Dazu unten mehr.

Die Ausgangsfrage war ja, ob das Procedere, die Namensauflösung ausschließlich über die shorewall zu regeln, mein Netz etwas sicherer machen könnte. Gehe ich recht in der Annahme, dass da jetzt noch das entscheidende Bauteilchen fehlt: Statt die DNS-Anfragen in der shorewall einfach auf den Plastikrouter weiterzuleiten, sollte ich dort und nur dort, einen "echten" Nameserver angeben, z.B. den von Jana verlinkten des CCC?

Nichtsdestotrotz: Vielen Dank für deine Mühe, Jana! Ich denke, ich habe trotz der "Irrfahrten" einiges dazugelernt. Und werde mit dem neuen Wissen auch noch einiges rumexperimentieren

Was meine (etwas? ) chaotische IP-Zahlenvergabe betrifft: auch das hat historische Gründe. So ist das eben, wenn ein Nichtexperte, expertenmäßig loslegt ("Experten [...] fangen einfach an." ,O-Ton Jana ). Ich werde das, wenn ich Zeit finde, mal nach Janas Hinweisen etwas übersichtlicher sortieren.

Nebenbei:
Die im deutschsprachigen Internet zu findenden Informationen über dnsmasq haben mich meistens eher verwirrt als weitergebracht. Mit DNS hält man sich da meist nicht lange auf, sondern beschreibt ausführlich seine DHCP-Server-Funktionalität. . Am besten klar gemacht, dass das Teil die Bezeichnung DNS-Server nur bedingt verdient, hat mir das hier:

Für die DNS-Funktionalität wird auf die Dateien /etc/hosts und /etc/resolv.conf zurückgegriffen, die keinerlei Dnsmasq-spezifischer Anpassung bedürfen, und weiterhin standardkonform verwendet werden können. Dieses Verhalten kann allerdings angepasst werden. Die DHCP-Funktionalität wird in der Konfigurationsdatei von Dnsmasq angepasst.

(1). Das kann man zwar so ähnlich auch sonstwo lesen, z.B. hier (2), aber erst das Arch-Wiki brachte mich auf den Trichter, dass, nutzt ein Laie wie ich nur die DNS-Funktionalität, er vergeblich nach einer Fehlkonfiguration in der dnsmasq-config sucht, wenn die Namensauflösung nicht klappt.

(1) https://wiki.archlinux.de/title/Dnsmasq
(2) https://wiki.ubuntuusers.de/Dnsmasq/

Grüße, Günther

[BenutzerGa4gooPh]

Nachdem ich jetzt auch auf diesem Router dnsmasq nachinstalliert habe und den clients in 192.168.1.0/24 in ihrer /etc/resolv.conf die interne IP dieses Routers als nameserver eingetragen habe, funktioniert jetzt die Namensauflösung (mit Kern ohne ip_tables getestet) wie gewünscht.

Da fragt man sich nun, warum das vor der neuen Shorewall-Regel geklappt hat ... deshalb nur indirekt bezüglich DHCP und deinen Änderungen in Clients im 1er Netz in Betracht gezogen.

Ich kann mir jetzt nur vorstellen:
Der Router am 1er Netz selbst kümmert sich natürlich nicht um die Einträge in Clients (resolv.conf), gibt vmtl. als DHCP-Server den Clients sich selbst als DNS-Server (Forwarder) vor und fragt dazu einen externen DNS an, wird deshalb von Shorewall-Regel geblockt. Weiß nicht genau, was bei Widersprüchen DHCP-Clients tun.
Diesem Router demzufolge explizit seinen Gateway (Shorewall-LAN-Interface) als anzufragenden "öffentlichen" DNS-Server verklickern!

In die /etc/resolv.conf spielt vieles rein, auch DHCP, deshalb "heiße Kiste": https://wiki.debian.org/NetworkConfigur ... ameservers
Hoch interessant übrigens!

Die Ausgangsfrage war ja, ob das Procedere, die Namensauflösung ausschließlich über die shorewall zu regeln, mein Netz etwas sicherer machen könnte.

Bei DNS-kompromittierten Clients erzwingen nach wie vor entsprechende Shorewall-Rules den entsprechenden Server - oder verhindern einen falschen. Wie besprochen und Threadziel.

Gehe ich recht in der Annahme, dass da jetzt noch das entscheidende Bauteilchen fehlt: Statt die DNS-Anfragen in der shorewall einfach auf den Plastikrouter weiterzuleiten, sollte ich dort und nur dort, einen "echten" Nameserver angeben, z.B. den von Jana verlinkten des CCC?

.
4 sinnvolle Schritte:
1. Du machst erst mal die Shorewall-Rule fertig - ohne was zu ändern (Threadziel)!!!
2. Den DNS-Forwarder auf dem Plastikrouter benötigst du für dessen WLAN-Clients sowieso. Eine Umleitung auf Shorewall ist nahezu unmöglich, müsste per LAN-Anschluss des Plastikrouters erfolgen, und ich bezweifele, dass das dessen Firmware das mitmacht. Auf dem Plastikrouter könnte man also einen öffentlichen einstellen, der per Internet abgefragt wird und zu dem man als Aluhut Vertrauen hat. CCC = auch viele Aluhuete. Im positivem Sinne gemeint.
3. Da man nicht an x Stellen das Gleiche konfigurieren sollte (Übersicht!), würde ich den Plastikrouter der Shorewall als DNS "verklickern". Dem 1er Router Shorewall-DNS. Ohne Plastikrouter kommt eh kein Client ins Internet und die Shorewall kann die interne Namensauflösung für deine Hosts trotzdem tun mit dnsmasq.
4. Optional und m. E. Ideallösung für Aluhuete: Du deinstallierst nur auf dem Shorewall-Geraet dnsmasq einschl. Konfigs (purgen) und installierst und konfigurierst dafür unbound. Das ist ein rekursiver Resolver und fragt nur authoritative DNS-Server an. Zu denen muss man Vertrauen haben.
https://de.m.wikipedia.org/wiki/Domain_Name_System
https://blog.opendns.com/2014/07/16/dif ... meservers/
Also zusammengefasst: Erst Schritte 1 - 3, dann unbound in VM testen und evtl. neuer Thread vor "Produktiveinsatz" von unbound.

dnsmasq kann man auch so beschreiben: Der holt sein Wissen vom Vordermann, nicht vom Lehrer (authoritativer Server), speichert (cacht) und sagt sein Wissen allen Hintermännern (LAN) weiter. Erst auf Nachfrage eines Hintermannes fragt der faule Sack erst den Vordermann! Wenn der nächste Hintermann das Gleiche fragt, nutzt der clevere Sack sein Gedächtnis.

Was meine (etwas? ) chaotische IP-Zahlenvergabe betrifft: auch das hat historische Gründe. So ist das eben, wenn ein Nichtexperte ...

Macht doch nichts, bei mir kommt die ehem. Planerin manchmal durch.

[guennid]

Da fragt man sich nun, warum das vor der neuen Shorewall-Regel geklappt hat ...

Hat's ja nicht:

Ich habe bisher zwei Kauf-Router kennengelernt. Beide fungierten mit ihrer internen IP als DNS-Server

DHCP mache ich übrigens auch (noch) nicht, bzw. für den Tolino hatte ich da auf der Shorwall einen kleinen Bereich freigeschaufelt, aber da Adobe ( ) den Shorewall eh nicht mag, blieb mir gar nichts anderes übrig, als das auf dem Plastik-Router zu machen. Aber da wird WLAN/DHCP nur bei Bedarf eingesschaltet, konkret immer dann, wenn meine Frau (oder ich) ein E-Buch aus der Marburger Stadtbücherei ausleihen wollen.

Meine Idee, den CCC-DNS-Server auf der Shorewall einzutragen, funktioniert übrigens nicht. Das müsste ich schon auf dem Plastik-Router tun, denn an dem komme ich offensichtlich nicht vorbei - richtig?

[guennid]

1-3 deines letzten Post sind erledigt.

Tipp zum Posten: Es ist häufig dann nicht sinnvoll, den eigenen letzten Post nochmal zu ändern, wenn schon weitergepostet wurde, das führt mitunter zu Missverständnissen.

Nichtsdestotrotz, alles ok und (wahrscheinlich ) verstanden.

Da ich beruflich keine VM mehr brauche, wollte ich mir sowas eigentlich nicht mehr antun. Mal sehen, wenn ich viel Zeit habe (Rentner haben die eigentlich nie ) versuche ich 4. mal direkt.

[BenutzerGa4gooPh]

1-3 deines letzten Post sind erledigt.

Welche Regeln funktionieren, welche nutzt du?

Tipp zum Posten: Es ist häufig dann nicht sinnvoll, den eigenen letzten Post nochmal zu ändern, wenn schon weitergepostet wurde, das führt mitunter zu Missverständnissen.

Deshalb schrieb ich bis zur Fertigstellung "Editiere noch ..." ganz unten. Mittlerweile "wegeditiert"

[guennid]

Jana, soweit ich nach dem Hin und Her noch durchblicke, ist die einzige relevante Änderung, die ich gegenüber dem status qou ante letztlich vorgenommen habe: Installation von dnsmasq auf dem "hinteren" "Router". OK, die /etc/hosts habe ich mich während unserer Diskussion bemüht, aussschließlich auf der Shorewall zu pflegen und anschließend an meine sämtlichen Rechner zu verteilen. Was ich da alles zwischenzeitlich geändert habe, kriege ich nicht mehr zweifelsfrei auf die Reihe. Eines glaube ich sagen zu können: Die Shorewall-Konfiguration ist nach einigem Hin und Her die gleiche wie vor meinem 1. Post, also was DNS betrifft, steht da nach wie vor nur drin:

Code: Alles auswählen

DNS(ACCEPT)     loc             $FW
DNS(ACCEPT)     $FW             net

Mittlerweile glaube ich, dass diese beiden Zeilen schon ein

Code: Alles auswählen

DNS(REJECT)    loc             net

verhindern.

Und nochmal: ohne deine intensive Beteiligung und die Tipps von MSfree hätte ich das Ganze wohl ungelöst aufgegeben.

Grüße, Günther

[BenutzerGa4gooPh]

Meine Idee, den CCC-DNS-Server auf der Shorewall einzutragen, funktioniert übrigens nicht. Das müsste ich schon auf dem Plastik-Router tun, denn an dem komme ich offensichtlich nicht vorbei - richtig?

Müsste eigentlich auch funktionieren, sollte mich wundern, wenn der Plastikrouter ausgerechnet DNS-Anfragen blockt.
http://shorewall.org/shorewall_logging.html !!!
Sollte auch das Andere klären.

Über den Dank habe ich mich sehr gefreut.

[guennid]

Habe zwischenzeitlich oben nochmal ein zusätzliches Dankeschön formuliert!

[BenutzerGa4gooPh]

Code: Alles auswählen

DNS(ACCEPT)     loc             $FW
DNS(ACCEPT)     $FW           net
DNS(REJECT)      loc              net

Ein Paket wird im Allgemeinen (Standard vieler Firewalls und Paketfilter) gegen Regeln von oben nach unten geprüft, und bei erster Übereinstimmung der Bedingung (Matching) wird ACCEPT, Reject, Block/Drop ausgeführt. Widersprüche werden so ganz einfach gelöst - nicht immer im Sinne des Administrators. Reihenfolge ist demzufolge wichtig - und änderbar.

$FW ist sicher die Firewall selbst, local Host, 127.0.0.1. (Könnte man in meinen obigen Vorschlägen nutzen/testen.)

Mit diesem Wissen kannste jetzt knobeln ... oder noch besser Doku lesen ... ich verrate heute nichts mehr!
(Es bleibt ja auch die Frage offen, was passiert, wenn nichts passt. Meist (Shorewall auch?) wird geblockt oder vorher noch woanders nachgeschaut.)