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

shurshur, iptables -t nat -A POSTROUTING -o tun3 -j MASQUERADE на 192.168.11.3 помогла, но...
Интересует реально ли сделать на 192.168.2.90 (сервере ovpn) подобное правило, чтобы все пакеты так же маскарадило, только уже с интерфейса на той стороне (там это интерфейс tun2)?

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

dimonchik2013, в программе где рисовал не нашел подходящих значков

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

Но... ведь с самого astrave-mainsrv сети компании пингуются нормально! И пинги с него доходят через ovpn на сервера pce72/pcs72 с айпишника 192.168.2.90! Тут как я понимаю все окей как раз. Доступа нет ЗА mainsrv, в том числе и с телефона, который к нему цепляется по WG.

Поможете разобраться в принципе маршрутизации в схеме подключения?

Спасибо за доходчивый ответ. Кажется таким образом я проблему вчера и решил... но планы на настройку изменились. Идея прокидывать сеть компании через КЛИЕНТА на одном из компов в офисе отпалась. Сервер 192.168.11.3 будет подключаться как клиент к OVPN серверу в сети компании и маршрутизация будет между WG и OVPN. Думаю так правильнее)

Поможете разобраться в принципе маршрутизации в схеме подключения?

На 192.168.1.44 такие правила:
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -i wg0 -o enp4s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i enp4s0 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A POSTROUTING -s 10.1.3.0/24 -o enp4s0 -j MASQUERADE

Пакеты с 192.168.11.0/24 приходят же с интерфейса 10.1.3.1

Поможете разобраться в принципе маршрутизации в схеме подключения?

Alexey Dmitriev, так верно... но тогда на 192.168.1.44 и должны подменяться адрес пакетов из сети 192.168.11.0/24 на адрес 192.168.1.44. А они не подменяются. Ведь SNAT же есть. -A POSTROUTING -s 10.1.3.0/24 -o enp4s0 -j MASQUERADE

Поможете разобраться в принципе маршрутизации в схеме подключения?

rionnagel, проверял им. Как раз и им увидел что пакеты icmp уходят от IP ноды-вайргард левой сети (192.168.11.3),

Поможете разобраться в принципе маршрутизации в схеме подключения?

Alexey Dmitriev, потому что вторая сеть .1.0/24 это сеть компании и там микротики отбрасывают пакеты с других подсетей (моя домашняя .11.0/24). Поэтому надо маскировать пакеты под IPшник компа вайргард-ноды (192.168.1.44).

Как импортировать и экспортировать конфигурацию установленных пакетов (с оговоркой)?

Денис Юрьев, спасибо. Не проверял, так как нашел второе решение.
dpkg --set-selections < packagelist.txt + apt-get dselect-upgrade
Для второй команды нужно просто поставить пакет dselect и все работает.

Как импортировать и экспортировать конфигурацию установленных пакетов (с оговоркой)?

А нет... после экспорта списка пакетов, в файле оказываются записи

1c-enterprise83-client install
1c-enterprise83-common install
1c-enterprise83-server install
1c-enterprise83-ws install
accountsservice install
acl install
adduser install
adwaita-icon-theme install
alsa-utils install
anacron install
apparmor install
apt install
apt-listchanges install
apt-transport-https install

и так далее...

и выполнение команды apt install -y $(< list.txt) приводит к...

E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install
E: Невозможно найти пакет install

Как импортировать и экспортировать конфигурацию установленных пакетов (с оговоркой)?

Решение более чем удовлетворяет. Проверил, все работает. Спасибо!

TCP Retransmission там где его не должно быть. Почему?

В данный момент костыль прикручен. Добавил IP в черный список файрвола. Прога запускается мгновенно. Но решение так себе.

TCP Retransmission там где его не должно быть. Почему?

Denis, Программа не наша) сторонний сервис. У них арендуем

TCP Retransmission там где его не должно быть. Почему?

galaxy, ну там не 15 секунд точно. первый пакет в 1сек, второй (уже повтор) - через 5 сек... и третий раз еще через секунды 3-4. То есть поведение тут не по умолчанию...

TCP Retransmission там где его не должно быть. Почему?

galaxy, честно в винде ничего не делал (вопрос же о компе с виндой). Одна из причин почему сюда обратился - думал есть какие то ньюансы в работе TCP стека в семерке и что-то там можно накрутить. Завтра на работе буду и проверю Настройки фаервола. Включу ICMP. Но все же не понятно почему тогда ответ от того айпишника не фиксируется в дампе пакетов (на тех же компах, где все нормально)

TCP Retransmission там где его не должно быть. Почему?

galaxy, теория ясна. Ладно. Но... эти ответы были бы видны в Wireshark? Просто на нормальных хостах нет ответов от того айпишника. Просто прога шлёт «вникуда» н 555 порт TCP пакет и успокаивается.

TCP Retransmission там где его не должно быть. Почему?

galaxy, но там TCP пакеты уходят! На 555 порт (порт RDP на тех хостах). И тот комп остальные хосты пингует

TCP Retransmission там где его не должно быть. Почему?

galaxy, ну я там смотрел по фильтру с IP тем самым. Не было пакетов с RST. Вообще нет пакетов с того IP. Есть только НА тот IP. Просто на проблемном ПК эти пакеты 2 раза отправляются повторно.

TCP Retransmission там где его не должно быть. Почему?

galaxy, в том то и дело что сервер не наш, а удаленный. Сторонний сервис. Как я описал - все компы (вроде как) нормально работают с этой прогой. Подвисает только один. В в перехвачено трафике на нем видно что он не один раз шлёт запрос.

TCP Retransmission там где его не должно быть. Почему?

А почему тогда на другие может приходить RST, а на этот один не приходит? Куда копать?
Сервер не отвечает. Если пинговать - пинг бесконечно долго висит.