Aşağıda açıklandığı gibi bir ağ üzerinde çalışıyorum - bir BT HomeHub 5 ve bir Netgear EX6150 WiFi genişletici. Ağ üzerinde başka noktalar da var, ancak bunları kısalık olarak bıraktım ve pembe kesikli çizgilerin tümü WiFi.
Görüyorum sorun PC 1 olmasıdır olamaz ( olmaz PC 2 ile iletişim) ama telefonum olacak . Tabii ki telefonum doğrudan genişleticiye bağlanıp doğrudan genişleticiye bağlanabiliyor ve şu anda burada rol oynamaktan mahrum kalamam.
Aynı durum, PC 1'in WiFi genişleticideki diğer ana makinelerle iletişim kurmaya çalıştığını gösterir.
Tüm ev sahiplerinin internete erişimi var.
Genişleticinin MAC adreslerini " tıkatacağını " öğrendim , ancak nedenini tam olarak anlayamadım . Örneğin, PC 2’nin MAC adresi 88:b1:11:f4:e0:66, ancak yönlendiricinin arayüzü (ve yönlendiriciye bağlı olan ana bilgisayarlar), iletişim kurduklarını görecektir 02:0f:b5:f4:e0:66. Bir korkunç yazılı bölümü bulunmaktadır kılavuzda üzerinde sayfa 33 ve bunu kapatmak için bir yol olacaksa görünmüyor. Bunun için herhangi bir teknik sebep göremiyorum ve şu anda konunun kilit bir parçası olduğuna dair bahsimi yapıyorum.
Teknik bit zamanı.
- PC 1
192.168.1.74/1c:3e:84:c8:0c:08(işletim sistemi tarafından rapor edildiği gibi) - PC 2
192.168.1.16/88:b1:11:f4:e0:66(işletim sistemi tarafından rapor edildiği gibi)
Telefonum ağı neşeyle tarayacak ( Fing kullanarak ), ana bilgisayarı keşfedecek ve ping ... daha önce de belirtildiği gibi, PC 1 çalışmayacak.
PC 2'nin adres bilgilerini PC 1'in ARP tablosuna elle eklemeyi denedim:
C:\WINDOWS\system32>netsh interface ip add neighbors 14 192.168.1.16 02-0f-b5-f4-e0-66
C:\WINDOWS\system32>arp -a
Interface: 192.168.1.74 --- 0xe
Internet Address Physical Address Type
...
192.168.1.16 02-0f-b5-f4-e0-66 static
...
C:\WINDOWS\system32>ping 192.168.1.16
Pinging 192.168.1.16 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.1.16:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\WINDOWS\system32>
Yani bu açıkça değil sadece bir ARP sorunu.
Buna PC 2’nin bakış açısıyla baktığımda, tcpdumpping sırasında bir tane aldım :
$ tcpdump -enr dump.cap
11:37:45.730405 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1317, length 40
11:37:45.730468 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
11:37:45.764667 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
11:37:45.764678 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1317, length 40
who-hasICMP yankı isteğinden önce bir şey yok , bunu elle yaptığımız gibi ... ama PC 2 1c:3e:84:c8:0c:08, başarılı bir ARP sorgusunun ardından gelen bir yankı yanıtıyla açıkça yanıt veriyor - iyi şeyler - ancak PC 1 bunu asla almadığını iddia ediyor.
Ayrıca, ping işleminden sonra, PC 2'nin ARP tablosunda PC 1 adresi var (daha önce kaldırdım):
$ arp -n
Address HWtype HWaddress Flags Mask Iface
...
192.168.1.74 ether 1c:3e:84:c8:0c:08 C wlp3s0
...
PC 1 ve tcpdumpPC 2'de Wireshark ile ping işlemi yapılması aşağıdakileri ortaya çıkarır (çöplükler için aşağıya bakın):
- PC'den gelen trafik 1 → PC 2'nin durumu iyi görünüyor
- Kaynağın MAC mungingi yok
- PC 2'den gelen trafik → PC 1 yalnızca bir yayınsa alınır (örneğin: ARP isteği)
- Orada olan kaynağın MAC munging
PC 1
$ tcpdump -enr pc1_dump4.cap
reading from file pc1_dump4.cap, link-type EN10MB (Ethernet)
12:17:59.525610 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40
12:17:59.641049 02:0f:b5:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
12:17:59.641080 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
12:18:04.345340 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40
12:18:09.346886 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40
12:18:14.347539 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40
PC 2
$ tcpdump -enr pc2_dump4.cap
reading from file dump4.cap, link-type EN10MB (Ethernet)
12:18:02.206931 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40
12:18:02.206995 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
12:18:02.289242 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
12:18:02.289254 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1330, length 40
12:18:07.122444 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40
12:18:07.122484 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1331, length 40
12:18:12.037691 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40
12:18:12.037729 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1332, length 40
12:18:17.170982 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40
12:18:17.171025 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1333, length 40
Yönü tersine çevirirsem (PC 2 PC 1'e eko istekleri gönderir), o zaman PC 1 isteği asla görmez.
Windows güvenlik duvarını devre dışı bırakmak yardımcı olmaz.
Son çare olarak, PC 1'i yönlendiriciye Ethernet ile bağlamak sorunu çözdü ... ancak bu şu anda kabul edilebilir bir çözüm değil.
Biri yardım edebilir mi?