ifconfig-alias + Samba = PDC unreachable

fraenki

Active Member
Hi,

ich habe heute ein sehr lästiges und doch interessantes Problem zum ersten
Mal beobachtet... vielleicht kann sich ja jemand einen Reim darauf machen
oder mir ein wenig unter die Arme greifen. DAS IST EINE HERAUSFORDERUNG :-)


SITUATION
Ich nutze ein FreeBSD 5.4-STABLE (Tue May 17 17:39:16) und betreibe darauf
u.a. einen Samba3-PDC. Darüber hinaus habe ich auf der einzigen Netzwerkkarte
etwa folgende Konfiguration (anonymisiert):

ifconfig_vr0="inet [offizielle IP] netmask 255.255.255.248"
ifconfig_vr0_alias0="inet 192.168.0.126 netmask 255.255.255.0"
defaultrouter="[offizielle IP des SDSL-Routers]"

Mein "Office-Netz" ist also 192.168.0.0/24. Darunter auch z.B. der Windows-Client,
der darauf zugreift. Die Samba-Domäne heisst "OFFICE". Außerdem habe ich ein
kleines Netz mit offiziellen IP-Adresse (/29).


PROBLEM
Seit heute kann ich von dem Windows-Client (192.168.0.102) nicht mehr auf die
Samba-Domäne "OFFICE" zugreifen. Dass es ausgerechnet seit heute nicht mehr geht,
liegt vrsl. daran, dass ich erst gestern den Server rebooten musste...


VERSUCHE
Ich habe den Windows-Client jetzt erstmal aus der Domäne rausgenommen und in
eine Arbeitsgruppe gesteckt. Anschließend habe ich wieder versucht, ihn neu in die
Domäne hinzuzufügen, was mit folgender Meldung quittiert wird:

"Es konnte keine Verbindung mit einem Domänencontroller für die Domäne 'Office'
hergestellt werden.
Stellen Sie sicher, dass der Domänenname richtig eingegeben wurde. [...]"

Nagut, also habe ich mal die Samba-Logfiles und das Firewall-Log durchsucht,
aber Fehlanzeige. Nirgends ein Fehler zu finden.

Nachdem ich dann also viel herumprobiert habe, war das Ergebnis einige modifizierte
Firewallregeln für Samba (137-139, 445), die die Kommunikation jetzt nur noch auf das
Netz 192.168.0.0/24 beschränken, sowie folgende zusätzliche Einträge in der smb.conf:

socket address = 192.168.0.126
interfaces = 192.168.0.0/24 127.0.0.1
bind interfaces only = yes
hosts allow = 192.168.0. 127.0.0.1


ERKENNTNIS ;-)
Das Ergebnis einiger Stunden: ich bin nun davon überzeugt, dass mein Windows-Client
nicht mehr in die Samba-Domäne kommt, weil die Antwortpakete über die primäre
IP meines Netzwerkinterfaces (also die offizielle-IP des SDSL-Anschlußes) verschickt
werden.
Diese Theorie wird auch dadurch gestützt, dass ich wieder Zugriff auf die Domäne hatte,
als ich zu Testzwecken einmal eine IP aus meinem /29er SDSL-Netz auf dem Windows-Client
konfiguriert hatte.

Das Dumme daran ist, dass ich dachte, meinem Samba bereits alles gesagt zu haben
und es jetzt nach meinem Verständnis gar nicht mehr über die SDSL-IPs rausgehen dürfte..

Evtl. hängt das Problem auch mit dem Upgrade auf 5.4-STABLE (von 5.4-PRERELEASE)
vor einigen Tagen zusammen... seltsam nur, warum es dann erst jetzt auftritt... also ich
halte das für unwahrscheinlich....


Vielen Dank für jeden Tip!

Ciao
- Fraenki
 
routing table

Hi,

> netstat -rn bitte.

gerne :) (die S-DSL IP's habe ich anonymisiert)

Internet:
Destination Gateway Flags Refs Use Netif Expire
default [S-DSL Router] UGS 0 6862 vr0
127.0.0.1 127.0.0.1 UH 0 2946 lo0
192.168.0 link#1 UC 0 0 vr0
192.168.0.101 00:11:09:2c:e1:46 UHLW 0 176 vr0 1139
192.168.0.126 00:40:63:c3:98:a0 UHLW 0 465 lo0
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWb 0 516 vr0
[S-DSL Netz /29] link#1 UC 0 0 vr0
[S-DSL Router] 00:20:6f:0f:8a:92 UHLW 1 0 vr0 1145
[S-DSL BCAST] ff:ff:ff:ff:ff:ff UHLWb 0 142 vr0

Die .101 ist btw. meine FreeBSD-Workstation.. der Windows-Client .102 läuft gerade nicht.
Die interne IP des Servers ist ja die 192.168.0.126..

> um Probieren: Mit tcpdump den Verkehr abhoeren.

Ja, das werde ich mal probieren.. ggf. poste ich dass dann mal hier, falls etwas
interessantes dabei herauskommt...


Ciao
- Fraenki
 
tcpdump

> Zum Probieren: Mit tcpdump den Verkehr abhoeren.

Also im tcpdump sehe ich beim Versuch, den Windows-Client in die Domäne
hinzuzufügen folgendes:

SRC:192.168.0.102 DST:192.168.0.255 PROTO:NBNS INFO:Name query NB OFFICE<1c>

Allerdings bleibt es dabei (insofern hat die Windows-Fehlermeldung ja Recht)..
ich sehe keine Antwort vom Samba-Server ins 192er Netz... alles was ich gelegentlich
im Firewall-Logfile sehe, ist folgendes:

May 21 13:21:57 luzy kernel: ipfw: 65534 Reset UDP [SDSL Server-IP]:138 192.168.0.255:138 out via vr0
May 21 13:21:57 luzy kernel: ipfw: 65534 Reset UDP [SDSL Server-IP]:138 192.168.0.255:138 out via vr0

Und das habe ich halt geblockt, weil die Kommunikation nur innerhalb des 192.168.0.0/24
stattfinden sollte. Außerdem nützt es nichts, wenn ich diese Pakete erlaube, weil sie ihr
Ziel leider trotzdem nicht erreichen...

Irgendwie hänge ich da gerade ziiiiemlich... :-(


Ciao
- Fraenki
 
Prüfe mal mit
Code:
sockstat -4
ob Deinen Samba-daemons auch dort lauschen, wo sie sollen.

Gruß,

Ice
 
Ich bin mir nicht ganz sicher, ob
interfaces = 192.168.0.0/24 127.0.0.1
so stimmt.
Ich habe in meiner config
Code:
interfaces = 192.168.0.126/24 127.0.0.1
[code]
stehen.
Könnrte sein, dass dadurch die Bindung auf das richtige Interface verloren geht.

Gruß,

Ice
 
Was bindet wo?

Hi,

danke dass ihr euch so viele Gedanken macht :-)

> Ich habe in meiner config
> interfaces = 192.168.0.126/24 127.0.0.1
> stehen.

Ich habe es testweise einmal geändert, brachte allerdings keine Veränderung bei
der Interface-Bindung. Die sieht übrigens nachwievor ganz gut aus:

Code:
[~] (01:28:08) -> sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     smbd       29905 20 tcp4   127.0.0.1:445         *:*
root     smbd       29905 21 tcp4   127.0.0.1:139         *:*
root     smbd       29905 22 tcp4   192.168.0.126:445     *:*
root     smbd       29905 23 tcp4   192.168.0.126:139     *:*
root     nmbd       29895 6  udp4   192.168.0.126:137     *:*
root     nmbd       29895 7  udp4   *:138                 *:*
root     nmbd       29895 8  udp4   192.168.0.126:137     *:*
root     nmbd       29895 9  udp4   192.168.0.126:138     *:*

Also, langsam fange ich an zu zweifeln.... hat vielleicht noch jemand eine Idee,
wie man die Netzwerk-Konfiguration ändern könnte? Mir fällt schlichtweg keine
Alternative zum aktuellen Routing ein...


Ciao
- Fraenki
 
Da fällt mir doch gerade auf, dass...

Code:
...
root     nmbd       29895 7  udp4   *:138                 *:*
...

...nicht dort bindet, wo er es nach meiner Einschätzung tun sollte. Das erklärt dann allerdings auch
folgende Meldungen im Firewall-Log:

Code:
May 21 13:21:57 luzy kernel: ipfw: 65534 Reset UDP [SDSL Server-IP]:138 192.168.0.255:138 out via vr0
May 21 13:21:57 luzy kernel: ipfw: 65534 Reset UDP [SDSL Server-IP]:138 192.168.0.255:138 out via vr0


Ciao
- Fraenki
 
Hast Du schonmal versucht, ob Du auf den Server zugreifen kannst, wenn Dein Client "nur" Mitglied einer Arbeitsgruppe mit dem gleichen Namen wie die Domäne ist?
Wäre sehr interessant zu wissen!

Gruß,

Ice
 
In meiner Konfig habe ich:
Code:
   interfaces = 192.168.0.31 127.0.0.1
   bind interfaces only = yes
und das verdammte Ding macht trotzdem dies hier:
Code:
# sockstat -4 | grep mbd
root     smbd     56186    9 tcp4   127.0.0.1:139         *:*
root     smbd     56186   10 tcp4   192.168.0.31:139      *:*
root     nmbd     56183    8 udp4   *:137                 *:*
root     nmbd     56183    9 udp4   *:138                 *:*
root     nmbd     56183   10 udp4   192.168.0.31:137      *:*
root     nmbd     56183   11 udp4   192.168.0.31:138      *:*
Die Domäne funktioniert trotzdem, daran kann es also nicht liegen.

Kannst du denn auf die Freigaben zugreifen, wenn die Windows-Kiste einer Arbeitsgruppe zugeorndet ist? Dann ließe sich der Fehler schon mal eingrenzen.
 
Also ich glaube ich habe etwas Verwirrung gestiftet bzgl. nmbd ;-) Laut Manpage von smb.conf(5)
ist es ganz normal, dass er sich auf * bindet - er unterscheidet trotzdem noch intern, ob er antwortet
oder nicht:

Code:
              For  name service it causes nmbd to bind to ports 137 and 138 on
              the interfaces listed in the  interfaces  parameter.  nmbd  also
              binds  to  the  "all addresses" interface (0.0.0.0) on ports 137
              and 138 for the purposes of reading broadcast messages. If  this
              option is not set then nmbd will service name requests on all of
              these sockets. If bind interfaces only is  set  then  nmbd  will
              check  the source address of any packets coming in on the broad-
              cast sockets and discard any  that  don't  match  the  broadcast
              addresses of the interfaces in the interfaces parameter list. As
              unicast packets are received on the other sockets it  allowsnmbd
              to  refuse  to  serve  names  to machines that send packets that
              arrive through any interfaces not listed in theinterfaces  list.
              IP  Source  address spoofing does defeat this simple check, how-
              ever, so it must not be used seriously as a security feature for
              nmbd.


> Kannst du denn auf die Freigaben zugreifen, wenn die Windows-Kiste einer
> Arbeitsgruppe zugeorndet ist? Dann ließe sich der Fehler schon mal eingrenzen.

Also mit "net use...", ja? Ich versuche es mal, allerdings ist mir die Syntax nicht (mehr)
ganz geläufig. Ist doch schon wieder ein bisschen länger her...


Ciao
- Fraenki
 
Wenn Deine Domäne den gleichen Namen hat, dann solltest Du die shares sogar in der Netzwerkumgebung sehen können, bzw. im Explorer in der Adressleiste mal
Code:
\\SERVERNAME
oder
\\SERVER-IP
eingeben.

nmbd ist ja "nur" der Namensdienst. Das sollte also definitiv nicht das Problem sein.

Gruß,

Ice
 
Oh nein, ich dreh gleich durch! Die Lösung ist so einfach :-( Ich habe vor einigen Tagen
ein paar Veränderungen am lokalen tinydns vorgenommen und u.a. auch die Hostnamen des
Servers, der Office-Rechner, etc. auf eine andere DE-Domain umgezogen....

Nachdem ich jetzt die Tips von Ice und p.h. ausprobiert habe, hat Windows noch immer behauptet,
"Der angegebene Netzwerkname ist nicht mehr verfuegbar."... und das bei den trivialsten Sachen,
da hat es dann KLICK gemacht... jetzt habe ich die Forward- und Reverse-Einträge im DNS gefixed
und schon kann ich auch wieder Mitglied in der Domäne sein, Freigaben aufrufen, etc... *ARGL*
Also *ganz* genau weiss ich jetzt nicht, welcher DNS-Eintrag das jetzt gefixed hat.. es war jedoch GANZ
SICHER einer von denen...

Sorry, falls jemand sowas schon vermutet hatte, aber nicht mit einem lokalen DNS-Server
gerechnet hat... ich habe das nicht absichtlich verheimlicht. Ich dachte es hätte nix
damit zu tun, Windows hat doch "sein" NETBIOS für "sowas" ;-)

Ach ja, noch eine Anmerkung: ich habe ja behauptet, dass ich, wenn ich dem Windows-Client eine
IP aus dem S-DSL Netz gebe, auf die Domäne Zugriff habe. Das hat sich als falsch herausgestellt.
Ich habe es noch einmal getestet, bevor ich die Lösung fand: Zwar erhielt ich dann die
Passwortabfrage zum Beitritt in die Domäne (was mit RFC-IP nicht gelang), allerdings
schlug dies nach ein paar Minuten ebenfalls mit der o.g. Windows-Fehlermeldung fehl...
das hätte ich genauer testen müssen.

Jedenfalls noch ein GANZ GROSSES Dankeschön an alle, die sich hierzu Gedanken
gemacht haben. Ihr habt mir wirklich die entscheidenden Hinweise gegeben... da hat
meine innere Stimme diesmal doch sehr versagt ;-)


Ciao
- Fraenki
 
Last edited:
Also es gab jetzt noch immer das ein oder andere Problemchen, was ich durch die Erweiterung
des folgende Eintrages um mein S-DSL Netz beheben konnt:

Code:
socket address = 192.168.0.126
interfaces = 192.168.0.0/24 127.0.0.1
bind interfaces only = yes
hosts allow = 192.168.0. localhost [S-DSL Netz]/29

Ganz schön seltsam wie sich das entwickelt hat, aber letztendlich ergibt es einen Sinn...


Ciao
- Fraenki
 
Seltsam...

Hi,

also nachdem es jetzt so aussah, als würde alles (wieder) funktionieren, musste
ich leider feststellen, dass Logins sowie Zugriffe auf die Domäne über z.B. die Netzwerkumgebung
oder "net use" sporadisch fehlschlagen. Eine Ursache hierfür konnte ich noch nicht
ausmachen...

Fällt euch dazu noch etwas ein?


Danke
- Fraenki
 
Und es geht weiter...

So, nach weiteren Recherchen habe ich jetzt den Eintrag "wins support = yes" in die
smb.conf eingetragen und außerdem folgendes in die dhcpd.conf meines ISC-DHCPD
eingetragen:

Code:
        option netbios-name-servers 192.168.0.126;
        option netbios-dd-server 192.168.0.126;
        option netbios-node-type 8;
        option domain-name OFFICE;

Naja, und was soll ich sagen? Bisher funktioniert es mit WINS-Unterstützung sehr sehr gut.
Mich wundert nur, dass ich die ganzen zusätzlichen Einträge für Interface-Bindung, WINS-Server,
etc. früher nicht brauchte...


Ciao
- Fraenki
 
Back
Top