Hi@all

Ich habe bei uns ein Problem mit dem zeroconf entdeckt, das ich aber absolut nicht kapiere.

Ich hab ein paar MAC-Rechner in einem Klasse-C Subnetz (192.168.0.0/24)

Wenn ich jetzt einen von diesen MAC-Rechnern eine zeroconf Adresse zuweisen lasse (z.B. 169.254.62.209/16), dann kann dieser auf die MAC-Rechner im Klasse-C Subnet zugreifen und umgedreht.

Das dürfte eigentlich garnicht sein, weil das zwei verschiedene Subnetze sind und auch nicht geroutet werden.

Ich hab zum Test auch einemal einen Win Vista PC eine APIPA Adresse zuweisen lassen. Dieser kann wie erwartet nicht auf das Klasse-C Subnet zugreifen.

Hat irgendjmd eine Idee oder hab ich irgendwo einen Denkfehler? :confused:

[...]dann kann dieser auf die MAC-Rechner im Klasse-C Subnet zugreifen und umgedreht.

Was heißt "zugreifen"? Welches Protokoll?

Hi@flashpixx

zugreifen heisst, der Zugriff auf jegliche offenen Ports/Dienste der Hosts.

z.B. ICMP, SMB usw..

Ich habe zudem den ARP-Cache geleert und den traffic auf dem "zeroconf-MAC" mitgeschnitten während ich einen icmp-request (ping) geschickt habe.

Es gibt ein paar Multicasts aus dem ClassC Netz und der "zeroconf-MAC" löst, als gäbe es keine Subnetze, die Class C IP mittels ARP auf, schickt das icmp-request Paket und erhält als Antwort ein icmp-reply.

Ich hab zudem zuvor den bonhour-browsing Dienst (mDNSresponder) deaktiviert, weil ich dem Ding einfach nicht traue.

Ich bin jetzt kein ZeroConf Spezialist. Habe bei mir die Kombi aus Mac Rechnern und Linux laufen, wobei ich eben es nutze um die Samba / Itunes (DAAP) Shares zu verteilen.

Also bei mir kann ich zwar das Share sehen, wenn ich eine Zeroconf Adresse habe, aber ich kann nicht drauf zu greifen. Ich schaue gerne mal mit Wireshark im Detail nach, wenn Du mir einmal sagst, was Du genau für Infos brauchst

Kleiner Hinweis zur Fehlersuche:

Grundsätzlich können Rechner in verschiedenen Subnetzen ohne Router nicht kommunizieren. Also sind wohl beide Rechnert entweder irgendwie doch im selben Subnetz, oder es Routet wer - das wäre aber relativ unwahrscheinlich

- Sind beide Rechner im wirklich im selben IP-Subnetz (eine Netzschnittstelle kann auch mehrere IPs haben!)?

- die Frage von Flashpixx wurde noch nicht ganz beantwortet: Schon mal an IPv6 gedacht? Wie greifst Du auf den anderen Host zu (Name/Netzwerkumgebung oder IP)?

Ich tippe auf IPv6

Grüße

Ripper

Ich habe mir eine Testumgebung aufgebaut um den Problem auf die Spur zu kommen.

Ein Mac OS X Rechner und ein Windows Vista Rechner an einem ISO/OSI Layer2 Switch.

Auf beiden Rechnern ist ausschließlich IPv4 aktiviert.

Mac OS X mit zeroconf Adresse (169.254.62.209/16)

Windows Vista Rechner mit irgendeiner IP in einem anderen Subnet.

Der MAC Rechner kann weiterhin auf den Windows Rechner zugreifen, egal in welchem Subnet und mit welcher IP der Windows Rechner adressiert ist. Ebenso kann der Windows Rechner auf den MAC Rechner mit der zeroconf-Adresse zugreifen.

Drehe ich den Spieß um, d.h. der Windows Rechner bekommt eine zeroconf(APIPA) und der MAC Rechner z.b. eine Class C Adresse können sich beide Rechner nicht mehr sehen, wie es auch sein sollte.

Da kein Routing zwischen den Subnets stattfindet, darf der Zugriff nur jeweils im eigenen Subnet funktionieren und nicht Subnet-übergreifend.

Der Zugriff erfolgt stets per IP-Adresse und nicht per NetBios-Name/ Netzwerkumgebung.

Auf beiden Rechnern ist jeweils nur eine IP-Adresse an der NIC aktiv. (abgesehen von den Multicast Adressen)

@flashpixx

Es wäre interessant ob du ohne Router ebenfalls aus dem zeroconf subnet auf die anderen Mac's und den Linux Rechner zugreifen kannst, solang diese in einem anderen Subnet, in Bezug auf das zeroconf Subnet, stehen.

Subnetze:

zeroconf:

Netzwerkbasisadr.: 169.254.0.0

Subentmaske: 255.255.0.0

Broadcast: 169.254.255.255

Class C:

Netzwerkbasisadr.: 192.168.0.0

Subnetmaske: 255.255.255.0

Broadcast: 192.168.0.255

Bearbeitet 20. Juli 201015 j von richidd

Poste doch einfach mal die Ausgabe von "ifconfig" auffm Mac und "ipconfig /all" unter Windows und die Ausgabe von "route -n" bzw. "route print"..

Grüße

Ripper

Windows PC:

Windows-IP-Konfiguration

Hostname . . . . . . . . . . . . : Mobile

Prim‰res DNS-Suffix . . . . . . . :

Knotentyp . . . . . . . . . . . . : Hybrid

IP-Routing aktiviert . . . . . . : Nein

WINS-Proxy aktiviert . . . . . . : Nein

DNS-Suffixsuchliste . . . . . . . :

Ethernet-Adapter LAN-Verbindung:

Verbindungsspezifisches DNS-Suffix:

Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8039 PCI-E Fast Ethernet Controller

Physikalische Adresse . . . . . . : ##-##-##-##-##-##

DHCP aktiviert. . . . . . . . . . : Nein

Autokonfiguration aktiviert . . . : Ja

IPv4-Adresse . . . . . . . . . . : 192.168.0.2(Bevorzugt)

Subnetzmaske . . . . . . . . . . : 255.255.255.0

Standardgateway . . . . . . . . . : 192.168.0.1

NetBIOS ¸ber TCP/IP . . . . . . . : Aktiviert

Ping wird ausgef¸hrt f¸r 169.254.90.3 mit 32 Bytes Daten:

Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255

Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255

Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255

Antwort von 169.254.90.3: Bytes=32 Zeit<1ms TTL=255

Ping-Statistik f¸r 169.254.90.3:

Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),

Ca. Zeitangaben in Millisek.:

Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

IPv4-Routentabelle

===========================================================================

Aktive Routen:

Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik

0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.2 276

127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306

127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306

127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306

192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.2 276

192.168.0.2 255.255.255.255 Auf Verbindung 192.168.0.2 276

192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.2 276

224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306

224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.2 276

255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306

255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.2 276

===========================================================================

St‰ndige Routen:

Netzwerkadresse Netzmaske Gatewayadresse Metrik

0.0.0.0 0.0.0.0 192.168.0.1 Standard

===========================================================================

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MAC - Rechner

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

inet 169.254.90.3 netmask 0xffff0000 broadcast 169.254.255.255

ether ##:##:##:##:##:##

media: autoselect (1000baseT <full-duplex,flow-control>) status: active

supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,flow-control> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,flow-control> 100baseTX <full-duplex,hw-loopback> 1000baseT <full-duplex> 1000baseT <full-duplex,flow-control> 1000baseT <full-duplex,hw-loopback>

PING 192.168.0.2 (192.168.0.2): 56 data bytes

64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.895 ms

64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.703 ms

64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.556 ms

64 bytes from 192.168.0.2: icmp_seq=3 ttl=128 time=0.623 ms

^C

--- 192.168.0.2 ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/avg/max/stddev = 0.556/0.694/0.895/0.127 ms

#route -nv get 192.168.0.2

u: inet 192.168.0.2; u: link ; RTM_GET: Report Metrics: len 128, pid: 0, seq 1, errno 0, flags:<UP,GATEWAY,HOST,STATIC>

locks: inits:

sockaddrs: <DST,IFP>

192.168.0.2

route to: 192.168.0.2

destination: 192.168.0.2

interface: en0

flags: <UP,HOST,DONE,LLINFO,WASCLONED>

recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire

0 0 0 0 0 0 1500 1200

locks: inits:

sockaddrs: <DST,GATEWAY,IFP,IFA>

192.168.0.2 ##.##.##.##.##.## en0:##.##.##.##.##.## 169.254.90.3

Sehr interessant - beim Traceroute taucht nicht zufällig das Standardgateway irgendwie auf?

Der Windowsrechner hat die Firewall oben? Wie reagiert er auf ICMP-Redirects?

Ohne Router zu jeweiligen anderen Netz sollte da wirklich nix rübergehen.

Grüße

Ripper

Nein, den Standardgateway-Eintrag unter Windows hätt ich auch weglassen können. Die beiden Rechner sind allein an einem Switch. Da gibt es keine weiteren Netzwerkendgeräte bzw. -knoten. Die Windows und MAC Firewall ist down. Sonst hätte die einiges dicht gemacht und mich bei der Analyse nur behindert.