• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Namensauflösung bcast geht mit Firewall nicht

R

RidewithStyle

Member
Hi,

ein Problem was ich bisher immer mit hosts Einträgen umgangen habe ist, dass meine Firewall lokale Namensauflösung verhindert. Internet DNS ist alles in Ordnung mit und ohne Firewall. Bloß ein ping lokaler_hostname bringt: unknown host. Wenn ich die Firewall abschalte (die der Quelle, nicht des Ziels) geht der Ping durch, mit Firewall nicht. Ping auf die IP direkt geht mit und ohne Firewall. Ich komm nicht dahinter wo der Haken sein könnte. Standardgateways sind eingerichtet, erster DNS Server ist der Router. Da die Sache geht, wenn die Firewall aus ist, tippe ich mal dezent auf die Firewall (welch Erleuchtung). In der Suse Firewall ist in der Broadcast Config netbios-ns netbios-dgm bootps ntp eingetragen, hab das Gefühl, das da was fehlt. Bloß was nur?

OS Suse 10.1

Gruß, rws
 
S

SP

Member
Kann der Hostname mit host dein_host_name aufgelöst werden? Du verwaltest das lokale DNS auf dem Router und nicht auf deinem Rechner oder?
 
OP
R

RidewithStyle

Member
host hostname schlägt fehl mit : 'Host zeus not found: 3(NXDOMAIN)' mit und ohne Firewall. host hostname geht weder als 'host zielrechner' noch als 'host quellrechner'.

ping direkt auf ip geht mit und ohne firewall
ping auf hostname geht nur ohne firewall

die frage ob ich lokales dns aufm router oder rechner hab versteh ich ehrlich gesagt net.

In der nsswitch.conf ist die reihenfolge der hosts: wins files dns bcast
in der smb.conf ist die resolve order: hosts wins bcast
in der /etc/resolv.conf sind als nameserver der router und der 1. dns meines isp eingetragen (das war der networkmanager, ich habs nicht eingetragen)

Laut NM ist meine Broadcastadresse richtig, mein Defaultgateway passt (router) und primary dns ist auch der router. Wenn ich die Firewall ausschalte dauert der erste ping bis zu 7 Sekunden, daher geh ich mal davon aus, das er über broadcast ermittelt wird.

Hat dir das jetzt was geholfen oder wolltest du was anderes wissen?

gruß, rws
 
framp

framp

Moderator
Teammitglied
RidewithStyle schrieb:
in der /etc/resolv.conf sind als nameserver der router und der 1. dns meines isp eingetragen (das war der networkmanager, ich habs nicht eingetragen)
Zum Vergrößern anklicken....
Hast Du auch eine 'search' Zeile darin? Wie sieht die aus?
 
OP
R

RidewithStyle

Member
nope, search zeile hab ich keine, hatte das schonmal gesehen irgendwo. sowas wie Search my.localdomain, aber ich war mir nicht sicher ob sich das gehört, da ich ja nur ne arbeitsgruppe hab. Was müsst ich dann eintragen?

[edit]

Hab mal mit nslookup versucht hostnamen zu bekommen. Das ist mir aufgefallen, dass er versucht hat den ISP DNS Server zu befragen, nicht meinen lokalen Router. Obwohl als Primary DNS mein Router eingetragen ist. Ist dieses Verhalten normal? Nimmt NSLookup immer der ersten public DNS? Wenn host genauso arbeitet wie nslookup dann ist mir klar warum der isp dns server keinen rechner kennt. Dann macht auch Sinn warum der erste Ping ohne Firewall immer über bcast läuft. Aber warum wird der bcast von der firewall geblockt und warum wird der falsche DNS Server befragt? :roll:
 
S

SP

Member
Versuch mal mit dig gezielt den Router zu befragen.

Code: 
dig @router-ip lokaler-hostname
 
OP
R

RidewithStyle

Member
ok, 'digg routerip zielhostname' bringt

Code: 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2703
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;192.168.0.254.			IN	A

;; AUTHORITY SECTION:
.			10608	IN	SOA	A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2006100900 1800 900 604800 86400

;; Query time: 11 msec
;; SERVER: 212.114.152.1#53(212.114.152.1)
;; WHEN: Mon Oct  9 21:57:04 2006
;; MSG SIZE  rcvd: 106


; <<>> DiG 9.3.2 <<>> 192.168.0.254 zeus
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18752
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;zeus.				IN	A

;; AUTHORITY SECTION:
.			10764	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2006100900 1800 900 604800 86400

;; Query time: 30 msec
;; SERVER: 212.114.152.1#53(212.114.152.1)
;; WHEN: Mon Oct  9 21:57:05 2006
;; MSG SIZE  rcvd: 97

Ich werd da nicht schlauer draus, hilft dir das?
 
S

SP

Member
dig routerip zielhostname fragt erst nach routerip und dann nach zielhostname beim Standard-DNS-Server.

dig @routerip zielhostname befragt den Router (also das "@" dazu).

Der Output jetzt zeigt nur, dass der DNS-Server vom Provider befragt wird und der deinen Host nicht kennt.
 
OP
R

RidewithStyle

Member
my bad, dig @192.168.0.254 hostname liefert

Code: 
; <<>> DiG 9.3.2 <<>> @192.168.0.254 zeus
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

gleiche antwort für ziel- und quellhost. heißt das mein router weiß gar nix?
 
S

SP

Member
Wahrscheinlich antwortet der Router nicht, oder die Pakete werden von einer Firewall geblockt (Rechner oder Router). Versuchs nochmal ohne Firewall und schau evtl. nach, ob der DNS-Server im Router aktiviert ist.
 
OP
R

RidewithStyle

Member
yep, global is in ordnung. es handelt sich nur um die auflösung lokaler namen. hier die antwort von msn.de

Code: 
; <<>> DiG 9.3.2 <<>> @192.168.0.254 www.msn.de
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22641
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.msn.de.			IN	A

;; ANSWER SECTION:
www.msn.de.		76223	IN	CNAME	www.msn.de.msnemea.nsatc.net.
www.msn.de.msnemea.nsatc.net. 300 IN	A	213.199.159.108

;; AUTHORITY SECTION:
nsatc.net.		160745	IN	NS	de-4.ns.nsatc.net.
nsatc.net.		160745	IN	NS	uk-6.ns.nsatc.net.
nsatc.net.		160745	IN	NS	b.ns.nsatc.net.
nsatc.net.		160745	IN	NS	e.ns.nsatc.net.

;; ADDITIONAL SECTION:
b.ns.nsatc.net.		160745	IN	A	213.254.244.5
e.ns.nsatc.net.		170503	IN	A	212.187.162.134
de-4.ns.nsatc.net.	170503	IN	A	212.162.1.102
uk-6.ns.nsatc.net.	160745	IN	A	206.24.172.39

;; Query time: 22 msec
;; SERVER: 192.168.0.254#53(192.168.0.254)
;; WHEN: Wed Oct 11 09:24:22 2006
;; MSG SIZE  rcvd: 223

[edit]
Achja, besser als x-mal zu beschreiben, hier die Einstellungen des HDCP/DNS im Router.
 
S

SP

Member
Bekommt dein Rechner seinen Hostnamen vom Router zugewiesen? Oder hast du im Router den Namen einer IP bzw. MAC-Adresse zugeordnet (evtl. Clients-Liste oder Feste Zuweisung in dem Interface auf dem Bild)?
 
OP
R

RidewithStyle

Member
Feste Zuweisung beinhaltet eine Zuordnung von MAC Adressen zu IP-Adressen, um PortForwarding und DHCP zu ermöglichen. Hostnamen werden also nicht vom Router vergeben, sondern sind in Linux hinterlegt. Das gleiche Router-Setup unter Windows (alle Rechner sind DualBoot) funktioniert mit ping hostname, weiß nicht in wie weit das eine Hilfe sein könnte (Oder evtl auch ein Grund zur Steinigung, weil ich immer noch nicht purer Linux-HaXX0r bin).
 
OP
R

RidewithStyle

Member
Update: Nachdem ich irgendwie das Gefühl habe, als würde mein Router DNS Anfragen einfach ungesehen an den ISP DNS weiterleiten, bin ich mal der Sache mit dem Broadcast auf den Grund gegangen.

habe mit 'nmblookup hostname' geschaut was in der /var/log/firewall hängenbleibt. Da ich das ganze von Attila (192.168.0.1 auf Zeus 192.168.0.14 versucht habe, bleibt also die Antwort auf den Broadcast in der Firewall hängen)

Code: 
Oct 12 17:36:51 attila kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:50:8d:fb:8d:64:00:12:f0:85:6e:d4:08:00 SRC=192.168.0.14 DST=192.168.0.1 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=10668 LEN=70

nmblookup selber gibt folgendes zurück:

Code: 
attila:/home/ridewithstyle # nmblookup zeus
querying zeus on 192.168.0.255
querying zeus on 172.16.196.255
querying zeus on 172.16.206.255
name_query failed to find name zeus

nach einem 'rcSuSEfirewall2 stop' ergibt nmblookup hostname

Code: 
attila:/home/ridewithstyle # nmblookup zeus
querying zeus on 192.168.0.255
192.168.0.14 zeus<00>

also muss ich es schaffen, der firewall dieses obige Paket als gut zu erklären. Yast2 lässt mich nicht einfach den Port 137 bei UDP freischalten, scheinbar geht das über Optionen unter Broadcast. Aber ich habe keine Ahnung wie die Option heißt, die ich suche. Google ist da wenig hilfreich, das ist zu speziell. Wollte das jetzt auch nicht crossposten, evtl hat jetzt jemand ja ne Idee.

Gruß, rws
 
S

SP

Member
Steht die Konfiguration für die SuSE-Firewall nicht in /etc/sysconfig/firewall oder so ähnlich?
 
OP
R

RidewithStyle

Member
Problem vorerst gelöst!

Wie man dem Ausschnitt von /var/log/firewall entnehmen konnte bliebt das gewünschte UDP Paket ja hängen. Was ich nicht verstanden habe ist, welche Regel dafür verantwortlich war. Irgendwann klickte es aber und ich hab begriffen, dass der Port 137 nicht der Destination, sondern der Sourceport war. Destination sprang immer so in der 3000ern hin und her. Also kann ich keine Regeln anlegen die nach dem Zielport geht, sondern muss anhand des Quellports entscheiden. Gleich mal mit Webmin Regel angelegt (dort ist das ziemlich übersichtlich) und schon kam das Paket durch. Problem ist aber, dass die Susekonfig ja bei jedem Neustart neue Regeln generiert also muss die Lösung in der Susekonfig erfolgen. Und das hab ich über /etc/sysconfig/firewall in der Section FW_ALLOW_INCOMING_HIGHPORTS_UDP gemacht, indem ich "137" eingetragen hab. Allerdings mault jetzt die Firewall bei jedem Start rum:

SuSEfirewall2: Warning: FW_ALLOW_INCOMING_HIGHPORTS_UDP is deprecated and will likely be removed in the future.
SuSEfirewall2: Warning: If you think it should be kept please report your use case at
SuSEfirewall2: Warning: http://forge.novell.com/modules/xfmod/project/?susefirewall2

Also werd ich mal weiterwühlen, warum Novell dieses feature loswerden will. In Yast2 war das ganze ja schonmal nicht zu erreichen, d.h. die Option geht nur über Text editieren.

Immerhin funktioniert jetzt meine Namensauflösung, unter Windows ist mir das nie aufgefallen, ich frag mich wieso das da funktioniert hat.

Nochmal danke für alle Tips & Hilfsversuche

Gruß, rws
 
OP
R

RidewithStyle

Member
dachte ich auch, aber wie du dem firewall-Eintrag entnehmen kannst
Code: 
Oct 12 17:36:51 attila kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:50:8d:fb:8d:64:00:12:f0:85:6e:d4:08:00 SRC=192.168.0.14 DST=192.168.0.1 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=10668 LEN=70

speziell
Code: 
SPT=SourcePorT 137
DPT=DestinationPorT 10668

ist dem scheinbar nicht so. Hab der Suse Firewall devel mailinglist geschrieben, mal sehen was (oder ob überhaupt) ne Antwort kommt.

gruß, rws
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben