richidd Geschrieben 14. Juli 2010 Geschrieben 14. Juli 2010 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: Zitieren
flashpixx Geschrieben 14. Juli 2010 Geschrieben 14. Juli 2010 [...]dann kann dieser auf die MAC-Rechner im Klasse-C Subnet zugreifen und umgedreht. Was heißt "zugreifen"? Welches Protokoll? Zitieren
richidd Geschrieben 19. Juli 2010 Autor Geschrieben 19. Juli 2010 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. Zitieren
flashpixx Geschrieben 19. Juli 2010 Geschrieben 19. Juli 2010 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 Zitieren
RipperFox Geschrieben 20. Juli 2010 Geschrieben 20. Juli 2010 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 Zitieren
richidd Geschrieben 20. Juli 2010 Autor Geschrieben 20. Juli 2010 (bearbeitet) 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 2010 von richidd Zitieren
RipperFox Geschrieben 20. Juli 2010 Geschrieben 20. Juli 2010 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 Zitieren
richidd Geschrieben 20. Juli 2010 Autor Geschrieben 20. Juli 2010 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 Zitieren
RipperFox Geschrieben 20. Juli 2010 Geschrieben 20. Juli 2010 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 Zitieren
richidd Geschrieben 20. Juli 2010 Autor Geschrieben 20. Juli 2010 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. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.