VPN Сайт - Сайт + Дорожный Воин

Неудивительно, похоже, что что-то не так с вашей конфигурацией. Когда вы покажете её или точно опишете кому-то другому, возможно, получите полезный совет. И да, вам нужны правильные маршруты. Если клиенты RW получают адреса из другой подсети, тогда всему необходимы маршруты к ней. Если ваши VPN-соединения между сайтами основаны на политике IPSec, их политики должны включать все комбинации источников и получателей, которые должны передаваться через них.

Ты когда-нибудь это делал? Можешь объяснить, как ты это сделал?

Конечно. В противном случае я бы не говорил об этом. Один из моих текущих сетапов выглядит так: https://app.diagrams.net/#Uhttps%3A%2F%2Fdrive.google.com%2Fuc%3Fid%3D1pqnKtG0pdkHpXwzonfnEBs0z8L3UmKhJ%26export%3­Ddownload https://drive.google.com/file/d/1pqnKtG0pdkHpXwzonfnEBs0z8L3UmKhJ/view?usp=sharing. Я указал только конфигурацию, касающуюся этого EoIP/IPsec. Я не включил конфигурацию, относящуюся к LAN или управленческим сетям, а также IPsec, связанный с сайтом «P» (это просто обычная конфигурация, соответствующая требованиям Cisco, и она скоро будет заменена другим EoIP, когда я получу больше микротиков). Обратите внимание, что каждый сайт требует некоторой «подготовки» — создать Mesh, назначить IP и добавить правило межсетевого экранирования для принятия всего, что приходит из VPN. Затем для каждого туннеля есть соответствующая конфигурация, которая создаст IPsec peer и политику, туннель EoIP, порт для Mesh, правило межсетевого экранирования для исходящих данных и маршрут. Теперь две вещи, которые могут быть трудно понять: почему я использую EoIP, когда это создает дополнительную нагрузку? Да потому что тогда мои политики просты, что позволяет избежать случайной некорректной конфигурации. Все внутренние данные проходят обычный процесс маршрутизации в EoIP или Mesh. Почему Mesh и что это вообще? Еще одна излишняя подготовка. Прямо сейчас я могу отправить данные с сайта «R» на «T», и это просто сработает, потому что Mesh позаботится об этом (я уже делаю это для управленческих сетей). Если объем данных достаточно велик, я просто создам другой туннель напрямую между R-T, чтобы данные не проходили через «C». Кроме того, я могу иметь больше резервных EoIP туннелей (например, резервное мобильное соединение, прямое WLAN и т.д.), и это создаст одну большую L2 сеть. Но почему Mesh, а не мост? Так вот, мосты не любят петли. Они создают топологию дерева покрытий, чтобы предотвратить петли. С Mesh петли не являются проблемой, потому что Mesh выполняет поиск путей и передает данные самым коротким путем. Это идеально? Далеко от этого. Это работает? О, да! ИЗМЕНЕНИЕ 2020-10-12: Ладно, я немного поиграл с этим и понял, что надежность Mesh сильно зависит от функции keep-alive туннелей EoIP. Поэтому в лабораторных условиях это работало отлично, но в реальности может работать не так, как ожидалось. Моя ошибка заключалась в том, что я тестировал резервирование, отключая интерфейсы EoIP. Отключение или изменение текущего состояния приведет к мгновенной реакции, и это отлично работает. Однако проблема заключается в том, что текущее состояние может не измениться мгновенно (зависит от настроек keep-alive, которые по умолчанию составляют 10*10 секунд, и это неприемлемо), если происходит сбой шифрования или физического канала. Я все еще считаю, что есть что-то полезное в наличии простой политики «сайт-на-сайт» для симметричного виртуального интерфейса (GRE/EoIP/IPIP/WireGuard), вместо «простой» политики для всех данных, потому что вы разделяете туннель и маршрутизацию (что делает это менее подверженным ошибкам). Однако я больше не буду утверждать, что это решение непробиваемо или что у него есть мгновенные возможности аварийного переключения. Аварийное переключение все еще происходит, но не мгновенно, и могут быть потери пакетов.