История изменений
Исправление upcFrost, (текущая версия) :
вопрос довольно странно сформулирован, да и с vyos не работал. Если по сути - как я понял у тебя есть две подсети, между ними два шлюза с одной общей подсетью, что на вид сильно похоже на обычный тоннель.
далее, у тебя есть статические маршруты на первом шлюзе во второю подсеть через второй шлюз, и на втором шлюзе в первую подсеть через первый шлюз. Оба маршрута используют общую подсеть и адреса в ней.
далее, компы в подсетях о другой подсети не знают, потому получая от юзера запрос в ту подсеть пойдут по default маршруту на шлюз, где включается логика маршрутизации шлюза. Аналогично пойдут ответные пакеты.
соответственно у меня возникает вопрос - а при чем тут вообще нат? маршрут разрешается в первую очередь по longest matching prefix, потому пакет на хост 1.2.3.4 пойдет по маршруту 1.2.3.0/24, а не по 0.0.0.0/0. Или ты натишь между подсетями, а не только на внешку?
покажи вообще ipfw list.
Исходная версия upcFrost, :
вопрос довольно странно сформулирован, да и с vyos не работал. Если по сути - как я понял у тебя есть две подсети, между ними два шлюза с одной общей подсетью, что на вид сильно похоже на обычный тоннель.
далее, у тебя есть статические маршруты на первом шлюзе во второю подсеть через второй шлюз, и на втором шлюзе в первую подсеть через первый шлюз. Оба маршрута используют общую подсеть и адреса в ней.
далее, компы в подсетях о другой подсети не знают, потому получая от юзера запрос в ту подсеть пойдут по default маршруту на шлюз, где включается логика маршрутизации шлюза. Аналогично пойдут ответные пакеты.
соответственно у меня возникает вопрос - а при чем тут вообще нат? маршрут разрешается в первую очередь по longest matching prefix, потому пакет на хост 1.2.3.4 пойдет по маршруту 1.2.3.0/24, а не по 0.0.0.0/0.
покажи вообще ipfw list.