Малый бизнес имеет внутреннюю сеть Windows в одной подсети 192.168.16.x. Существует брандмауэр Watchguard XTM 330, который направляет трафик в Интернет. Выделенная линия.
У некоторых пользователей периодически возникают проблемы с доступом к внутреннему веб-приложению. Когда это происходит, пинг по адресу внутреннего веб-сервера (который является адресом 192.168.16.x) дает следующий результат:
Pinging [local server name] [192.168.16.x] with 32 bytes of data:
Reply from 192.168.20.1: Destination host unreachable.
Reply from 192.168.20.1: Destination host unreachable.
Reply from 192.168.20.1: Destination host unreachable.
Reply from 192.168.20.1: Destination host unreachable.
Подсеть 192.168.20.x не используется что мы знаем о так что это загадка.
ipconfig / all сообщает правильный шлюз по умолчанию: 192.168.16.1 (внутренний IP-адрес XTM).
Еще одно: мы также попробовали tracert на 192.168.20.1 с пораженных машин. В одном случае мы получили это:
Tracing route to 192.168.20.1 over a maximum of 30 hops
1 4 ms 6 ms 6 ms 192.168.16.1
2 7 ms 8 ms 7 ms [public IP address of XTM]
3 * 5 ms 2 ms 192.168.20.1
Другими словами, tracert отправился к XTM, а затем к таинственному серверу и получил ответ.
В других случаях (та же внутренняя сеть) мы получили это, чего я ожидал:
Tracing route to 192.168.20.1 over a maximum of 30 hops
1 4 ms 3 ms 8 ms 192.168.16.1
2 5 ms 8 ms 6 ms [public IP address of XTM]
3 [public IP address of XTM] reports: Destination net unreachable.
Я озадачен таким поведением и приветствую предложения по устранению неполадок.
PS:
Routes
------------
Route Table: main
-------------------
default via [public IP].57 dev eth0 metric 5
10.0.6.0/24 dev eth6 proto kernel scope link
[public IP].72/29 dev eth0 proto kernel scope link
[public IP].56/29 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
172.20.10.12 dev eth0 scope link metric 1
192.168.16.0/24 dev eth1 proto kernel scope link
::1/128 via :: dev lo
Route Table: eth0.out
-------------------
default via [public IP].57 dev eth0 metric 1
[public IP].56/29 dev eth0 scope link metric 1
Оказывается, именно это и происходит, если кто-то подключает маршрутизатор ADSL к сети, чтобы использовать его в качестве коммутатора для увеличения количества доступных портов Ethernet. DHCP был отключен на маршрутизаторе, но он все еще периодически пытался маршрутизировать трафик через свой (отключенный) порт WAN. Никто не понял, что это маршрутизатор, а не просто коммутатор. 192.168.20.1 был важной подсказкой, но arp был ключевым инструментом для устранения неполадок.
Watchguard работал нормально.
Тим