У меня есть контейнер с входящей VPN. Соединению с этим контейнером будет назначен 192.168.10.10 IP. Виртуальный сетевой адаптер контейнера имеет IP-адрес 10.10.10.1 и шлюз (на главном мосту) 10.10.10.254.
При прямом входе в контейнер пакет уйдет с 10.10.10.1 как источник и будет знать, как вернуться (через мост).
При подключении к VPN пакет уходит с 192.168.10.10 как источник и не вернется как 192.168.10.x не рекламируется в сети (в эту сеть нет маршрута).
Для этого есть два решения:
10.10.10.1 192.168.10.x маршрут в сетиЯ бы хотел (по разным причинам) избежать любого из этих решений, и мне было интересно если есть возможность сделать маскарад на самом мосту, на стороне хозяина?
Другими словами, пакет покидает контейнер с источником 192.168.10.10, который затем был бы переписан "мостом" на известный 10.10.10.1 IP (а затем снова переписывается, когда ответ возвращается в контейнер)
Примечание: как это сделать в shorewall было бы здорово, но любая информация будет отличной.
Для shorewall вы можете отредактировать / etc / shorewall / masq, чтобы он выглядел примерно так:
br0 192.168.10.1/24 - tcp 22,80,443
Вам также нужно будет создать запись в / etc / shorewall / hosts и / etc / shorewall / zone для диапазона VPN и, конечно же, добавить все необходимые правила в / etc / shorewall / rules.
Однако я думаю, что у вас может быть случай XY проблема.
Если я правильно понимаю вашу настройку, только ваш контейнер знает о 192.168.10/24 ассортимент.
Это означает, что проблема на самом деле не будет решена (только) с помощью маскарадинга.
Проблема в том, что хост, на котором работает контейнер, также не имеет маршрута для 192.168.10 / 24, потому что этот маршрут существует только в таблице маршрутизации контейнера.
Итак, как минимум, вам потребуется:
ip r add 192.168.10.1/24 via 10.10.10.1)В противном случае ваш контейнерный хост видит, сколько марсиан приходит из вашего VPN-контейнера.
В MASQUERADE цель iptables работает в POSTROUTING таблица, которая используется только для пакетов, маршрутизируемых с одного интерфейса на другой. Мостовые пакеты, вероятно, никогда не будут доступны на уровне IP, поэтому вы не сможете их замаскировать.