Сделать устройство, которое не умеет в vpn, клиентом vpn сети

Network bridge

ssh -L
ssh -R

До этого делал бридж для виртуалки, но как сделать его для обособленного устройства со своим интерфейсом - не понял. Как я объединю в бридж интерфейс RPi и некий интерфейс, которым я не могу управлять, у второго устройства?

Как это работает, когда ssh есть только на RPi, но нет на втором устройстве и нет на клиенте, с которого получаю доступ?

какой ты загадочный. говори уже прямо, что умеет второе устройство и как оно к RPi подключено

Это ты прям молодец

Никак оно к RPi не подключено. Написал же, что оно в одной локалке с RPi. Там нет ничего, кроме ethernet и вебни для управления.

Никак оно к RPi не подключено
в одной локалке с RPi
ethernet и вебни для управления

ну ты это, определись уже как-то

Корма тебе тут не будет. Можешь идти.

Что-то вроде проброса порта, только не через роутер.

Ну сделай проброс порта через RPi.

Какой софт мне нужен?

Другими словами, достаточно ли для этого простого маскарадинга типо такого

Destination NAT

You need to add the following table and chain configuration:

% nft 'add rule nat prerouting iif eth0 tcp dport { 80, 443 } dnat 192.168.1.120'

https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)

Или нужен доп. софт? Если этого достаточно, то новое соединение происходит через пакеты, которые идут устройство управления -> RPi -> устройсто. А ответы по какому маршруту будут идти? Тот же или RPi уже в этой схеме не обязателен? Мне нужно, чтобы и ответы шли через openvpn, то есть все соединение полностью внутри впн. Маршруты я не могу корректировать на конечном устройстве.

Нужен iptables. -j DNAT –to-destination

Гуглить iptables port forwarding.

Устройство = устройство в той локалке типа умный свитч или тупая вебкамера
Десктоп = комп не в той локалке, например домашний

--

способ 1, запускать на rpi.


ssh CloudVPS -R 0.0.0.0:8222:ustrojstvo_ip:8222 -N

из интернета обращаемся на cloudvps:8222, попадаем на ustrojstvo_ip:8222
---

Способ 2, запускать на твоем десктопе. Здесь я предполагаю , что по адресу Cloudvps:2222 ты можешь залезть на Rpi.

ssh Cloudvps -p 2222 -L 8222:ustrojstvo_ip:8222 -N

Потом лезешь на localhost:8222 со своего декстопа, попадаешь на ustrojstvo_ip:8222

--

Все способоы выше могут не работать, потому что тупое устройство тебя будет редиректить своей тупой вебмордой на свой локальный IP типа 192.168.хр.ень. Поэтому

Способ 3 , поднимаем SOCKS прокси на RPI.

Запускать на десктопе

ssh Cloudvps -p 2222 -D 5555 -N

и лезешь браузером на ustrojstvo_ip:8222 , предварительно сконфигурив в браузере socks proxy == localhost:5555

Понятно, что ничего не понятно. Буду разбираться с носками. Скажи хотя бы, вот это условие

Все общение между устройством, с которого хочу получить доступ, и конечным устройством должно быть внутри openvpn.

при варианте 3 осуществимо? Ответы будут внутри туннеля идти через носки на малине или они будут по дефолту валиться напрямую на роутер?

Если RPi будет маршрутизатором для твоего устройства, то да.

Ну если без иптаблеса, можно haproxy взять.

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

Не обязательно. Просто сделать DNAT и разрешить роутинг. А на устройстве указать маршрут по умолчанию IP от RPi. Но согласен, неудобно. Я в таких случаях просто через haproxy делаю.

Только вот

Маршруты я не могу корректировать на конечном устройстве.

Если днат+снат на рпи, то устройство трогать вообще не надо.

Если днат+снат на рпи, то устройство трогать вообще не надо.

Если на устройстве маршрут по умолчанию через RPi.

Нет. Если оно в той же локальной сети. Оно будет думать что к нему рпи обращается.

Через iptables? Чтобы DNAT? Нет, не будет. Он будет думать, что к нему обращается указанный IP, на который он попытается отправить ответ, используя свои таблицы маршрутизации. И отправить вообще в никуда.

я жи писал DNAT+SNAT ( а ты ответил на просто DNAT ).
это значит RPI подменит src_ip на свой из локалки. Так что «устройство» ответит на RPI , а не на default gw.

Ну SNAT да.