Я работаю над сетью, как описано ниже - BT HomeHub 5 и расширитель WiFi Netgear EX6150. В сети есть и другие точки, хотя я их не указал для краткости, и все розовые пунктирные линии - это WiFi.
Проблема, которую я вижу, заключается в том, что ПК 1не могу(не будет) общаться с ПК 2, но мой телефонволя. Конечно, мой телефон может подключаться к ретранслятору напрямую, и в настоящее время я не могу исключить, что это играет здесь какую-то роль.
Та же ситуация возникает, когда ПК 1 пытается связаться с другими хостами через расширитель WiFi.
Все хосты имеют доступ к интернету.
Я обнаружил, что удлинитель будет "манге" MAC-адреса, но я не совсем могу разобратьсяпочему. Например, MAC-адрес ПК 2 — 88:b1:11:f4:e0:66, но интерфейс маршрутизатора (и хосты, подключенные к маршрутизатору) будут видеть его как 02:0f:b5:f4:e0:66. В разделе «Введение» есть ужасно написанный разделруководствонастраница 33, и, похоже, нет способа отключить это. Я не вижу никаких технических причин для этого, и в настоящее время я делаю ставку на то, что это является ключевой частью проблемы.
Пришло время для технических подробностей.
- ПК 1 — это
192.168.1.74/1c:3e:84:c8:0c:08(согласно данным ОС) - ПК 2 — это
192.168.1.16/88:b1:11:f4:e0:66(согласно данным ОС)
Мой телефон будет с радостью сканировать сеть (используяФинг), обнаружить хост и выполнить пингование... как упоминалось ранее, ПК 1 этого не сделает.
Я попробовал вручную добавить адресную информацию ПК 2 в таблицу ARP ПК 1:
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>
Так что это явно нетолькопроблема ARP.
Глядя на это с точки зрения ПК 2, я сделал следующее tcpdump:
$ 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
Перед эхо-запросом ICMP его нет who-has, поскольку мы составили его вручную... но ПК 2 явно отвечает эхо-ответом 1c:3e:84:c8:0c:08после успешного запроса ARP — это хорошо, — а вот ПК 1 утверждает, что никогда его не получал.
Кроме того, после пинга в таблице ARP ПК 2 есть адрес ПК 1 (ранее я его удалил):
$ arp -n
Address HWtype HWaddress Flags Mask Iface
...
192.168.1.74 ether 1c:3e:84:c8:0c:08 C wlp3s0
...
Повторный пинг с помощью Wireshark на ПК 1 и tcpdumpПК 2 выявил следующее (см. дампы ниже):
- Трафик с ПК 1 → ПК 2, похоже, в порядке.
- Нет никаких изменений MAC источника
- Трафик от ПК 2 → ПК 1 принимается только в том случае, если это широковещательная передача (например, запрос ARP)
- ТамявляетсяMAC-подделка источника
ПК 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
ПК 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
Если я изменю направление (ПК 2 отправит эхо-запросы на ПК 1), то ПК 1 никогда не увидит запрос.
Отключение брандмауэра Windows не помогает.
В крайнем случае, подключение ПК 1 к маршрутизатору через Ethernet решает проблему... однако в настоящее время это решение неприемлемо.
Кто-нибудь может помочь?