Пинг работает, но TCP не в какой-то необычной топологии

Ваша сеть работает как положено. Давайте нарисуем это:

Я уверен, что это упрощение, но здесь достаточно информации, чтобы показать проблему и различные исправления (и их недостатки).

Предположения

• Каждое устройство использует IP-адрес брандмауэра локальной сети в качестве шлюза по умолчанию.
• DNS не важен
• Все сетевые маски в этом примере /24
• Две топологии ЛВС были заданы как VLAN. Я оставил это пока, и мы представляем каждую VLAN как отдельную физическую локальную сеть.
• Исправления предполагают, что вы можете управлять правилами на всех трех маршрутизаторах / брандмауэрах

Для тех, кто следует за стеком OSI, это все IP и находится на уровне 3.

1. Непосредственно связанные сети

У вашего ПК есть пакет для отправки на IP. Сначала он проверяет, находится ли IP-адрес назначения в той же локальной IP-сети. Если адреса SRC и DST совместно используют одну и ту же сеть (будучи битом IP, который остается после применения маски подсети), то ОС отправляет пакет через интерфейс Ethernet. ОС помечает исходящий пакет исходным IP-адресом интерфейса, на котором он выходит.

Ваш тестовый ПК отправляет пакеты с IP-адресом SRC, равным 192.168.5.172. Пункт назначения - 192.168.5.250. Маска вашей сети - /24, равная 255.255.255.0, из сети 192.168.5.x. Следовательно, ваш ПК может отправлять напрямую, передавая пакет из Ethernet и пункт назначения получит его.

2. Шлюзы по умолчанию

Шлюз по умолчанию, маршрут по умолчанию, шлюз, маршрутизатор последней инстанции - это то, на что вы отправляете пакеты, когда у вас нет лучшего маршрута для их отправки.

Вот маршруты по умолчанию в вашей сети:

Таким образом, если IP-адрес назначения не является локальным (напрямую подключенным), тогда TestPC знает, как адресовать пакет через шлюз по умолчанию.

Для устройства существует только один IP-адрес шлюза по умолчанию (рукопожатие - да, я стараюсь сделать его простым).

(комментарий на стороне) Если в окне VyOS задан шлюз по умолчанию, это, вероятно, через ваш офисный Juniper. Это хорошо для обновлений и прочего, но не относится к вашей среде. Для VyOS также вполне разумно вообще не настраивать шлюз по умолчанию.

3. Конкретные маршруты

Ваш след от вопроса указывает, что два офисных брандмауэра имеют определенные знания о другой локальной сети.

Таким образом, для каждого брандмауэра будет настроен дополнительный маршрут.

Ваша компания Juniper знает, как "получить доступ к 192.168.1.0/24 через 192.168.5.34"

Их брандмауэр знает, что "192.168.5.0 255.255.255.0 через 192.168.1.34" или подобное. Наглядно это означает:

4. Будьте едины с пакетом

Итак, давайте представим это с точки зрения пакета.

а. TestPC пингует Google (я использую ping, потому что он не содержит состояний и проще, чем объяснение TCP-соединения, такого как HTTP)

1. Пакет для 8.8.8.8 Это не в 192.168.5.x, поэтому test PC выбрасывает его в Ethernet с DST 192.168.5.1
2. Juniper получает пакет с SRC 192.168.5.172 и DST 8.8.8.8. Он настроен на NAT и передает этот пакет. Адрес SRC перезаписывается на внешний IP-адрес Inet на можжевельнике и передается провайдеру. Можжевельник отслеживает это соединение в таблице в памяти.
3. Пакет отправляется в Google, а через ISP возвращается ответ с SRC 8.8.8.8 и DST от Inet IP
4. Juniper просматривает таблицу отслеживания соединений и обнаруживает, что это ответ на соединение, запущенное TestPC. Таким образом, он изменяет DST на 192.168.5.172 и передает этот пакет на интерфейс LAN (потому что это интерфейс, который напрямую подключен к 192.168.5.x
5. TestPC слышит пакет для своего IP-адреса и захватывает его с провода (подробнее здесь)

Это как изображение:

б. TestPC теперь пингует сервер клиента по адресу 192.168.1.28.

1. Как и выше, testPC не имеет прямого соединения с 192.168.1.x, поэтому он направляет пакет на шлюз по умолчанию, Juniper.
2. Juniper сконфигурирован для пересылки пакетов, но имеет статический маршрут до 192.168.1.x через VyOS в 192.168.5.34. Поэтому вместо использования NAT для изменения места назначения на шлюз ISP, Juniper пересылает пакет через VyOS.
3. VyOS знает только о двух сетях. Он видит пакет в одну сторону для другой стороны и просто пересылает его на другой интерфейс
4. CustyServer видит пакет и получает его. Наполовину!
5. CustyServer отправляет ответ на 192.168.5.172, но он не подключен напрямую, поэтому мы переходим к шлюзу по умолчанию.
6. У отвратительного брандмауэра НЕТ ИДЕИ, что делать с этим пакетом, так что он, вероятно, отбрасывается или может быть перенаправлен своему провайдеру, который затем отбрасывает его.
7. На этом все кончено. Пакет ответа теряется, и TestPC будет ждать до истечения времени ожидания ответа.

Вот это последнее как изображение:

Как мы это исправим? Есть несколько разных исправлений.

1. Соединительная сеть

Это "правильная" конструкция, использующая небольшую межсетевую сеть между двумя межсетевыми экранами и избавляющуюся от устройства VyOS. Я использовал 172.22.22.x/24 в качестве локальной сети. А /24 довольно большой, но держится так просто.

Положительных

1. Каждый брандмауэр знает обо всем трафике и может правильно отслеживаться.
2. Одно устройство в каждой компании для смены брандмауэра, а не два места для проверки
3. Каждое устройство локальной сети имеет простейшую настройку.

Недостатки

1. Для обоих устройств брандмауэра потребуется дополнительный интерфейс Ethernet, и между ними проходит кабель Ethernet.

2. Добавить статический маршрут на межсетевой экран Заказчика.

Кажется, отсутствует. Если вы добавите синюю стрелку из Customer Firewall в VyOS, то это будет работать лучше.

3. Добавьте SOURCE NAT на устройство VyOS

Кто-то известный однажды сказал: "Если ваш план предусматривает добавление большего количества слоев NAT, тогда вы не понимаете проблему с корнем". Я не думаю, что это хорошая идея.

Если устройство VyOS NATs весь трафик между двумя сетями к своему собственному IP в этой локальной сети, то ответный трафик не будет пытаться перейти на шлюз по умолчанию.

Основным недостатком является то, что вы будете видеть весь трафик, поступающий с IP-адреса VyOS, и вы не будете знать, кто является настоящим отправителем. Это делает судебную экспертизу несколько более сложной.

4. Статический маршрут всех вещей!

Это ужасный ответ, но в некоторых ситуациях это может быть уместно.

Если бы каждое устройство локальной сети имело такую ​​таблицу маршрутизации, то все они знали бы, как общаться с загруженной локальной сетью.

# ip ro ls
по умолчанию через 192.168.5.1 dev eth0
192.168.1.0/24 через 192.168.5.34 dev eth0
192.168.5.0/24 dev eth0 Прото ядро ​​link ссылка src 192.168.5.173

Недостатком является управленческий кошмар. Это может быть работоспособно, если у вас есть только пара устройств, которые никогда не перемещаются, но их динамическое добавление является грязным.

Возможные сохранения

1. Active Directory может выдвигать статические маршруты с помощью групповой политики. Не поможет ни одно устройство, которое не присоединено к домену. Принтеры, телефоны, точки доступа, все остальное не хватает. Это все, что я знаю об этом.
2. Возможно выдвинуть статический маршрут с DHCP, но большинство реализаций игнорирует предложение. pfSense может это сделать, но windows10 проигнорировал эту опцию.

В итоге

Карты LAN - это отличные решения для понимания вашей сетевой проблемы. Люблю их! Я использовал http://www.gliffy.com/ для создания фонового изображения для этих иллюстраций.

ПОЦЕЛУЙ Если решение утомительно и сложно, это, вероятно, неправильное решение.