Установка: у
меня есть настройка клиент / сервер openvpn (файлы конфигурации внизу), и я получаю печально известное MULTI: bad source address from client [192.168.x.x], packet dropped
сообщение на сервере. Сервер имеет публичный IP-адрес, а клиент находится за NAT.
Недостатками ранее предложенных решений:client-config-dir
определены в конфигурации сервера пуста. Предыдущие сообщения (здесь и на форумах поддержки openvpn) предлагают добавить либо файл с именами DEFAULT
с соответствующими правилами client-config-dir
, либо добавить файл для каждого пользователя с этими правилами для решения проблемы.
Тем не менее, это не кажется долгосрочным решением, потому что эти правила зависят от местоположения клиента. Итак, я могу добавить правило, позволяющее клиентам 192.168.x.0
подключаться. Но если они подключаются из другой сети, которая вместо этого использует 192.168.y.0
для NAT, потребуется новое правило.
Вопросов:
- Могут ли необходимые правила быть написаны универсальным / одноразовым способом?
- Может кто-нибудь объяснить, почему эта проблема возникает в первую очередь?
Конфигурация сервера:
port 1234
proto tcp
dev tun
ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem
server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC
user nobody
group nogroup
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login
status openvpn-status.log
push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"
client-config-dir ccd
verb 4
Конфигурация клиента:
ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234
auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4
192.168.x.0
и клиента, который находится в192.168.y.0
сети? Они все в той же192.168.x.x/16
сети, которую вы определили ... (?)Ответы:
Вы спросили: « Кто-то может объяснить, почему эта проблема возникает в первую очередь? »
На основании того, что сообщается в официальном FAQ по OpenVPN, я уверен, что это вызвано проблемой маршрутизации в движке OpenVPN.
Чтобы лучше прояснить сценарий, позвольте мне обратиться к следующей диаграмме:
Здесь вы можете увидеть:
Также
Теперь давайте предположим, что:
Имея такой сценарий, давайте подробно проверим, что происходит, когда R_PC1 (192.168.1.2) отправляет пакет, как эхо-запрос, в L_PC1 (10.0.1.2):
Так что все в порядке ...
Теперь давайте проверим, что происходит с эхо-ответом, который L_PC1 отвечает R_PC1.
Теперь, если мы хотим, чтобы 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 сможет определять маршрут пакета с помощью 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 подходит именно к нашей области:
Итак, вам нужно:
для применения (к серверу) при подключении клиента OpenVPN, например, через специальный файл конфигурации, определенный на сервере (client-config-dir и т. д.).
Если вам интересно , почему эта проблема не не произойдет на шаге 2) выше, я понимаю, что OpenVPN клиент знает , как направить его, потому что он знает , что VPN-туннель по умолчанию шлюз.
То же самое нельзя сделать на сервере OpenVPN, потому что там шлюз по умолчанию обычно не переопределяется. Кроме того, учтите, что у вас может быть один сервер OpenVPN с большим количеством клиентов OpenVPN: каждый клиент знает, как связаться с сервером, но ... как сервер может решить, какой клиент выполняет роль шлюза для неизвестной подсети?
Что касается вашего первого вопроса ( Могут ли необходимые правила быть написаны в общем / одноразовом виде? ), Извините, но я не понимаю вашу проблему. Можете ли вы перефразировать, предоставив более подробную информацию?
источник
У меня была проблема, которая кажется похожей, но я не уверен, что она такая же, как ваша проблема. Я пытался пинговать с клиента openvpn на компьютер в локальной сети сервера openvpn (маршрутизируемый в конфигурации сервера), не получая ответа, и я мог видеть сообщение «неверный адрес источника» в журнале сервера openvpn.
Чтобы решить ее, мне пришлось сделать 2 вещи:
Это исправило это для меня.
источник