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

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

Сначала скажу, что я не проектировал эту сеть с самого начала, поэтому топология стала неожиданностью даже для меня.

Существует две подсети (одна - наша компания, а другая - наши клиенты), которые находятся в одном физическом месте, и поэтому сети разделены VLAN: s. Однако в дополнение к этому и у нас, и у нашего клиента есть разные брандмауэры, поэтому у нас есть дополнительный виртуальный маршрутизатор (VyOS), который действует как мост между нашими сетями. Маршрутизатор VyOS имеет два интерфейса (eth0 и eth1).

Я могу нормально пинговать обе сети, но если я попытаюсь перейти на веб-сервер наших клиентов в их подсети, соединение не удастся. Что особенно интересно, когда я вручную настраиваю свой шлюз так, чтобы он указывал на 192.168.5.34 (VyOS) вместо нашего шлюза на 192.168.5.1, соединение работает, поэтому в брандмауэре должно быть что-то не так, когда он должен перенаправить трафик обратно из того же интерфейса, откуда он появился. Кроме того, если я настрою исходный код, он также будет работать.

Вот информация о сетях:

наша подсеть: 192.168.5.0/24 firewall: 192.168.5.1 VyOS eth1: 192.168.5.34

подсеть клиента: 192.168.1.0/24 брандмауэр: 192.168.1.1 VyOS eth0: 192.168.1.34

РЕДАКТИРОВАТЬ: это маршрут, по которому проходит трафик, когда я пытаюсь подключиться к веб-серверу через HTTP.

192.168.5.172 -> 192.168.5.1 -> 192.168.5.34 -> 192.168.1.28 | 192.168.1.28 -> 192.168.1.1 (похоже, что здесь, на нашем брандмауэре Juniper, соединение не работает)

Ваша сеть работает должным образом. Нарисуем это:

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

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

  • Каждое устройство использует 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. Таким образом, ваш компьютер может отправлять пакеты напрямую, выводя пакет из сети. Ethernet и адресат получат его.

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

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

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

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

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

(боковой комментарий) Если для 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. Будьте единым целым с пакетом

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

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

  1. Пакет для 8.8.8.8 Этого нет в 192.168.5.x, поэтому testPC бросает его в Ethernet с 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-адреса и снимает его с провода (подробнее здесь)

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

б. 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 в качестве межсоединения LAN. A / 24 довольно большой, но все просто.

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

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

Недостатки

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

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

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

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

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

Если устройство VyOS преобразует весь трафик между двумя сетями через NAT на свой СОБСТВЕННЫЙ 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 proto kernel scope link src 192.168.5.173

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

Возможные сейвы

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

В итоге

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

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