Маршрутизация из одной сети в другую через цепочку Wireguard > OpenVPN?

Добрый день.
Имеется 4 сети и зоопарк устройств (по факту интересует только 2 сети и парочку устройств в них).

Сеть 192.168.11.0 - моя личная, 192.168.12.0 - товарища, 192.168.1.0 и *.2.0 - сети компании.
Вот схема:
5fdbc2bbc76fa648504335.png

С телефона могу пинговать всю сеть 192.168.11.0 и 192.168.12.0.
С 192.168.11.3 могу пинговать ВСЕ вокруг.
Интересует способ сделать возможность пинговать все сети из под сетей 192.168.11.0 и 192.168.12.0 и, главное, возможность пинговать с телефона сети 192.168.1.0 и 192.168.2.0 (то есть чтобы пакеты сначала прокидывались через WG, а потом через OpenVPN). И критично важно, чтобы в сети 192.168.1.0 и 192.168.2.0 пакеты из 192.168.11.0 и 192.168.12.0 шли из под IP 192.168.2.90 (в сетях компании блокируется весь чужеродный трафик).

На 192.168.2.90 правилось iptables только одно:
iptables -t nat -A POSTROUTING -s 10.8.2.0/24 -o ens32 -j SNAT --to-source 192.168.2.90

и все остальные сотрудники, кто пользуется этим туннелем - спокойно ходят в сети *.1.0 и *.2.0 без каких либо проблем.

На 192.168.11.3 как я понимаю ничего в iptables прописывать не надо, так как он выступает просто как клиент? Вот это я не понимаю(

Для чего это нужно все? Чтобы иметь доступ к домашней сети, к сети товарища и к сетяМ компании (те самые *.1.0 и *.2.0) с телефона и компов дома не используя по сути никакого доп.софта на конечных устройствах, кроме телефона, на котором, благодаря этой схеме, нужно будет использоваться только ОДИН vpn с ОДНИМ подключением для всего (причем личный), которое будет работать в автоматическом режиме и всегда в фоне. Не надо будет заморачиваться с кучей сертификатов OpenVPN, а просто использоваться один единственный (уже полученный на работе) на одном компе 192.168.11.3 (HP microserver с debian 10) и дальше уже плясать "по той дорожке".
  • Вопрос задан
  • 196 просмотров
Решения вопроса 1
shurshur
@shurshur
Когда мы идём с самого сервера 192.168.11.3 в 192.168.1.* и 192.168.2.*, то в качестве исходящего адреса выставляется IP местного конца туннеля, в данном случае 10.8.2.3, поэтому всё и работает. Это легко проверить с помощью команды типа:

ip route get 192.168.1.77

Когда же подобный трафик приходит с телефона, у него IP-адрес 10.1.3.2. С таким адресом трафик попадает на astrave-mainsrv и в дальнейшем роутится в openvpn либо не пропускается на astrave-mainsrv (смотря как там настроено). Аналогичная фигня происходит с трафиком из сетей 192.168.11.* и 192.168.12.* - он не будет уходить в туннель с адресом источника 10.8.2.3.

Решение: на astrave-mainsrv весь трафик, уходящий в openvpn, NATить в 10.8.2.3.

Вот так (тут tun666 - интерфейс openvpn):

iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -o tun666 -j SNAT --to 10.8.2.3

Или даже так (тогда можно не задумываться о том, какой IP на нашей стороне туннеля, особенно если он динамический):

iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -o tun666 -j MASQUERADE

Или даже можно не особо разбираться с конкретным адресом (тогда заодно с любых IP типа 192.168.11.* заработает, если трафик от них как-то попадёт на astrave-mainsrv):

iptables -t nat -A POSTROUTING -o tun666 -j MASQUERADE

Общий смысл: если компания хочет видеть у себя весь трафик подключающегося по VPN сотрудника c адреса 10.8.2.3, то мы весь трафик должны посылать именно с этого адреса, подменяя адрес источника.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы