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

[BenutzerGa4gooPh]

Die interne IP des Archer ist doch "aktiv"? Oder versteh' ich wieder was nicht?

Nein, alles verstanden. Der Archer ist ein Weiterleitungsserver, akiv und "ungewollt", Anfragen von Shorewall offenbar zurückgewiesen.

Fragen zum anderen Problem:
Auf dem internen Shorewall-Router läuft welcher DNS-Server (Programm/Paketname)?
Welche öffentlichen DNS-Server fragt dieser interne DNS-Server an?
Warum nicht einfach dem Archer-DNS den/die gleichen öffentlichen Server "verklingeln", die auch der interne "Shorewall-Router-DNS anfragt? Kleine Access-Liste (analog Shorewall) auf dem Archer für eventuell fehlkonfigurierte/kompromittierte Clients dazu.

[guennid]

Auf dem internen Shorewall-Router läuft welcher DNS-Server (Programm/Paketname)?

Ich dachte, gar keiner, der Router leitet weiter an den Plastikrouter? Schon lange her, als ich den Router eingerichtet habe.

Welche öffentlichen DNS-Server fragt dieser interne DNS-Server an?

Wenn ich das im Plastikrouter richtig deute, dann die IP 217.0.43.113. Im shorewall ist aber nur die interne IP des Plastikrouters eingetragen.

[BenutzerGa4gooPh]

Ich dachte, gar keiner, der Router leitet weiter an den Plastikrouter?

Kann durchaus sein, aber irgendein Paket/Modul macht das, wahrscheinlich dnsmasq oder die resolv.conf.

Wenn ich das im Plastikrouter richtig deute, dann die IP 217.0.43.113. Im shorewall ist aber nur die interne IP des Plastikrouters eingetragen.

IP Address: 217.0.43.113
Host of this IP: f-nxr-a01.isp.t-ipnet.de
Organization: Deutsche Telekom AG

Also fragen deine beiden Weiterleitungsserver einunddenselben öffentlichen DNS der Telekom ab. Der Shorewall-Router-DNS über den Umweg Archer.

Was spricht nun gegen:

Warum nicht einfach dem Archer-DNS den/die gleichen öffentlichen Server "verklingeln", die auch der interne "Shorewall-Router-DNS anfragt? Kleine Access-Liste (analog Shorewall) auf dem Archer für eventuell fehlkonfigurierte/kompromittierte Clients dazu.

Der erste Satz ist bereits Realität.

Falls dir der Telekom-DNS nicht passt, ich hatte oben was vom CCC verlinkt, ich kenne doch meine Aluhuete. Musst nur den Eintrag (IP des öffentlichen DNS) im Archer ändern.

[guennid]

Falls dir der Telekom-DNS nicht passt, ich hatte oben was vom CCC verlinkt, ich kenne doch meine Aluhuete.

Ja, ja, ja, habe ich mir schon angeguckt - aber das ist nachrangig. Erstmal geht's darum, dass alle Maschinen im Heimnetz überhaupt einen kriegen und zwar möglichst, ohne den Shorewall zu umgehen. Im Shorewall-Netz (192.168.100.0) funktioniert das ja auch, aber nocht nicht im nachgelagerten 192.168.1.0.

dnsmasq wird benutzt.

[BenutzerGa4gooPh]

Hatte ich wahrscheinlich falsch verstanden. Mein letzter Vorschlag bezog sich auf das WLAN des Archers, wo du m. E. den Tolino betreibst.

Das "nachgelagerte" 192.168.1.0 ist das interne Netz des Shorewall-Routers, direkt an dem angeschlossen? 192.168.100.0 das externe "Transfernetz" zwischen Archer und Shorewall?

[guennid]

Also, der Archer ist im Netz 192.168.3.0 (und auch nur der)
Der Shorewall ist im Netz 192.168.100.0 (mitsamt einigen Clients)
und dann gibt's noch das Netz 192.68.1.0 (mitsamt einigen clients und einem weiteren Router (192.168.1.110/192.168.100.110), der deren Anfagen ins Netz 192.168.100.0 und darüber hinaus an den Archer und damit ins Internet weiterleitet.

Für die Nichtinsider: Archer=Plastikrouter

Nachdem das mit der shorewall-config für das 100er Netz geklärt war, hätte ich hier aufhören und einen neuen Thread aufmachen sollen. Aber die Freude darüber war zu groß, ich konnte der Versuchung, weiterzumachen nicht widerstehen.
Wahrscheinlich werde ich gleich gesteinigt!

Also das wlan des Archer/Tolino können wir, denke ich, wirklich hier draußen lassen.

[BenutzerGa4gooPh]

Wahrscheinlich werde ich gleich gesteinigt!

Ja. Wegen schlechter Erläuterungen.
Mach doch einfach einen Netzplan, hier eine Vorlage zum Kopieren/Anpassen:

WAN (Internet/DSL)
|
Archer mit NAT ---- WLAN ---- Netz 1 ---- WLAN-Clients 1
|
Netz 2 --- Hosts 2 (evtl. WLAN-Clients in diesem Netz, Netz 1 fehlt )
|
Shorewall
|
Netz 3 --- Hosts 3
|
noch ein Router?
|
Netz 4
|
Hosts 4

Wenn du über IPs reden willst, Netze x mit IPs korrigieren/erweitern. Ansonsten können wir gerne auch nur von Netz x / Host x reden - mit gleicher Grundlage.
Die funktionierende Shorewall-Regel für DNS-Anfragen wurde für Netz 3 (entsprechendes Interface) erstellt? Jedenfalls hatte ICH das so gemeint.

[guennid]

Ich muss mich erst sortieren, morgen mehr.

[guennid]

Netzplan

[MSfree]

Netzplan

So, wie du es aufgezeichnet hast, müßte sich DNS von dem einen Nameserver auf der Shorewall bewerkstelligen lassen.

Gibt es einen besonderen Grund, warum du das 192.168.1.00/24-Netz nochmal vom Rest separiert hast?

[guennid]

So, wie du es aufgezeichnet hast, müßte sich DNS von dem einen Nameserver auf der Shorewall bewerkstelligen lassen.

Meine ich ja auch, tut aber z.Z. nicht. Bitte um Nennung möglicher Fehlerquellen.

Gibt es einen besonderen Grund, warum du das 192.168.1.00/24-Netz nochmal vom Rest separiert hast?

Jain. Histroischer Grund. Aus baulichen Gründen will ich kein Netzwerkkabel zu dem 1/100er Router legen [1]. Die dort angeschlossenen Clients verfügen nicht über wlan. Der Versuch, die Verbindung über Stromnetzadapter zu realisieren, scheiterte an dem 101er Clienten im 100er Netz, der auch im ausgeschalteten Zustand - also wenn er lediglich durch seine Steckerverbindung Kontakt zum Stromnetz hatte - das lan erheblich störte. Mittlerweile ist der Störenfried durch eine neuere Maschine ersetzt, aber ich sah bisher keine Notwendigkeit, das mit den Stromnetzadaptern erneut zu probieren. Obwohl - wenn ich das jetzt nach Jahren neu überdenke - bin ich mir gar nicht mehr sicher, ob die Existenz des Störenfriedes die Kreation des 1er Netzes tatsächlich nötig machte. Dann müssten aber die beiden NICs im jetzigen 1/100er Router beide eine 100er IP bekommen? Könnten wir diese Frage einstweilen zurückstellen. Ich fürchte da ein neues Fass aufzumachen ohne das erste Problem zu lösen.

Ich bitte um Entschuldigung für meine unfachmännische IP/Netz-Bezeichnerei, aber bei den fachmännischen Bezeichnungsmodalitäten blicke ich nicht wirklich durch. Ich habe gestern noch versucht, mich da etwas schlauer zu machen, aber alles, was ich gefunden habe, war nicht das, von dem ich vermute, dass ich es wissen sollte.

[1] Switch hinter dem 1/100er Router legen, womit diese Maschine dann keine Routing-Funktionen mehr übernehmen müsste

[MSfree]

Histroischer Grund. Aus baulichen Gründen will ich kein Netzwerkkabel zu dem 1/100er Router legen [1].

Das hatte ich mir schon fast gedacht, begründet aber nicht, daß du hinter dem Router ein separates Subnetz aufziehst.

OK, ich kenne deinen Router nicht, aber hier liegt eigentlich nur ein Konfigurationsfehler vor. Wenn du den Router als WLAN-Bridge konfigurieren könntest, hättest du am Switch hinter dem Router das gleiche Subnetz (also IP-Adressbereich) wie hinter der Shorewall. Was deine DNS-Probleme praktisch mit einem Schlag lösen würde.

Statt eines Routers könntest du auch einen Raspi nehmen, den du WLAN-seitig als Client ans Netz hängst und dann das LAN-Interface mit dem WLAN des Raspis bridged. Dadurch fungiert der Raspi dann wie ein Ethernetswitch, nur daß an einem Ende kein Kabel sondern eine Funkstrecke liegt.

[guennid]

OK, ich kenne deinen Router nicht, aber hier liegt eigentlich nur ein Konfigurationsfehler vor. Wenn du den Router als WLAN-Bridge konfigurieren könntest[...]

Ob wir das neue Fass aufmachen sollen?
Der Router ist ein einfacher alter laptop (TP X31).
Bei den Ubuntus leses ich

Intel Centrino (ipw2200) funktioniert leider definitiv nicht.

Ic habe ipw2100.

[MSfree]

Ob wir das neue Fass aufmachen sollen?

Naja, die Bridge-Konfiguration bei einem Linuxrechner ist wirklich denkbar einfach:
In der Datei /etc/network/interfaces ist nur folgendes einzutragen:

Code: Alles auswählen

auto lo
iface lo inet loopback

iface eth0 inet manual
iface wlan0 inet manual

auto br0
iface br0 inet dhcp
  bridge_ports eth0 wlan0

Statt DHCP kann man da natürlich auch statische IPs verwenden.

Bei den Ubuntus lese ich Intel Centrino (ipw2200) funktioniert leider definitiv nicht.

Mir ist leider nicht bekannt, ob die Möglichkeit, WLAN mit LAN zu bridgen, von der WLAN-Hardware abhängt. Bei mir läuft so etwas als Gäste-AP auf einem Raspi mit dem dafür typischen Edimax-WLAN-Stick.

[guennid]

Ich hatte es zwischenzeitlich schonmal anhand ubuntu-wiki (1) probiert. hat aber nicht funktioniert. Bei dir sieht das sehr anders aus.

Ist das komplett??

Was ist mit den Angaben für wpa-supplicant? Ich habe noch nie eine händisch gestrickte supplicant.conf benutzt.

(1) https://wiki.ubuntuusers.de/Netzwerkbr%C3%BCcke/

[MSfree]

Bei dir sieht das sehr anders aus.

Bei mir läuft das auch in der anderen Richtung ab. Bei mir sollen WLAN-CLients ans LAN gebracht werden, bei dir sollen LAN-Clients über eine WLAN-Luftbrücke ans Restnetz angeschlossen werden.

Ist das komplett?

Ja, mehr ist das bei mir nicht.

Was ist mit den Angaben für wpa-supplicant?

Guter Punkt. Aber bei mir läuft das ja als Accesspoint und nicht als WLAN-Client. Folglich ist bei mir der hostapd für die Verschlüsselung zuständig, bei einem Client wäre das dann wpa-supplicant.

Ich habe noch nie eine händisch gestrickte supplicant.conf benutzt.

Unter /usr/share/doc/wpasupplicant/examples gibt es Beispiele. Ich könnte mir aber vorstellen, daß folgendes in der /etc/network/interfaces auch funktioniert: (ohne Gewähr)

Code: Alles auswählen

auto lo
iface lo inet loopback

iface eth0 inet manual
iface wlan0 inet manual
  wpa-ssid Luftnummer
  wpa-psk  StrengGeheim

auto br0
iface br0 inet dhcp
  bridge_ports eth0 wlan0

(1) https://wiki.ubuntuusers.de/Netzwerkbr%C3%BCcke/

Nun stellt sich die Frage, ob folgende Aussage nur für Ubuntu gilt:

Diese Funktion des Kernels wurde deaktiviert. Soll ein WLAN-Adapter in eine Brücke integriert werden, so muss sich dieser im Master-Modus befinden! Die ist so nur in Kombination mit hostapd und einer Konfiguration als WLAN Router möglich. Alternative wäre den Kernel mit der entsprechenden Option selbst zu kompilieren.

[guennid]

Ich denke, wir lassen das. Ich komme damit nicht zurecht und habe mittlerweile die Überlegung weiterverfolgt, ob der Hausstromadapter angesichts der Erneuerung von 192.168.100.101 immer noch unbrauchbar ist. Das scheint nicht mehr der Fall zu sein. Ich schaufele gerade 2GB von einer Maschine auf den ehemaligen Router und das scheint trotz eingeschaltetem 192.168.100.101 störungsfrei zu laufen. OK schnell ist was anderes, aber das sind eben auch alte Maschinen. Sollte sich das stabilisieren, könnte ich auch auf diese Weise das 1er Netz loswerden.

Aber ich hätte doch zu gerne herausbekommen, warum diese Namensauflösung zwischen den Netzen nicht funktionierte.

[BenutzerGa4gooPh]

Aber ich hätte doch zu gerne herausbekommen, warum diese Namensauflösung zwischen den Netzen nicht funktionierte.

Wenn es vor der neuen Shorewall-Regel funktioniert hat, dann liegt es wohl an dieser. Die schränkt sicher zu weit ein, berücksichtigt das 192.168.1.0/24er Netz nicht.

Könnte man nochmal dran arbeiten.

Dein Netzplan ist übrigens verständlich so.
(Kleiner Mangel: Subnetting ist nicht richtig erkennbar, konnte man sich aber denken. In 10.0.0.0/8 ist das bei Subnetting nicht der Fall. Auch in 192.168.1.0/24 kann man weitere Teilnetze (Subnets) konfigurieren. Schreibe einfach in Dokumentation die Anzahl 1en der Subnetzmaske hinter die Adressen aller Router-Interfaces, z. B. 255.255.255.0 enthält 24 x 1, für 192.168.1.0/24. Bei Hosts (Clients) und Bridges muss man das nicht tun, sieht man am entsprechend gekennzeichneten Routerinterface. Vgl. a. https://de.m.wikipedia.org/wiki/Classle ... in_Routing)

Sorry für Schlaumeierei, aber Doku braucht man für sich selbst und für Helfer. Zu große Ausführlichkeit lässt sich ja flott
löschen.

[guennid]

Wenn es vor der neuen Shorewall-Regel funktioniert hat, dann liegt es wohl an dieser.

Da wär' ich jetzt nicht drauf gekommen!

Der Witz ist doch dass die 1. durch deine Anregung entstanden ist und 2. mir äußerst sinnvoll erscheint, ergo ich die partout nicht aufgeben will, aber 3. offenbar keine Mensch eine Idee hat, wieso die Maschinen hinter 192.168.1 mit dieser Regel keine Namensauflösungund ergo kein Internet mehr bekommen. Sakra!!!

[BenutzerGa4gooPh]

wieso die Maschinen hinter 192.168.1 mit dieser Regel keine Namensauflösungund ergo kein Internet mehr bekommen. Sakra!!!

Zusätzliche Zone für Problemnetzwerk oder nee besser Problem-Netzwerk in die vorhandene Zone mit aufnehmen? 1 Regel / 1 Zone mit 1 Alias für 2 Netzwerke? https://www.rrze.fau.de/dienste/arbeite ... wall.shtml
Jedenfalls liegt es an den Sourceadressen der entstehenden iptables.

Mit dem unbedingten Portforwarding für DNS (53) unabhängig von Quelladressen auf localhost (53) wäre das Problem auch gegessen (Mein erster Beitrag, die andere Idee kam von MSfree.)

Und noch eine Möglichkeit gibt es, warum bin ich nicht gleich drauf gekommen?!
Diesmal auf dem Shorewall-WAN-Interface: Reject, Outbound, alle Quelladressen, TCP/UDP, alle Quellports, NICHT-Operator auf Zieladresse LAN-Interface Archer, Port 53 (DNS). Eigentlich dürfte auch nur das Shorewall-WAN-Interface DNS-Anfragen stellen.

[guennid]

Mit dem unbedingten Portforwarding für DNS (53) unabhängig von Quelladressen auf localhost (53) wäre das Problem auch gegessen (Mein erster Beitrag [...])

Portforwarding sagt mir was, damit habe ich dazumalen hantieren müssen. Aber deinen Beitrag verstehe ich diesbezüglich immer noch nicht. Erklär' das doch bitte mal ausführlicher für Dumme.

[BenutzerGa4gooPh]

Alle (ANY) Quelladressen mit Zielport 53 (DNS), Zieladresse ANY, also auch Anfragen von kompromittierten Clients an andere DNS-Server als die Shorewall) werden immer auf Localhost (also Shorewall, 127.0.0.1, Port 53 = DNS-Server der Shorewall) umgeleitet. Dies muss dann Incoming auf dem internen Interface der Shorewall durchgeführt werden, also dort, wo deine ganzen Clients angeschlossen sind. Die Quelladressen sind egal (ANY).

(Eigentlich macht man Portforwarding umgekehrt, also um einen Dienst im LAN hinter NAT-Routern vom WAN aus verfügbar zu machen.)

DNS IPv4 basiert auf tcp/udp Port 53. Protokoll muss man in Regeln auch angeben, deshalb der Satz.

[guennid]

Tut mir leid, ich versteh's nach wie vor nicht, warum aufgrund der Zeile

Code: Alles auswählen

DNS(REJECT)  loc  net

in /etc/shorewall/rules auf der Shorewall-Maschine die Rechner, deren IP mit 192.168.100. beginnt, mit dem Eintrag

Code: Alles auswählen

nameservers 192.168.100.251

in ihrer jeweiligen /etc/resolv.conf ins Netz dürfen und diejenigen, deren IP mit 192.168.1. beginnt, mit demselben Eintrag in ihrer /etc/resolv.conf das nicht mehr können.

Ich habe hier [1] nochmal erfolglos versucht schlauer zu werden.

Ich muss mich insofern korrigieren: Ich hatte bei der Einrichtung meines Shorewall-Routers mit IP-Forwarding, nicht mit Port-Forwarding zu tun. Vielleicht hilft's weiter.

[1] http://shorewall.org/two-interface.htm#DNAT

[BenutzerGa4gooPh]

DNS(REJECT)  loc  net

Hhm. Habe mir das Manual angesehen. Um zu verstehen, muss man aber die ganzen vordefinierten Objekte nachvollziehen. Sowie deine Änderungen/Erweiterungen dieser. Also bleiben wir erst mal bei deiner Regel:

Du weist wie vorgeschlagen alle DNS Anfragen aus der lokalen Zone "loc" ins "net" zurück. DNS müsste dann funktionieren, sobald der Default-GW (also die Shorewall selbst in loc) angefragt wird. Klappt ja aus dem 100er Netz.

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!

Ansonsten wird die Shorewall auch zum Logging zurückgewiesener Pakete aufgrund welcher Regel zu überreden sein. Anhand der Paketeigenschaften vs Regel kommt meist der Effekt:

http://www.shorewall.net/troubleshoot.htm

[BenutzerGa4gooPh]

Vor den Basteleien am letzten Router (obige AW) probierst du noch Folgendes auf der Shorewall - bis es mit der Syntax der Shorewall und der Namensauflösung im 192.168.1.0/24er Netz klappt:

Voraussetzung: Das Netz 192.168.1.0/24 muss im Objekt "loc" enthalten sein. Oder es gibt bereits ein weiteres Objekt für dieses Netz. Dann müssten nachfolgend genannte Einträge auch dafür getätigt werden.
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST PORT(S)

Code: Alles auswählen

DNS(DNAT)  loc       loc:192.168.100.251

Falls Shorewall-Objekt DNS(DNAT) nicht existiert, müsste das funktionieren (beide Zeilen gemeinsam eintragen), DNAT sollte wenigstens vordefiniert sein:
#ACTION SOURCE DEST PROTO DEST PORT(S)

Code: Alles auswählen

DNAT      loc       loc:192.168.100.251:53   tcp 53
DNAT      loc       loc:192.168.100.251:53   udp 53

Erläuterung:
Die von dir hinzugefügte REJECT-Regel ist zu löschen.i
Alle DNS-Anfragen werdern so (hoffentlich) auf den Shorewall-DNS (Default-Gateway, Port53/tcp/udp umgeleitet (forwarded).
Ohne vorherige Bastelei am letzten Router zeigt die DNS-Funktion von Clients im 1er Netz die korrekte Funktion der Regel(n).
Zusätzlich im 100er Netz einem Client testweise die 8.8.8.8 (Google DNS) per resolv.conf verbraten, die Namensauflösung muss trotzdem per Shorewall laufen.
(Anstelle 192.168.100.251 wäre 127.0.0.1 (localhost) etwas hübscher. Falls mal IPs geändert werden, stimmt die Regel trotzdem. Kannst ja mal testen, ob Shorewall das auch nimmt. Ist recht wahrscheinlich. Gibt vielleicht sogar ein Objekt dafür.)
Log-Auswertung der Shorewall wegen Funktionalität und im Fehlerfalle!

Edit: Portnummern DNS von 52 auf 53 nach guennid Anfrage korrigiert.