iptables + тунель + 2 сети

Задача: сделать чтобы машинам из моей сетки 1.0/24 были доступны машины с той стороны тунеля.

Смотри - на твоей стороне сеть 192.168.1.0/24. Трафик в этой сети идет между компами напрямую МИНУЯ шлюз. То есть пингуя комп 192.168.1.2, они ищут его в том же сегменте, а не идут в туннель.

В общем случае задача «дать доступ компам из сети 192.168.1.0/24 на другую сторону туннеля в туже самую подсеть» не решается без ОБЪЕДИНЕНИЯ этих подсетей(с устранением возможных пересечений IP-адресов) или СМЕНЫ адреса сети на одной из сторон.

Простой SNAT тут не поможет никак.

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

Но я бы всё же рекомендовал сменить сегмент

на «той» стороне прописана свободная сетка 4.0/24, которую я могу использовать под свои нужды. Проблема в том, что на сетке 1.0/24 «висят» куча IP камер посредством свитчей, все они имеют статически прописанные IP (сетка проектировалась до меня) поэтому менять их всех (около 70 штук) достаточно проблематично. А если добавить еще один интерфейс в шлюз что-то типа 192.168.4.1 и пустить на него весь трафик с моей 1.0/24 используя SNAT, такая схема заработает?

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

Если ты не можешь сменить адресацию, то используй netmap.

Проблема в том, что на сетке 1.0/24 «висят» куча IP камер посредством свитчей, все они имеют статически прописанные IP (сетка проектировалась до меня) поэтому менять их всех (около 70 штук) достаточно проблематично.

С одной стороны? Если да, то поменять сеть с другой стороны.
Если нет возможности, то присоединяюсь к варианту netmap.

Никакая комбинация без смены адресов на клиентах(либо адресов источников либо адресов назначения) не заработает.

Пример с NETMAP, который уже упоминался:

Допустим у нас есть две сети(foo и bar), в каждой из которых есть подсеть 192.168.1.0/24.

Допустим клиент из сети foo с IP 192.168.1.5 хочет подключиться к IP 192.168.1.6 из сети bar. Напрямую он этого сделать не может - сам клиент будет искать этот IP в сети foo, так как он находится в той же сети(точнее имеет тот же самый «адрес сети» - 192.168.1.0).

Решение: выделяем блок, например, 192.168.5.0/24(неиспользуемые ранее ни в foo ни в bar) и прозрачно транслируем все исходящие запросы на 192.168.5.0/24 из сети foo в 192.168.1.0/24 расположенные в сети bar(так как транслировать будет роутер, уже подключенный к сети 192.168.1.0/24 из сети foo - потребуется другая таблица маршрутизации).

То есть если 192.168.1.5 из сети foo хочет обратиться к 192.168.1.6 из сети bar, он должен стучать на 192.168.5.6 - тогда этот траффик пойдет через роутер и данную трансляцию.

Ну а так как адрес источника у нас остался не изменным(192.168.1.5) - ответы на него не дойдут(потому что со стороны bar сеть 192.168.1.0/24 доступна напрямую, а не через туннель). И вот тут есть два варианта - если нам нужен непосредственный доступ из сети bar на подсеть 192.168.1.0/24 сети foo - тогда мы делаем тоже самое - еще один сегмент, еще одна трансляция, уже для ответных адресов. Если же такой доступ не нужен - достаточно просто сделать SNAT в адрес роутера на стороне сети foo, о чём ты уже и так догадался.

Но это всё не отменяет факта, что это - дикий костыль и максимум стоит это использовать как временное решение.

Спасибо за подробное изложение. Видимо смена подсетки наиболее оптимальный вариант при всех трудозатратах по смене IP у камер.

Proxy arp, нет?