Маршрутизация определенного трафика через Open VPN

Я использую Open VPN для удаленного подключения к интрасети в другом городе в другой сети (но, вероятно, в той же подсети). Интранет находится на 192.168.1.42 на удаленном сервере в офисе.

Мы находимся в офисе, где IP-адрес 192.168.1.42 является локальным IP-адресом и удаленным IP-адресом, но я хочу заставить открытый VPN использовать удаленную версию этого IP-адреса, но оставить обычный Интернет по-прежнему с использованием локального соединения (т.е. не проталкиваю все через VPN). Возможное?

OpenVPN включает меры противодействия этой очень популярной проблеме. По сути, это статический NAT один к одному. Включается с помощью --клиент-натур вариант:

       --client-nat аргументы
              Эта опция клиента с поддержкой push-уведомлений настраивает NAT «один к одному» без сохранения состояния.
              правило для адресов пакетов (не портов), и полезно в случаях
              где маршруты или настройки ifconfig, переданные клиенту, 
              создать конфликт IP-нумерации.

              Примеры:

                 клиент-нат snat 192.168.0.0/255.255.0.0
                 клиент-нат днат 10.64.0.0/255.255.0.0

              сеть/сетевая маска (например, 192.168.0.0/255.255.0.0) определяет
              локальное представление ресурса с точки зрения клиента, в то время как
              псевдоним/сетевая маска (например, 10.64.0.0/255.255.0.0) определяет 
              удаленный просмотр с точки зрения сервера.

              Используйте snat (исходный NAT) для ресурсов, принадлежащих клиенту и 
              dnat (целевой NAT) для удаленных ресурсов.

              Установите --verb 6 для отладочной информации, показывающей преобразование 
              адреса src/dest в пакетах.

Добавьте следующее в файл конфигурации OpenVPN уязвимого клиента:

клиент-нат днат 10.64.0.0/255.255.0.0
клиент-нат snat 10.64.0.0/255.255.0.0

И попробуйте подключиться, например. 10.64.1.42 вместо 192.168.1.42.

Обратите внимание, пока это май помощь, вам обязательно понадобится отладка (используйте глагол 6 в файле конфигурации или на канале управления).Также помните, что все подобное подвержено ошибкам, поскольку делает вашу сеть менее четкой и требует большей концентрации, чтобы понять, что происходит и как исправить проблемы. А это, в свою очередь, создаст другие проблемы с IPSec, SIP или другими сложными протоколами; это неизбежно.

Чтобы исправить это, не вводя непонятные параметры конфигурации, следуйте совету Эсы Йокинена. Я скажу шире: так как 192.168.0.x и 192.168.1.x используются по умолчанию на большом количестве домашних устройств, никогда не используйте эти сети для офиса., а также, вероятно, 192.168.88.x тоже стоит внести в стоп-лист, потому что это дефолт для устройств Mikrotik, которые тоже достаточно популярны.

Изменение нумерации офисной сети таким образом, чтобы никогда не использовать эти подсети, приведет к наиболее чистому общему дизайну сети. (И эта идея распространяется даже на другие сетевые возможности, например, никогда не используйте идентификатор VLAN по умолчанию 1 и т. д.)

Самым простым и запутанным решением будет следующий обходной путь. Вы не можете просто нажмите "маршрут 192.168.1.0 255.255.255.0", потому что вы потеряете доступ ко всем локальным ресурсам. Но вы все еще можете протолкнуть маршруты к индивидуальные адреса в подсети. Например, если затронуто много клиентов, добавьте следующую строку в конфигурацию сервера:

нажмите "маршрут 192.168.1.42"

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