Как заставить сервер OpenVPN пересылать пакеты tun0 в локальную сеть?

Question

У меня есть три машины, которые я пытаюсь координировать через соединение TUN.

FREEBSD работает сервер OpenVPN (tun)
10.0.200.21/24 в локальной подсети
10.0.202.1/24 по VPN

REMOTE
Общественный IP
10.0.202.6/24 по VPN

WEBSERVER
10.0.200.31/24 в локальной подсети

Я могу получить REMOTE VPN от FREEBSD через OpenVPN, и соединение в порядке, но оно настроено неправильно. Когда я пытаюсь подключить REMOTE к WEBSERVER через набрав «IP - адрес s в WEBSERVER REMOTE браузер s, WEBSERVER недостижим. Это достижимо, если я присоединяю REMOTE к локальной подсети напрямую.

Я узнал следующее при устранении неполадок.

• REMOTE может свистеть FREEBSD и даже SSH к нему.
• Захват пакетов, настроенный на локальном порту FREEBSD не захватывает пакеты с или на REMOTE IP-адрес VPN 10.0.202.6. Таким образом, пакеты REMOTE не попадают в локальную подсеть.
• Файл openvpn.log на FREEBSD имеет следующую строку: GET INST BY VIRT: 10.0.200.31 [failed]

Таким образом, кажется, что OpenVPN не пересылает пакеты, полученные на устройстве TUN, на сетевой адаптер FREEBSD и в локальную подсеть.

У меня есть следующая строка в моем файле server.conf.
push "route 10.0.200.0 255.255.255.0"

Я попытался добавить эту строку, но это не помогло.
route 10.0.200.0 255.255.255.0

Вот таблица маршрутизации на FREEBSD

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.0.200.1         UGS         0     4306    re0
10.0.200.0         link#9             U           0    61582    re0
10.0.200.21        link#9             UHS         0       41    lo0
10.0.201.0         10.0.200.1         UGS         0        0    re0
10.0.202.0         10.0.202.2         UGS         0        0   tun0
10.0.202.1         link#12            UHS         0        0    lo0
10.0.202.2         link#12            UH          0        0   tun0
localhost          link#11            UH          0   193743    lo0

Я прочитал в Интернете о сообщении GET INST BY VIRT: 10.0.200.31 [failed] и для машин Linux было рекомендовано выполнить следующую команду.
echo 1 > /proc/sys/net/ipv4/ip_forward
Я боюсь запускать его, потому что я его не понимаю и не хочу FREEBSD в странную конфигурацию. Я также настоятельно предпочитаю решение, которое изменяет файл server.conf для автоматического создания необходимой конфигурации, чтобы он правильно управлялся и разрушался при закрытии OpenVPN.

Каково решение этой проблемы?

Answer 1

Нашел проблему. Оказывается, что FreeNAS, программное обеспечение устройства NAS, основанное на FreeBSD и которое я FREEBSD выше, для net.inet.ip.forwarding установлено в 0. Это можно просмотреть с помощью команды sysctl -a | grep net.inet.ip.forwarding . Чтобы пересылать пакеты, мне нужно было выполнить sysctl net.inet.ip.forwarding=1 .

Это изменение не сохраняется после перезагрузки. Я думаю, что мне, возможно, придется использовать файл /etc/rc.conf и установить gateway_enable="YES" , но до сих пор я обнаружил, что этот параметр не обрабатывается до перезагрузки, и, к сожалению, во FreeNAS rc.conf, кажется, перезаписывается при каждой перезагрузке. Может быть возможно записать эту переменную в /etc/defaults/rc.conf, которая должна хранить значения по умолчанию для системы и перезаписывается пользовательскими конфигурациями в rc.conf, но /etc/defaults/rc.conf Файл имеет предупреждение в верхней части, чтобы не редактировать его.

Таким образом, эта проблема не полностью решена, но, по крайней мере, я выяснил, что это за проблемы. Теперь, когда я понимаю это, я теперь замечаю проблему с входом в устройства веб-управления https в локальной подсети. Это будет еще одна проблема для решения.

Answer 2

Итак, ваш VPN-клиент имеет маршрут для доступа к сети 10.0.200.0/24 , а ваш VPN-сервер имеет маршрут. Но вопрос в том, есть ли у вашего веб-сервера 10.0.200.31 маршрут для доступа к сети 10.0.202.0/24 ?

Сделайте tcpdump на коробке freebsd. Я подозреваю, что вы увидите, что трафик с вашего хоста 10.0.202.6 перенаправлен, но вы не увидите никакого обратного трафика.