☰

Автоматическое подключение к OpenVPN только при использовании Wi-Fi, а не Ethernet

tag-icon • tag-icon wireless networking vpn openvpn wired
Автоматическое подключение к OpenVPN только при использовании Wi-Fi, а не Ethernet

В моей домашней сети настроен сервер OpenVPN с использованием устройств TAP (а не TUN), благодаря чему клиенты, подключающиеся к сети удаленно, подключаются к той же подсети, что и моя (проводная) домашняя сеть.

Однако у меня есть ноутбук, который я подключаю дома с помощью Ethernet, а в других местах использую WiFi (я стараюсь не использовать WiFi дома — это катастрофа в переполненных многоквартирных домах Манхэттена). Мне также нравится иметь фиксированные IP-адреса для каждого устройства в моей сети, поэтому я фиксирую конфигурацию IP для его адаптера Ethernet и использую тот же IP для устройства TAP при подключении к VPN (с помощьюкаталог конфигурации клиентана стороне сервера).

Есть ли хороший и минимально хакерский способ настроить службу OpenVPN на моем ноутбуке так, чтобы она подключалась к OpenVPN только тогда, когда соединение Ethernet неактивно? Автоматическая работа службы OpenVPN в фоновом режиме очень удобна, и мне не хочется вручную отключать ее каждый раз, когда я подключаюсь к Ethernet, но попытка подключиться к той же сети, в которой я уже физически нахожусь, через VPN, используя тот же IP-адрес, который я уже использую, явно не очень хорошая идея...

Я уверен, что смогу что-то взломать с помощью скриптов инициализации, но я хотел бы максимально минимизировать расхождения с официальной конфигурацией Ubuntu. Я был бы очень признателен, если бы кто-нибудь придумал более "правильный" подход.

решение1

Я поигрался и нашел решение, которое работает для моей конфигурации. Это не совсем общее решение, так что надеюсь, кто-то сможет прийти и дать решение, которое будет более надежным.

Вместо того чтобы отключать OpenVPN на моем ноутбуке при подключении к Ethernet, я просто настроил UFW (Uncomplicated Firewall) на сервере OpenVPN моей сети, чтобы отклонять соединения из локальной подсети. Хотя это немного сложнее, чем просто создание правил с помощью sudo ufw allow ...и sudo ufw deny ...:

  • Во-первых, если вы используете ufw на машине, которая соединяет VPN с локальной сетью (что я и делаю), вам нужно настроить ufw для разрешения пересылки трафика, поскольку по умолчанию он его сбрасывает. Это означает изменение DEFAULT_FORWARD_POLICY="DROP"на DEFAULT_FORWARD_POLICY="ACCEPT"в /etc/default/ufw.

  • Во-вторых, вам нужно убедиться, что вы добавляете правила в правильном порядке; ufw обрабатывает правила одно за другим и использует то, которое вы отклоняете подключения к OpenVPN (порт 1149) внутри вашей подсети, прежде чем разрешать их извне, только если вы создаете их в этом порядке; в моем случае это означало запуск sudo ufw delete deny from 192.168.16.0/20 to any port 1194(нет, это не опечатка, я на самом деле использую подсеть /20 локально :D) перед запуском sudo ufw allow 1194.

  • Наконец, вам необходимо убедиться, что соединения из вашей локальной сети действительноделатьвыглядят так, как будто они приходят из вашей локальной сети, поэтому вызывается правило UFW.

Последняя часть важна, потому что изначально это было не так, когда я пробовал первые два шага; OpenVPN на моем ноутбуке автоматически настроен на попытку подключения к моему VPN в mydomainname.com, который динамически назначается моему домашнему маршрутизатору, который, в свою очередь, перенаправляет порт 1194 на компьютер, на котором запущен мой VPN в 192.168.16.1. Это может быть не так для всех маршрутизаторов, но для моего маршрутизатора, по крайней мере, подключение mydomainname.comиз локальной подсети создает соединение с сервером OpenVPN, который выглядит так, как будто у него есть IP-адрес маршрутизатора, а не ноутбука. (И это долгая история, но на самом деле я хочу разрешить доступ к VPN с других устройств, подключенных к маршрутизатору, в другой подсети — у меня довольно сложная домашняя настройка :D).

Решение в моем случае в конечном итоге заключалось в настройке DNS-сервера моего маршрутизатора со статическим назначением от mydomainname.comдо 192.168.16.1, так что он mydomainname.comразрешался напрямую в 192.168.16.1но в противном случае во внешний IP моего маршрутизатора. Это работает для меня, но ваш путь может отличаться.

Связанный контент