☰

Openvpn несколько клиентов один шлюз

tag-icon • tag-icon openvpn gateway
Openvpn несколько клиентов один шлюз

У меня есть два клиента, которым нужно подключиться к одному серверу OpenVPN. Можно ли использовать один и тот же шлюз для обоих клиентов в параметре ifconfig?

Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1

Client B config file
[...]
ifconfig 10.0.0.3 10.0.0.1

Ситуация на сервере следующая:

tun0
inet 10.10.0.1 destination 10.10.0.2

tun1
inet 10.10.0.1 destination 10.10.0.3

Сейчас все работает нормально, но могут ли возникнуть проблемы со временем?

Мне сказали использовать другой шлюз, например такой:

Client A config file
[...]
ifconfig 10.0.0.2 10.0.0.1

Client B config file
[...]
ifconfig 10.0.1.2 10.0.1.1

Но я думал, что разные шлюзы нужны только для маршрутизации. Если я хочу добавить маршрут и перенаправить свой трафик на определенный интерфейс Tun, мне действительно нужен другой шлюз, иначе сервер не будет знать, через какой из них отправлять пакеты. Но если мне не нужен определенный маршрут, могу ли я использовать свою первую конфигурацию?

Спасибо

решение1

Это возможно и правильно. Параметр шлюза определяет конфигурацию на клиенте, которая используется для отправки данных в VPN, чтобы можно было определить маршрутизацию, как обычно в IP. После того, как пакет отправлен в процесс OpenVPN, он заботится о его маршрутизации (пока он не покинет какой-либо другой процесс OpenVPN).

В частности, вы определяете:

ifconfig 10.10.0.3 10.10.0.1

TheтолькоРезультат этой команды подобен выполнению следующих команд на клиенте:

ip address add 10.10.0.3 dev tun0
ip route add 10.10.0.1 dev tun0

Вот и все. Другие клиенты, сервер, внешние системы — больше никто не знает об этой конфигурации клиента.

Единственное, где используется шлюз, — это прописывание маршрутов к VPN следующим образом:

ip route add 192.168.0.0/24 via 10.10.0.1

например, чтобы сделать эту сеть доступной через VPN. Например, маршрут к VPN-серверу и другим клиентам делается так. Конечно, если у вас несколько клиентов, вы можете использовать на них один и тот же адрес шлюза (и вы делаете это естественным образом, например, для соседних компьютеров в той же локальной сети).

То же самое применимо и к серверу. Например, я запускаю несколько VPN на одной машине (один через UDP, другой через TCP на порту 443 с опцией port-share — чтобы иметь возможность пробраться через брандмауэры, которые блокируют обычные порты, но разрешают 443 и даже проверять, есть ли веб-сервер). Оба сервера имеют одинаковыйместныйадрес настроен и отличаетсяудаленный(это позволяет указать, через какой VPN я буду направлять пакеты).

Теперь о проблемах, с которыми вы столкнетесь. С полноценным Linux OpenVPN проблем, конечно, нет. Если вы собираетесь использовать "OpenVPN Client", будь то Linux, Windows, iOS/iPadOS/macOS или Android client, это зависит от того, что topologyвы настроите. В net30топологии они отклонят такую ​​конфигурацию как недействительную. В этом случае адрес клиента и его remote должны принадлежать одной подсети /30.

решение2

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

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

Все становится немного сложнее, если какая-то третья сторона должна иметь возможность достичь вашей удаленной конечной точки. Чтобы добраться до этой конечной точки, им понадобитсяудаленный адрескак пункт назначения пакета. Удаленная сторона, наоборот, использует ваш локальный адрес для того, чтобы определить свою версиюдругой конецкогда это необходимо, то есть он устанавливает к нему маршрут по умолчанию; однако он может использовать сам интерфейс туннеля в качестве пункта назначения маршрута, даже не зная вашего локального адреса, и это все равно будет работать.

Таким образом, если вам не нужно идентифицировать интерфейс туннеля по его локальной конечной точке (т. е. использовать его в качестве исходного адреса для определенных сценариев протокола динамической маршрутизации через туннель), вы можете использовать любой адрес в качестве локального адреса в туннеле — он даже не обязательно должен находиться в той же подсети, что и удаленный адрес.

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