Вы в той же локальной сети, что и ваш первый RPI? Если это так, вы не должны потерять контакт с ним вообще. VPN работают путем добавления маршрутов, а не подавления существующих. Итак, если у вас был маршрут как
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.74 metric 1
перед запуском VPN, тот же маршрут должен продолжать существовать после того, как VPN изменит вашу таблицу маршрутизации. Это оставляет ваш RPI доступным из вашей локальной сети. Возможно, вам придется связаться с ним по IP-адресу, а не по имени (если, конечно, вы не используете локальный DNS); также возможно, что из RPI вы не можете получить доступ к другим ПК в вашей локальной сети через имя, потому что DNS был перенаправлен через VPN (не обязательно, но чаще всего).
Если RPI не находится в вашей локальной сети, то это другое дело; Пожалуйста, укажите, так ли это.
РЕДАКТИРОВАТЬ:
У вас есть три варианта, два простых и немного более сложный.
Если вы всегда подключаетесь, скажем, из 1.2.3.4, просто добавьте подходящий маршрут в таблицу маршрутизации первого RPI:
ip route add 1.2.3.4./32 via 192.168.0.1 dev eth0
Это будет маршрутизировать пакеты для 1.2.3.4 через обычный шлюз локальной сети (я предположил, что это 192.168.0.1, если не изменен соответствующим образом), минуя VPN вообще;
Поскольку вы используете коммерческий VPN, этот прием вряд ли сработает. Если у вас был VPN-сервер на вашем собственном VPS (что, к слову, я всегда делаю, дешевые VPS стоят 3 доллара / евро в месяц, а некоторые имеют неизмеренные соединения), то вы просто подключаетесь к VPN-серверу через VPN, затем свяжитесь с вашим RPI с помощью ssh , используя в качестве IP-адреса адрес его конца туннеля! Итак, если ваш VPN-туннель имеет адреса 10.0.0.1 для сервера и, скажем, 10.0.0.6 для клиента RPI, это
ssh me@10.0.0.6
соединит вас с RPI. Так как вы используете коммерческий провайдер VPN, даже если вы можете подключиться к их серверу через VPN с ПК, который не является RPI, я сомневаюсь, что они позволят вам связаться с другим клиентом: это было бы немного, как позволить лисе в куриная ручка, не так ли?
- Более сложное решение объясняется здесь для первого RPI: основная идея состоит в том, чтобы настроить вторую таблицу маршрутизации, что может быть сделано только в Linux, даже в Unix; эта вторая таблица маршрутизации не использует VPN, просто ваш обычный шлюз локальной сети. Чтобы идентифицировать пакеты, которые будут направлены через эту вторую таблицу маршрутизации, вам нужно будет пометить все пакеты с определенной характеристикой, например, те, которые входят в RPI через порт 22 (порт ssh), с помощью модуля CONNTRACK, а не модуля MARK: это помечает все соединение, а не только отдельный пакет, включая УСТАНОВЛЕННЫЕ, СВЯЗАННЫЕ пакеты. Теперь вы можете настроить
ip rule которое выбирает помеченные пакеты, указывающие ядру использовать вторую таблицу маршрутизации, т.е. таблицу без VPN.
