MULTI: неверный исходный адрес от клиента - какие-либо одноразовые решения?

Ты спрашивал: "Может кто-нибудь объяснить, почему возникает эта проблема?"

На основании того, что сообщается в официальный OpenVPN FAQ Бьюсь об заклад, это вызвано проблемой маршрутизации в движке OpenVPN.

Чтобы лучше прояснить сценарий, позвольте мне обратиться к следующей диаграмме:

Здесь вы можете увидеть:

• «сервер» OpenVPN, подключенный к внутренней сети ШТАБА (10.0.1.0/24)
• «клиент» OpenVPN, работающий на удаленном сайте и подключенный к удаленной сети 192.168.1.0/24

Также

• мы предполагаем, что туннель OpenVPN установлен и:
  • «Сервер» OpenVPN доступен через собственный тун интерфейс, с адресом 10.10.0.1. Также, адрес P2P, используемый интерфейсом tun, - 10.10.0.2. (это важно для дальнейшего обсуждения, поэтому давайте подчеркнем это)
  • «Клиент» OpenVPN имеет тун интерфейс с IP 10.10.0.2

Теперь предположим, что:

• «Клиент» OpenVPN переопределил свой шлюз по умолчанию, чтобы перенаправить в туннель весь исходящий IP-трафик;
• «Клиент» OpenVPN имеет включенный IP_FORWARDING и, как таковой, может маршрутизировать пакеты, поступающие из его внутренней LAN (192.168.1.0/24) (Я подчеркиваю этот момент, так как он важен для нашего обсуждения).

Имея такой сценарий, давайте подробно проверим, что происходит, когда R_PC1 (192.168.1.2) отправляет пакет, например эхо-запрос, на L_PC1 (10.0.1.2):

1. после выхода из сетевого адаптера R_PC1 пакет достигает клиента OpenVPN;
2. Клиент OpenVPN (который настроен для работы в качестве обычного маршрутизатора) направляет его в соответствии с его таблицей маршрутизации. Поскольку шлюзом по умолчанию является туннель, он отправляет пакет в туннель;
3. Пакет достигает интерфейса tun сервера OpenVPN. OpenVPN "увидит" его и, поскольку он (сервер OpenVPN) знает, что 10.0.1.2 - это адрес, принадлежащий его подсети LAN, он "пересылает" пакет из TUN в LAN;
4. Достижение пакета L_PC1.

Так что все нормально ...

Теперь давайте проверим, что происходит с эхо-ответом, который L_PC1 отвечает R_PC1.

5. эхо-ответ покидает сетевой адаптер 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-адрес». Благодаря такому статическому маршруту теперь ...

6. пакет покидает контекст маршрутизации ОС и достигает 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: каждый клиент знает, как связаться с сервером, но ... как сервер может решить, какой клиент выступает в качестве шлюза для неизвестной подсети?

Что касается вашего первого вопроса (Могут ли необходимые правила быть написаны универсальным / одноразовым способом?), Извините, но я не понимаю вашу проблему. Не могли бы вы перефразировать, указав более подробную информацию?

У меня была проблема, которая кажется похожей, но я не уверен, совпадает ли она с вашей. Я пытался выполнить эхо-запрос с клиента openvpn на компьютер в локальной сети сервера openvpn (маршрутизированный в конфигурации сервера), не получая ответа, и я мог видеть сообщение «плохой адрес источника» в журнале сервера openvpn.

Чтобы решить эту проблему, мне пришлось сделать 2 вещи:

1. Включите переадресацию IP на сервере.
2. Добавьте маршрут для подсети vpn на шлюз сервера, потому что шлюз для локальной сети сервера в моем случае - это не сам сервер, а маршрутизатор. Компьютер с проверкой связи пытался ответить через шлюз, который не знал, что делать для подсети vpn. Поэтому я добавил статический маршрут в маршрутизатор, используя подсеть vpn для пункта назначения и IP-адрес сервера openvpn в качестве шлюза для него.

Это исправило это для меня.