НЕСКОЛЬКО: неверный адрес источника от клиента - какие-то одноразовые решения?

10

Установка: у меня есть настройка клиент / сервер 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
M000
источник
Все ли ваши клиенты в сетях 192.168.xy?
IceMage
Мне не понятно ... Вы хотите сказать, что хотите по-другому маршрутизировать клиента, который включен, 192.168.x.0и клиента, который находится в 192.168.y.0сети? Они все в той же 192.168.x.x/16сети, которую вы определили ... (?)
krisFR

Ответы:

12

Вы спросили: « Кто-то может объяснить, почему эта проблема возникает в первую очередь? »

На основании того, что сообщается в официальном 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):

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

Так что все в порядке ...

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

  1. 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-адрес». Благодаря такому статическому маршруту, сейчас ...

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


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


Дамиано Верзулли
источник
Отвечая на ваш последний вопрос: я не хочу редактировать конфигурацию iroute каждый раз, когда клиент OpenVPN подключается с другого общедоступного Wi-Fi только потому, что он имеет другой адрес локальной сети.
Jollyroger
1
@jollyroger: в типичном сценарии "road-warriors" (один компьютер выступает в роли vpn-клиента по отношению к openpn-серверу), вам не нужна никакая директива "iroute"! Так что, если вы подключитесь через публичный Wi-Fi, я уверен, что вам это не нужно. Он понадобится вам только в типичных конфигурациях LAN-to-LAN, где за клиентом OpenVPN у вас есть целая сеть, к которой обращается сервер OpenVPN. Я уверен, что это НЕ тот случай, когда вы подключаетесь ... "с другого публичного Wi-Fi". Если мои предположения неверны, пожалуйста, опишите подробно вашу типичную конфигурацию сети (особенно при подключении через общедоступный wifi)
Дамиано Верзулли
Это в основном связано с использованием SIP поверх OpenVPN. Предположим, у вас есть 192.168.0.111/24 на вашем wlan0 и 10.10.10.5/30 на вашем tun0, подключенном к OpenVPN. Предположим, что сервер OpenVPN имеет дополнительную сеть 10.11.10.2/24 с Asterisk 10.11.10.1, и все необходимые маршруты передаются клиенту (проверка связи выполняется в обоих направлениях). Проблема в том, что SIP может решить направить пакеты с исходным IP-адресом вашего wlan0 на интерфейс tun0 вместо использования исходного IP-адреса tun0, и именно тогда вы получите проблему - звездочка будет думать, что вы NAT-ed, хотя это не так.
Jollyroger
@jollyroger: если я прав, вполне возможно иметь SIP-клиентов за NAT-блоками, поэтому в вашем OpenVPN-клиенте должна быть возможность использовать исходящий VPN-трафик NAT (оставляя интерфейс tun0). Есть ли какие-то конкретные причины, почему это не вариант для вас?
Дамиано Верзулли
Оно работает. но не является надежным (читай мой предыдущий комментарий) из-за природы SIP и глючных клиентов, и последний не меняется годами. Конечно, я могу включить принудительное проксирование всего трафика через мой сервер Asterisk, но это ограничивает возможности клиентов использовать только кодеки, поддерживаемые сервером, несмотря на то, что у них есть возможность направлять RTP-пакеты напрямую только при согласовании кодеков между клиентом.
Jollyroger
1

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

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

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

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

aditsu
источник