Вы спросили: « Кто-то может объяснить, почему эта проблема возникает в первую очередь? »
На основании того, что сообщается в официальном FAQ по OpenVPN, я уверен, что это вызвано проблемой маршрутизации в движке OpenVPN.
Чтобы лучше прояснить сценарий, позвольте мне обратиться к следующей диаграмме:
Здесь вы можете увидеть:
- OpenVPN-сервер, подключенный к внутренней сети HEADQUARTER (10.0.1.0/24)
- OpenVPN-клиент, работающий на удаленном узле и подключенный к удаленной сети 192.168.1.0/24
Также
- мы предполагаем, что туннель OpenVPN установлен и:
- OpenVPN «сервер» доступен через собственный интерфейс tun с адресом 10.10.0.1. Также P2P-адресом, используемым интерфейсом tun, является 10.10.0.2 ( это важно для дальнейшего обсуждения, поэтому давайте подчеркнем его )
- OpenVPN «клиент» имеет тун интерфейс с IP 10.10.0.2
Теперь давайте предположим, что:
- OpenVPN «Клиент» переопределил свой шлюз по умолчанию, чтобы перенаправить в туннеле весь исходящий IP-трафик;
- OpenVPN «Клиент» имеет включенный IP_FORWARDING и, как таковой, может маршрутизировать пакеты, приходящие из его внутренней локальной сети (192.168.1.0/24) ( я подчеркиваю этот момент, так как это важно для нашего обсуждения ).
Имея такой сценарий, давайте подробно проверим, что происходит, когда R_PC1 (192.168.1.2) отправляет пакет, как эхо-запрос, в L_PC1 (10.0.1.2):
- после выхода из NIC R_PC1 пакет достигает клиента OpenVPN;
- Клиент OpenVPN (настроенный для работы в качестве общего маршрутизатора) маршрутизирует его в соответствии с таблицей маршрутизации. Поскольку шлюз по умолчанию является туннелем, он отправляет пакет в туннель;
- Пакет достигает интерфейса TUN сервера OpenVPN. OpenVPN «увидит» его и, поскольку он (сервер OpenVPN) знает, что 10.0.1.2 является адресом, принадлежащим его подсети LAN, он «пересылает» пакет из TUN в LAN;
- Пакет достигает L_PC1.
Так что все в порядке ...
Теперь давайте проверим, что происходит с эхо-ответом, который L_PC1 отвечает R_PC1.
- echo-reply покидает сетевой адаптер L_PC1 и достигает интерфейса LAN сервера OpenVPN (10.0.1.1);
Теперь, если мы хотим, чтобы OpenVPN Server мог подключаться к удаленному сайту, нам нужно определить маршрутизацию с помощью «статического маршрута». Что-то вроде:
route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2
Обратите внимание на P2P-адрес, используемый в качестве шлюза .
Такие статические маршруты будут работать на уровне ОС. Другими словами, операционная система должна правильно маршрутизировать пакет. Это означает что-то вроде: «Пожалуйста, весь трафик, адресованный подсети 192.168.1.0/24, должен быть перенаправлен в механизм OpenVPN, с которым ОС может общаться через P2P-адрес». Благодаря такому статическому маршруту, сейчас ...
- пакет покидает контекст маршрутизации ОС и достигает OpenVPN. Экземпляр OpenVPN, работающий на сервере OpenVPN. Таким образом, на данный момент ОС больше нечего делать, и вся маршрутизация (в пределах VPN) оставлена программному обеспечению сервера OpenVPN.
Итак, теперь проблема в том, как серверное программное обеспечение openvpn сможет определять маршрут пакета с помощью SRC_IP 10.0.1.2 и DST_IP 192.168.1.2 ?
Обратите внимание, что, основываясь на конфигурации сервера OpenVPN, он ничего не знает ни о сети 192.168.1.0/24, ни о хосте 192.168.1.2. Это не подключенный клиент. Это не местный клиент. И так? OpenVPN также знает, что это не «OS-Router», поэтому он не хочет (и может ....) отправлять пакет обратно на локальный шлюз. Таким образом, единственный вариант здесь - вызвать ошибку. Именно ошибка, которую вы испытываете
Сказать это на языке FAQ: « ... он не знает, как маршрутизировать пакет на этот компьютер, поэтому он отбрасывает пакет ... ».
Как мы можем решить эту проблему?
Как видно из официальной документации , опция iroute подходит именно к нашей области:
--iroute network [netmask]
Generate an internal route to a specific client. The netmask
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server
to a particular client, regardless of where the client is
connecting from. Remember that you must also add the route to the
system routing table as well (such as by using the --route
directive). The reason why two routes are needed is that the
--route directive routes the packet from the kernel to OpenVPN.
Once in OpenVPN, the --iroute directive routes to the specific
client.
Итак, вам нужно:
--iroute 192.168.1.0 255.255.255.0
для применения (к серверу) при подключении клиента OpenVPN, например, через специальный файл конфигурации, определенный на сервере (client-config-dir и т. д.).
Если вам интересно , почему эта проблема не не произойдет на шаге 2) выше, я понимаю, что OpenVPN клиент знает , как направить его, потому что он знает , что VPN-туннель по умолчанию шлюз.
То же самое нельзя сделать на сервере OpenVPN, потому что там шлюз по умолчанию обычно не переопределяется. Кроме того, учтите, что у вас может быть один сервер OpenVPN с большим количеством клиентов OpenVPN: каждый клиент знает, как связаться с сервером, но ... как сервер может решить, какой клиент выполняет роль шлюза для неизвестной подсети?
Что касается вашего первого вопроса ( Могут ли необходимые правила быть написаны в общем / одноразовом виде? ), Извините, но я не понимаю вашу проблему. Можете ли вы перефразировать, предоставив более подробную информацию?