OpenVPN, маршрутизация и IP-таблицы

Есть две вещи, которые вам нужно проверить и, возможно, исправить.

Во-первых, вам необходимо убедиться, что в ядре включена переадресация IP. Пересылка IP позволяет ядру передавать пакеты от одного интерфейса к другому. Вы можете проверить это следующим образом:

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Если вы видите 0 вместо 1, то вам нужно включить переадресацию IP. Самый простой и надежный способ - добавить следующую строку в /etc/sysctl.conf (или измените его, если уже есть запись для net.ipv4.ip_forward):

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

А потом беги sysctl -p чтобы перезагрузить конфигурацию из этого файла.

Далее вам нужно будет настроить IPtables выполнять трансляцию сетевых адресов (NAT) для пакетов, поступающих из VPN. В противном случае, когда эти пакеты будут отправлены eth0, любые устройства, которые получают пакеты, не будут знать, как отвечать (у них нет маршрута обратно к 192.168.3.0/24 через VPN-сервер). Существует два способа настройки NAT: статический NAT (SNAT) и маскарадный. SNAT рекомендуется, когда IP-адрес на исходящем интерфейсе (eth0 в вашем случае) не ожидается изменений. Режим Masquerade разработан для динамических IP-ситуаций, таких как коммутируемое соединение или другие динамически назначаемые конфигурации адресов (кабельные модемы, DSL и т. Д.). Но оба настроены одинаково.

Для SNAT вы должны добавить правило IPtables в соответствии с (обратите внимание, я использовал 192.168.2.13 потому что я не знаю IP, который вы назначили eth0; вы бы хотели изменить это по мере необходимости):

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.2.13

Если IP-адрес на eth0 не является статическим и надежным, вы должны использовать Masquerade, который будет выглядеть так:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Я не уверен, используете ли вы AWS, но убедитесь, что вы отключить проверку места назначения / источника на любом экземпляре AWS, который вы можете использовать для этого.

Щелкните правой кнопкой мыши на экземпляре, наведите указатель мыши на Сеть, тогда там должна быть опция.

Если это вам не поможет, надеюсь, поможет кому-то другому.

Вам нужно правило iptables для VPN-клиентов для доступа к сети.

Сначала убедитесь, что ваша система разрешает NAT:

# Setup sysctl to enable NAT.
echo "# Allowing nat translation for VPN clients.
net.ipv4.conf.default.forwarding=1
net.ipv4.ip_forward=1" > "/etc/sysctl.d/openvpn.conf"
# load new sysctl config.
command sysctl -p "/etc/sysctl.d/openvpn.conf" > '/dev/null'

Затем установите правило NAT iptables для сети VPN:

CURRENT_IP_RANGE="192.168.2"
command iptables -t nat -C POSTROUTING -s "${CURRENT_IP_RANGE}.0/24" \
                      -o 'eth0' -j MASQUERADE 2>'/dev/null' \
    || command iptables -t nat -A POSTROUTING -s "${CURRENT_IP_RANGE}.0/24" \
                       -o 'eth0' -j MASQUERADE

Эти правила являются выдержкой из openvpn-инструменты, представленные в Установите и настройте OpenVPN на Debian, сценарий управления OpenVPN и инструкции, которые я написал.

Убедитесь, что DNS-сервер доступен для ваших VPN-клиентов. Простой ответ - OpenDNS (8.8.8.8). Более сложное, но, возможно, лучшее решение - установить Bind на сервере (это решение используется openvpn-tools).

openvpn-tools может вас заинтересовать, поскольку он обеспечивает экспорт конфигурации клиентов для различных систем и автоматизирует настройку новых сетей VPN.

РЕДАКТИРОВАТЬ для сервера Openvpn 2.x и клиента 1.5

Видеть: Примечания к выпуску OpenVPN.

Чтобы OpenVPN 2.0 мог взаимодействовать с версиями 1.5 / 1.6, поместите это в конфигурационный файл 1.x:

tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
key-method 2

Для использования TLS теперь по умолчанию используется метод ключа 2.

В вашей ситуации вам следует попробовать использовать стандартную маршрутизацию вместо использования NAT (между внутренней сетью и сетью openvpn). NAT должен быть вашим последним вариантом.

«Граничный маршрутизатор» (вероятно, ваш CPE) (между вашей внутренней сетью и остальной частью Интернета) должен отправлять пакеты для узлов VPN (в 192.168.3.0/24) на открытый сервер. Вы должны добавить такой маршрут в граничный маршрутизатор / CPE:

# This is the Linux command, find the equivalent for your router:
ip route add 192.168.3.0/24 via 192.168.2.111

Теперь этот маршрутизатор может быть комбинированным маршрутизатором xDSL +, предоставленным FAI, поэтому вы не сможете это сделать.

Если вы не можете этого сделать (вы не можете добавлять маршруты на своем маршрутизаторе) и если ваш граничный маршрутизатор считает, что ваша внутренняя сеть - 192.168.0.0/16 (или, по крайней мере, содержит 192.168.3.0/34), вы можете настроить прокси ARP в eth0 для Узлы VPN в основной сети:

echo 1 > /proc/sys/net/ipv4/conf/$xx/proxy_arp

с x = eth0, x = tun0, x = all (я действительно не знаю, в каком интерфейсе вы должны установить эту опцию).

Идея состоит в том, что ваш сервер OpenVPN будет отвечать на запросы ARP в сети eth0 для узлов в VPN. Он будет работать только в том случае, если ваш маршрутизатор считает, что 192.168.3.0/24 находится во внутренней сети: в противном случае он не будет отправлять запросы ARP во внутреннюю сеть.