Назад | Перейти на главную страницу

Странное поведение маршрутизации между 2 подсетями

У меня две подсети, и маршрутизация работает так: Клиент A может пинговать (ICMP) Клиент B
Клиент B не может проверить связь (ICMP) Клиент A

Маршрутов нет вручную настроен в точке доступа (Google Wi-Fi Wlan Router - не имеет большого количества опций, не говоря уже о таблицах маршрутизации) в подсети A, и между ними есть только неуправляемые коммутаторы.

Единственное, что связано с обеими подсетями, - это Брандмауэр Sonicwall но я не знаю, проходит ли через это трафик? Потому что технически между подсетями существует более прямой маршрут.

На обоих устройствах нет клиентского брандмауэра. На самом деле я совершенно уверен, что это не имеет никакого отношения к клиентам (одинаковое поведение для разных клиентов)

Шлюз по умолчанию в подсети A - это точка доступа Google Wifi. В подсети B шлюзом по умолчанию является сервер Windows (на котором установлен DHCP-сервер).

Мои вопросы:

  1. Почему клиент A может пинговать клиента B, а не наоборот?
  2. Где мне искать, если я хочу найти плохо настроенное правило маршрутизации?
  3. Как я могу добиться, чтобы маршрутизация работала между всеми клиентами из подсети A и B?

Во-первых, 192.168.15.0/21 (255.255.248.0) неправильный способ называть эту сеть, на самом деле это 192.168.8.0/21 (255.255.248.0), в диапазоне от 192.168.8.0 до 192.168.15.255.

Во-вторых, между двумя подсетями нет реальной безопасности, если они находятся на одном коммутаторе / VLAN на коммутаторе, как показано на вашей схеме, или если точка доступа Wi-Fi в подсети A просто падает в коммутатор в подсети B от точки доступа. порт, который не настроен для работы в другой VLAN.

Если на любом клиентском устройстве вы добавите маршрут с нулевой метрикой для подсети B в подсети A и сделаете обратное для подсети B (добавите маршрут с нулевой метрикой для подсети A в подсети B), системы будут считать себя подключенными к обе сети. Трафик из этой системы в другую подсеть будет просто использовать ARP и отправлять напрямую в другую подсеть, минуя любые устройства уровня 3 (маршрутизаторы, межсетевые экраны 13) и взаимодействуя напрямую.

Например, если на хосте linux в подсети B вы сделали что-то вроде: 

ip route add 192.168.86.0/24 metric 0 dev eth0
The linux host would try to send packets directly to nodes on subnet A by ARPing. Obviously if you are depending on the firewall or routers to provide some sort of security between the two subnets this would defeat it.

Теперь, когда это решено, это довольно простая проблема IP-маршрутизации. Вам нужен маршрут на шлюзе по умолчанию для подсети A, который указывает на действительный шлюз для 192.168.86.0/24 (подсеть B). Вам нужен маршрут на шлюзе по умолчанию для подсети B, который указывает на действительный шлюз для 192.168.8.0/21 (подсеть A). Допустимый шлюз - это маршрутизатор, доступный напрямую от исходного маршрутизатора / шлюза, который знает, как добраться до сети назначения, либо имея маршрут следующего перехода, либо напрямую подключаясь к сети назначения.

Как только это будет установлено, вы должны убедиться, что никакие брандмауэры не блокируют трафик между подсетями. Брандмауэр Windows по умолчанию имеет довольно строгие правила. Если он включен, он почти наверняка каким-то образом блокирует трафик между двумя подсетями. Если точка доступа в подсети B находится на уровне 3 (например, порт VLAN, а не просто другой порт коммутатора), то ее брандмауэр (при условии, что он у него есть) также может блокировать трафик.

В целом, вы можете взглянуть на эту сетевую архитектуру и придумать что-нибудь более разумное. Например, у вас, скорее всего, должен быть маршрутизатор в центре, а не просто коммутатор. Если это коммутатор l3, вы можете просто разделить порты на разные VLAN и заставить коммутатор действовать как основной маршрутизатор между двумя подсетями, избавиться от падения с точки доступа в подсеть A и позволить маршрутизатору выполнять маршрутизацию.

Ах, значит, точка доступа Google является многосетевой и находится в обеих подсетях. Из вашего описания похоже, что AP предоставляет NAT для всего в подсети A. Если это так, вам придется добавить маршрут либо на сервере Windows, либо на sonicwall (я предполагаю, что это gw по умолчанию для окон сервер). Маршрут по существу отправит все, что связано с подсетью A, на адрес подсети B точки доступа Google.