Маршрут к подсети ЛВС через клиент OpenVPN

Наткнувшись на этот вопрос при проведении другого поиска, выясняется, что OP пытается получить доступ к подсети , которая подключена к удаленный сервер OpenVPN.

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

Если я правильно понимаю, тогда - client-config-dir ( В этом случае необходимо использовать «CCD»). Должна быть директива route , охватывающая диапазон адресов подсети в основной конфигурации, и и iroute (обратите внимание на «i») в файле CCD, который будет правильно идентифицирован как принадлежащий тому удаленному . (Вы увидите, распознан ли он, посмотрев журналы OpenVPN, а затем убедившись, что маршрут теперь существует на вашем компьютере.)

Если вы получаете доступ к подсети из другой подсети (то есть ] не с машины, на которой запущен клиент OpenVPN, должен быть также статический маршрут в вашей локальной подсети, который отправляет трафик на вашу машину OpenVPN «в качестве шлюза». Это может быть определено на каждой клиентской машине или , что более удобно, на локальном маршрутизаторе.

И вот как будет передаваться трафик:

• Вы проверяете удаленную подсеть.
• Ваш компьютер или маршрутизатор перенаправляет трафик на ваш OpenVPN-сервер в качестве шлюза. (Потому что функционально туннель OpenVPN действует как маршрутизатор.)
• Директива route на этой машине заставляет трафик отправляться на устройство tunX , так что OpenVPN фактически получает его.
• Директива iroute (и CCD, в которой она встречается) сообщает OpenVPN о существовании удаленной подсети и о том, на какой удаленный сервер ее следует отправить. (Даже если есть только один удаленный.)
• Трафик направляется к месту назначения на удаленной стороне.
• А теперь все должно происходить наоборот! Удаленное устройство отправляет ping-ответ, используя ваш IP-адрес в удаленной подсети, и он должен вернуться обратно домой.

Если вы отправляете эхо-запрос с компьютера, который напрямую подключен к OpenVPN (на нем запущен клиент) , то ваш адрес, вероятно, будет 10.8.0.x и этот диапазон адресов также должен быть успешно маршрутизирован «туда и обратно» на всех задействованных устройствах.

Это «основные проблемы маршрутизации TCP / IP», которые могут иметь место независимо от того, является ли «рассматриваемый маршрутизатор» OpenVPN или нет. Как только вы заставите хосты успешно взаимодействовать друг с другом (ура!) , «в сети они просто маршрутизаторы».

tcpdump (или WireShark) и traceroute здесь ваши лучшие друзья. Во-первых, вы должны убедиться, что зашифрованный трафик доставляется между хостами OpenVPN, как и должно быть. (Хотя, конечно, вы не можете прочитать их содержимое, вы можете видеть, что они маршрутизируются или нет.) Затем проделайте то же самое в туннеле.Проследите, чтобы пакеты доставлялись в туннель и через него, и чтобы они доставлялись туда и обратно. (Если traceroute начинает печатать строки со звездочками, это, вероятно, означает, что на этом конкретном «переходе» нет обратной маршрутизации. Пакет попадает туда, но не может добраться домой оттуда. .)

К сожалению, сетевые инструменты часто выдают ужасные сообщения об ошибках. Насколько я могу судить, ядру не нравится то, что вы пытаетесь добавить маршрут со шлюзом, который он не считает «локальным». Вы должны либо сделать:

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.9.0.2 dev tun0

или:

route add -net 192.168.0.0 netmask 255.255.255.0 dev tun0

В дополнение к настройке маршрута ядра вам также потребуется добавить маршрут внутри самого openvpn. Это делается с помощью директивы «iroute» в файле ccd для клиента.