[Gelöst] AVM-Firewall-cgi DNSMasq und interne DNS-Portumleitung / -Weiterleitung

[WileC]

Hallo liebe Forumler,

ist es denn möglich, mit der internen AVM-Firewall über das avm-firewall-cgi (freetz) den DNS-Port von 53 auf z.b. 5353 umzuleiten ??!

MfG
WileC

 

[RalfFriedl]

Ich vermute, dass die AVM Firewall nur etwas auf dem externen DSL-Interface tut.

 

[WileC]

Das heißt, ich bräuchte iptables oder etwas anderes ?! .. Ich möchte einfach alles, was auf Port 53 auf der Box aufläuft, auf Port 5353 der Box umleiten. Sonst nix..

 

[sf3978]

... oder etwas anderes ?! ...

Ich kann mit iptables, den udp-Port 53 nicht umleiten. tcp-Ports kann ich umleiten. Bei cuma geht das mit den udp-Ports. Ich versuche mal "udp_redirect" für die Box zu kompilieren:

Usage:
./udp_redirect our-ip our-port send-to-ip send-to-port
./udp_redirect our-ip our-port [I](echo mode)[/I]
Example:
 ./udp_redirect 0.0.0.0 53 192.168.0.1 53
./udp_redirect 0.0.0.0 7

 

[Suchiman]

Mh mit welchem sinn ? Selbst wenn du das hinkriegst, der würde dann sozusagen auf 53 und 5353 laufen, so... dual (Ich würde ja mal raten dass es etwas mit Multid und DNSMASQ zu tuen hat)

@sf3978 die neue Labor von AVM unterstützt auch DNS mit TCP

 

[sf3978]

... die neue Labor von AVM unterstützt auch DNS mit TCP

Danke für den Hinweis, aber ich habe z. Zt. keine Probleme mit dem Port 53. Ich mache das nur so, zum experimentieren und probieren.

EDIT:
Man kann ein DNS-Server nur, z. B. auf Port 5353 lauschen lassen. Die Clients sind aber für den Port 53 konfiguriert und deshalb die Umleitung.

 

[Suchiman]

Achsooo jetzt verstehe ich, hehe ich habe zuerst verstanden, dass der Port auf 53 läuft und alle anfragen von 5353 auf 53 umgeleitet werden sollen

 

[WileC]

Nene, ich möchte das DNSMasq / multid - Problem umgehen, indem ich ganz normal den multid auf #53 laufen lasse und den DNSMasq an Port 5353 binde. Die Client-Anfragen kommen ja immer über #53. Somit müsste in der Box der Port 53 auf 5353 umgeleitet werden

 

[sf3978]

Mit "udp_redirect" auf der Box geht es nicht bzw. kann es nicht funktionieren. "udp_redirect" müsste ja auf den Clients aktiv sein, und dort den Port 53, auf den Port 5353 der Box umleiten. Die Umleitung mit iptables (REDIRECT oder DNAT) will bei mir (noch) nicht funktionieren. Mit nmap kann ich den Port 5354 (bei mir!) über den Port 53 zwar scannen, mehr geht aber nicht. Muss weiter probieren.

 

[WileC]

Ah vielen Dank .. da wäre wahrscheinlich ein mod des multid besser, den den auf einen anderen Port bindet...

 

[MaxMuster]

Also bei mir funktioniert z.B. diese iptables-Regel für UDP:

# Generated by iptables-save v1.4.11.1 on Sat Dec 31 15:27:47 2011
*nat
:PREROUTING ACCEPT [8:578]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -i lan -p udp -m udp --dport 53 -j REDIRECT --to-ports 5533
COMMIT
# Completed on Sat Dec 31 15:27:47 2011

Ein probehalber in der BusyBox eingeschalteter dnsd kann dann auf Port 5533 antworten.

Multid zu "modden" ist nicht so trivial, weil ein AVM Binary. Wenn aber beim Start des multid der Port 53 "besetzt" ist, startet der multid halt ohne DNS-Server...
Also z.B. multid stoppen, "eigenen" DNS starten und dann den multid wieder starten. Du könntest das zur Not auch in einem "Wrapper" um das AVM-Binary mit Freetz in das Image "fest einbauen".

 

[WileC]

Hmm.. das ist ja das Problem: wenn der multid nix auf dem Port 53 machen kann, dann funktionieren die ein oder anderen AVM-Dienste nicht wirklich... Und ich glaube, iptables wird zu kompliziert für mich sein ?!

 

[WileC]

Das Problem wurde mittels Ticket http://freetz.org/ticket/1648 gelöst. Dort hat "cuma" einen Patch veröffentlicht, der das Problem mit der Portbindung des MultiD und DNSMasq löst. Getestet mit Trunk r8394.

 

[WileC]

Ich wollte diesen Thread mal wieder ausgraben und fragen, ob die DNS-Portumleitung mittels voip_forwardrules möglich ist? Oder wirken sich die voip_forwardrules lediglich auf den Datenverkehr vom DSL/WAN-Interface zum LAN-Interface aus ? .. Oder kümmern die sich vielleicht auch um den "internen" Netzverkehr?

Oder führt immer noch kein Weg an IPTABLES vorbei?

Danke schon mal