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

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

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

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

• Каждое устройство использует IP-адрес брандмауэра локальной сети в качестве своего шлюз по умолчанию.
• DNS не важен
• В этом примере все маски сети равны / 24
• Две топологии LAN были указаны как сети 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-адрес шлюза по умолчанию (handwave - да, я стараюсь не усложнять.)

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

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

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

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

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

Их межсетевой экран знает, что" 192.168.5.0 255.255.255.0 через 192.168.1.34 "или подобное. Графически это означает:

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

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

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

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

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

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

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

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

---

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

1. Сеть межсоединений

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

Положительные стороны

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

Недостатки

1. Оба устройства межсетевого экрана потребуют дополнительного интерфейса Ethernet, и между ними проложен кабель Ethernet.

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

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

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

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

Если устройство VyOS преобразует весь трафик между двумя сетями через NAT на свой СОБСТВЕННЫЙ IP-адрес в этой локальной сети, ответный трафик не будет пытаться перейти на шлюз по умолчанию.

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

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

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

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

# 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 proto kernel scope link src 192.168.5.173

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

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

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

В итоге

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

KISS Если решение утомительное и сложное, вероятно, это неправильное решение.