Prerouting auf dnsmasq 127.0.0.1 funktioniert nicht

[uid]

Hallo

ich habe folgendes Verständnisproblem:

Ich benutze für meinen auf Ubuntu basierender Server dnsmasq (ausschließlich für DNS, DHCP mache ich woanders). Dieser lauscht lokal auf dem Server auf 127.0.0.1.

Mit der IPTables Regel :
$FW -I PREROUTING -t nat -p tcp --src $zone_lan --dport 53 -j DNAT --to 127.0.0.1:53
$FW -I PREROUTING -t nat -p udp --src $zone_lan --dport 53 -j DNAT --to 127.0.0.1:53

$FW -A INPUT -p tcp --dport 53 -d 127.0.0.1 -j ACCEPT
$FW -A INPUT -p udp --dport 53 -d 127.0.0.1 -j ACCEPT
$FW -A OUTPUT -p tcp --sport 53 -s 127.0.0.1 -j ACCEPT
$FW -A OUTPUT -p udp --sport 53 -s 127.0.0.1 -j ACCEPT

----------------
netstat | dnsmasq:
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 855/dnsmasq
udp 0 0 127.0.0.1:53 0.0.0.0:* 855/dnsmasq


... möchte ich erreichen, das die Anfragen der Clients von innerhalb meines Netzwerks auf 127.0.0.1:53 umgelenkt werden.
Das funktioniert nicht, Anfragen kommen nie an. (zu sehen beispielsweise in den Logs von dnsmasq)

Wenn ich dnsmasq auf der nach intern gerichteten Netzwerkkarte eth0 lauschen lasse, haut das natürlich hin. Insofern sollte dnsmasq richtig konfiguriert sein.

Mein Frage: Warum kommen die Anfragen nie an, wenn ich ausschließlich auf 127.0.0.1 lauschen lasse?
Ist das ne Eigenart von dnsmasq, iptables oder habe ich einen Denkfehler in der Rule?

Es geht mir hier vorrangig um iptables. Durch prerouting nat sollte das Ziel doch umgeschrieben werden, wirds aber nicht (richtig). Woran liegt das?


Falls ihr noch Infos braucht, reiche ich die gerne nach.

Grüße, Daniel

 

[greystone]

Sollte das statt --to nicht --to-destination heissen? Am besten noch mal in der man-page nachlesen.

Hast Du die gesetzten iptables Regeln überprüft?

Greifen die Regeln - sprich - erhöhen sich die Zähler bei watch -n1 --differences=cumulative iptables -t nat -L PREROUTING -v -n ?

 

[uid]

Hi greystone,

shit, ja, hast recht, muss to-destination heißen!

Der Zähler erhöht sich (danke für den watch String, kannte ich so noch nicht, sehr hilfreich!)

Ein weiterer Fehler, der sich eingeschlichen hat waren fehlende Regeln für In- und Out. Hab sie jetzt erstmal zum Test möglichst offen gelassen.
$FW -A INPUT -p tcp --sport 53 -j ACCEPT
$FW -A INPUT -p udp --sport 53 -j ACCEPT
$FW -A INPUT -p tcp --dport 53 -j ACCEPT
$FW -A INPUT -p udp --dport 53 -j ACCEPT

$FW -A OUTPUT -p tcp --sport 53 -j ACCEPT
$FW -A OUTPUT -p udp --sport 53 -j ACCEPT
$FW -A OUTPUT -p tcp --dport 53 -j ACCEPT
$FW -A OUTPUT -p udp --dport 53 -j ACCEPT

Nur klappen tuts trotzdem nicht, die in den logs von dnsmasq kommt auch mit to-destination nichts an.

Grüße

 

[greystone]

Hör doch mit tcpdump doch mal ein bisschen in die Leitung,

also z. B. (eth0 evtl. anpassen)

tcpdump -i eth0 -n port 53

und

tcpdump -i lo -n port 53

...am besten mit zwei Fenstern parallel
...und poste mal die tatsächliche iptables-Konfiguration, also:

iptables -L INPUT -v -n
iptables -t nat -L PREROUTING -v -n

Wenn man sich Mühe dabei gibt anderen die benötigten Informationen sauber aufzubereiten und sich somit noch genauer mit seiner Konfiguration beschäftigt, fällt's einem selber manchmal wie Schuppen von den Augen. (Selbst oft genug erlebt). Spezielle Bitte: Code Tags verwenden!

Am besten auch mal alle iptables-Ketten beobachten und vielleicht ein paar Log-Regeln als einzige Regel einfügen. Man weiss ja manchmal gar nicht so genau in welches Universum die eigenen Konfigurationsfehler die Pakete so hinschicken

 

[uid]

Wenn man sich Mühe dabei gibt anderen die benötigten Informationen sauber aufzubereiten und sich somit noch genauer mit seiner Konfiguration beschäftigt, fällt's einem selber manchmal wie Schuppen von den Augen.

Da hast du natürlich recht, wollte euch wegen der eigentlichen Frage nicht gleich mit Infos überfluten. Mit etwas Glück wärs das --to / --to-destination schon gewesen.

Vielleicht nochmal anders ausgedrückt: Ich gehe zur Zeit tiefer ins Thema iptables, wollte mich eigentlich mit der Absicherung auseinandersetzen und scheitere an dieser eigentlich recht einfachen Geschichte. Das restliche Drumherum war mir jetzt erstmal nicht so wichtig, mir gings um speziell diese eine iptables Frage. Ich bin seit 6 Jahren Sysadmin für Linux in einem mittelständingen Unternehmen mit rund 700 Servern, gehe da also nicht ganz unbedarft ran.
Naja, hab trotzdem einfach mal In-Output Regeln vergessen... klatsch an die Stirn.

Ich hatte das ganze so gestrickt, das iptables in einem Testscript nur ssh, masquerading und eben den DNS Zugriff macht. Andere Regeln sind für diesen Test nicht enthalten, dewegen fand ich den Rest jetzt nicht so relevant.

Irgenwas verchecke ich hier aber, und komme nicht weiter.


Netzwerk intern:

LAN: 10.1.0.0/16
Server internes Interface: 10.1.1.1
Testrechner für Anfragen im LAN: 10.1.1.100

dnsmasq.conf

listen-address=127.0.0.1
#listen-address=10.1.1.1
bind-interfaces

netstat -alpn|grep dnsm

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      10738/dnsmasq
udp        0      0 127.0.0.1:53            0.0.0.0:*                           10738/dnsmasq

IPTABLES:

+ /sbin/iptables -F
+ /sbin/iptables -X
+ /sbin/iptables -t nat -F
+ /sbin/iptables -t nat -X
+ /sbin/iptables -t mangle -F
+ /sbin/iptables -t mangle -X
+ POLICY=DROP
+ /sbin/iptables -P INPUT DROP
+ /sbin/iptables -P FORWARD DROP
+ /sbin/iptables -P OUTPUT DROP
+ /sbin/iptables -A INPUT -i lo -j ACCEPT
+ /sbin/iptables -A OUTPUT -o lo -j ACCEPT
+ /sbin/iptables -A INPUT -p tcp --src 10.1.0.0/16 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
+ /sbin/iptables -A OUTPUT -p tcp --dest 10.1.0.0/16 --sport 22 -m state --state ESTABLISHED -j ACCEPT
+ '[' 1 == 0 ']'
+ /sbin/iptables -A INPUT -p tcp --sport 53 -j ACCEPT
+ /sbin/iptables -A INPUT -p udp --sport 53 -j ACCEPT
+ /sbin/iptables -A INPUT -p tcp --dport 53 -j ACCEPT
+ /sbin/iptables -A INPUT -p udp --dport 53 -j ACCEPT
+ /sbin/iptables -A OUTPUT -p tcp --sport 53 -j ACCEPT
+ /sbin/iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
+ /sbin/iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
+ /sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
+ /sbin/iptables -N pings
+ /sbin/iptables -A pings -p icmp --icmp-type any -j ACCEPT
+ /sbin/iptables -A INPUT -j pings
+ /sbin/iptables -A OUTPUT -j pings
+ /sbin/iptables -A FORWARD -j pings
+ '[' 1 == 0 ']'
[B]+ /sbin/iptables -I PREROUTING -t nat -p tcp --src 10.1.0.0/16 --dport 53 -j DNAT --to-destination 127.0.0.1:53 -m comment --comment 'DNS Prerouting TCP'
+ /sbin/iptables -I PREROUTING -t nat -p udp --src 10.1.0.0/16 --dport 53 -j DNAT --to-destination 127.0.0.1:53 -m comment --comment 'DNS Prerouting UDP'[/B]
+ /sbin/iptables -t nat -A POSTROUTING -o extern -j MASQUERADE
+ /sbin/iptables -A INPUT -j LOG -m limit --limit 12/min --log-level 4 --log-prefix 'IP INPUT drop: '
+ /sbin/iptables -A OUTPUT -j LOG -m limit --limit 12/min --log-level 4 --log-prefix 'IP OUTPUT drop: '

Wenn ich ein tcpdump drauf ansetze, wird nicht auf 127.0.01 umgeschrieben.
Ein dig google.de von einem anderen Rechner im internen Lan ergibt folgendes:


tcpdump -i intern -n port 53

03:33:37.036063 IP [B]10.1.1.100.55235 > 10.1.1.1.53[/B]: 44876+ [1au] A? google.de. (38)

.. Eine Antwort kommt nicht, klar, dnsmasq lauscht ausschließlich auf 127.0.0.1
(weiß nicht , wo tcpdump genau einsetzt, aber sollte da nicht gleich:
10.1.1.100.XXXXX > 127.0.0.1.53
stehen? Na vlt. auch nicht, die Anfrage geht ja erstmal ans interne Interface und wird erst dann durch iptables verbogen, oder wo hackt sich tcpdump ein? )

jedenfalls kommt bei:

[B]tcpdump -i lo -n port 53[/B]

.. gar nichts an.

Lasse ich dnsmasq auf 10.1.1.1 laufen, funktioniert alles. (mit entsprechend angepassten iptables Regeln natürlich)

Der Zähler geht bei:

watch -n1 --differences=cumulative iptables -t nat -L PREROUTING -v -n

nach oben, die Regel an sich fühlt sich also angesprochen.

Bleibt die Frage, warum da nicht umgebogen wird? Ich checks nicht.
Das 10.1.0.0/16 kein Standard privater IPAdress Bereich ist, sollte doch damit nichts zu tun haben, oder irre ich mich? (Will jetzt nicht alles umbiegen, da hängt ne Menge dran)

 

[storvi]

Darf ich fragen WARUM du das machen möchtest?

Was spricht gegen ein sauber konfigurierten DNS-Server welcher direkt auf der IP des Interfaces lauscht und damit die Anfragen ohne zusätzliches Natting / Forwarding beantworten kann?

Gruß
Markus

 

[greystone]

Unabhängig von der Frage nach dem Sinn, habe ich da so dunkel etwas in Erinnerung.

Ich meine ich hatte auch einmal so etwas vor, um Zugriff auf VNC-Ports die von Xen an localhost gebunden waren und die ich per iptables nach außen zugreifbar machen wollte. Ich meine mich zu erinnern, dass da eine Sicherheitsmassnahme von iptables ist, die genau das verhindert - kann mich aber auch täuschen.

iptables man-page bzw. Google-Recherche sollte weiterhelfen.

Da hast du natürlich recht, wollte euch wegen der eigentlichen Frage nicht gleich mit Infos überfluten.

Ja, das kann bei mir schon Mal passieren, wenn ich einen 3 Seiten langen Erstbeitrag sehe, dass ich mir denke: Oh, Mann! Wie anstrengend! Und gleich wieder zu klicke.

EDIT: BINGO!!!

http://hauweele.net/~gawen/blog/?tag=route_localnet
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

route_localnet - BOOLEAN
	Do not consider loopback addresses as martian source or destination
	while routing. This enables the use of 127/8 for local routing purposes.
	default FALSE

 

[uid]

Darf ich fragen WARUM du das machen möchtest?

Was spricht gegen ein sauber konfigurierten DNS-Server welcher direkt auf der IP des Interfaces lauscht und damit die Anfragen ohne zusätzliches Natting / Forwarding beantworten kann?

Klar darfst du Markus
2 Gründe:
1) Ich wollte sehen, das die Pakete schön an das Loopback gehen, einen eindeutigen Weg nehmen sozusagen, um dann vom Loopback wieder nach außen für Adressen, die nicht intern aufgelöst werden können.
Nachdem nach einem kurzen Test aufs Loopback das nat'ing nicht so richtig funktionieren wollte, wollte ich ausschließen, das sich Pakete doch direkt ins Netz schmuggeln, wenn ich an der internen Schnittstelle lausche, was ich vermeiden wollte, grad im Hinblick auf andere, wichtigere Dienste. War mehr eine Verständnisfrage.

2) eigentlich fast wie 1) ... ich wollte sehen, das ich keinen Denkfehler beim nat'ing mache. Deshalb erstmal das Umgebiege auf das Loopback, um zu sehen, daß das korrekt läuft. Hat also mit der letztendlichen Konfiguration eigentlich nicht viel zu tun. War eher eine Wissensfrage. Ich wollte / und möchte mit Halbwissen a la "hab ich schon verstanden wie's funktionieren soll", aber nie so wirklich überprüft, ob's tatsächlich so läuft, wie ich meine es verstanden zu haben, aufräumen.

 

[uid]

Ja, das kann bei mir schon Mal passieren, wenn ich einen 3 Seiten langen Erstbeitrag sehe, dass ich mir denke: Oh, Mann! Wie anstrengend! Und gleich wieder zu klicke.

Genau


...

Adressen ...
route_localnet - BOOLEAN
Do not consider loopback addresses as martian source or destination
while routing. This enables the use of 127/8 for local routing purposes.
default FALSE

Yo, perfekt! Damit ist das klar. Danke!!

Ich habe jetzt eine lokale Schnittstelle:

intern:service

definiert, um die lokale Schnittstelle zu umgehen und mir trotzdem anschauen zu können, was passiert... was mir immer noch nicht gelingt. Wtf ...

Folgendes hab ich gemacht:
virtuelles Interface

intern:service hört auf 172.20.2.1

Dnsmasq ist konfiguriert, um auf dieser Schnittstelle zu lauschen:

listen-address=127.0.0.1
#listen-address=10.1.1.1
listen-address=172.20.2.1
bind-interfaces

netstat:

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      17722/dnsmasq
tcp        0      0 172.20.2.1:53           0.0.0.0:*               LISTEN      17722/dnsmasq
udp        0      0 127.0.0.1:53            0.0.0.0:*                           17722/dnsmasq
udp        0      0 172.20.2.1:53           0.0.0.0:*                           17722/dnsmasq

resolv.conf hat einen Eintrag:

nameserver 172.20.2.1

Iptables entsprechend konfiguriert:

$FW -I PREROUTING -t nat  -p tcp --src $zone_lan --dport 53   -j DNAT [B]--to-destination 172.20.2.1:53 [/B]-m comment --comment "DNS Prerouting TCP"
$FW -I PREROUTING -t nat  -p udp --src $zone_lan --dport 53   -j DNAT [B]--to-destination 172.20.2.1:53[/B] -m comment --comment "DNS Prerouting UDP"

... Ok, sollte passen.

Tcpdump kann nicht auf virtuellen Interfaces lauschen, gibt mir bei:

tcpdump -i intern:service -n port 53

nur einen Mitschnit vom physischen Interface: intern wieder. Soweit schade, aber korrekt.

Also tshark benutzt und möglichst offen gelassen:

tshark  "host 172.20.2.1"

Als Ergebnis bekomme ich allerdings keine Infos über Verkehr auf dieser IP per DNS. Ein Ping direkt auf die Adresse ist zu sehen.
Eine Anfrage vom Testrechner wird immer mit einem Forward 10.1.1.100 (Testrechner) auf die externe DNS Adresse beantwortet.

Ein forwarding habe ich jedoch nicht eingebaut (kann natürlich auch gemeint sein, das dnsmasq die Anfrage forwarded) , und für mich noch seltsamer, es gibt keinerlei Verkehr über 172.20.2.1

Da die DNS Anfragen an sich aber beantwortet werden, wenn dnsmasq läuft, aber nicht, wenn ich dnsmasq stoppe, die 172.20.2.1 die einzige Adresse ist, auf die er hört, kann ich indirekt schließen, daß das ganze korrekt funktioniert.

Wie kann ich eindeutig mitlesen, wie die Anfrage läuft ? Langsam hab ich anscheinend ein Brett vorm Kopf. Sorry, wenn ich mich hier dusselig anstelle.

 

[greystone]

Da hast du natürlich recht, wollte euch wegen der eigentlichen Frage nicht gleich mit Infos überfluten.

Ich find das gut, die umfangreicheren Informationen, Scripte, Debugs, ... auszulagern(z. B. irgend ein NoPaste, z. B. http://fpaste.org), damit der Hauptbeitrag kurz und knapp bleibt.

Scripte packe ich meist in mein Mülleimer-GitHub-Repo, da man bei NoPaste idR nicht editieren kann und keine History hat.