☰

Невозможно подключиться к OpenVPN вне локальной сети

tag-icon • tag-icon linux networking router openvpn gentoo
Невозможно подключиться к OpenVPN вне локальной сети

Я настроил OpenVPN за роутером и переадресовал порт 1194. VPN использует подсеть 10.3.15.0/24и находится 192.168.1.14в локальной сети.

Работает, когда я подключаюсь локально или из домашней сети, подключаясь к публичному IP. Но не в других сетях, которые я пробовал.

Я не могу установить соединение с VPN и на клиенте получаю:

Mon Apr 20 13:50:42 2015 UDPv4 link local: [undef]
Mon Apr 20 13:50:42 2015 UDPv4 link remote: [AF_INET]83.***.***.***:1194
Mon Apr 20 13:51:42 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Apr 20 13:51:42 2015 TLS Error: TLS handshake failed
Mon Apr 20 13:51:42 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Apr 20 13:51:42 2015 Restart pause, 2 second(s)

Я подумал, что это может быть проблема с брандмауэром, вот из моего iptables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  10.3.15.0/24         anywhere             ctstate NEW

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Но я пробовал очистить таблицу, что не сработало. И при запуске tcpdump -qni any port 1194есть некоторая связь (в обоих случаях):

13:44:35.936684 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14
13:44:41.043704 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.063426 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.544690 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14

Я тоже заметил кое-что destination port unreachable, но эти ошибки исчезли.

Вот конфигурация моего сервера:

port 1194
proto udp
dev tun

ca openvpn_certs/host-ca.pem
cert openvpn_certs/host-cert.pem
key openvpn_certs/host-key.pem
dh openvpn_certs/dh1024.pem

server 10.3.15.0 255.255.255.0
route 10.3.15.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
push "remote-gateway 10.3.15.1"

client-to-client
max-clients 20

keepalive 10 120
comp-lzo

user nobody
group nobody

persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log

verb 11

Вот конфигурация моего клиента:

client
dev vpn
dev-type tun
proto udp
remote server.remote 1194
resolv-retry infinite
nobind
ns-cert-type server
persist-key
persist-tun
pull
ca certs/ca-host.pem
cert certs/cert-local.pem
key certs/key-local.pem
comp-lzo
verb 11

Сервер работает под управлением Alpine Linux, а клиент — под управлением Gentoo.

Я застрял и понятия не имею, где искать. Есть какие-нибудь идеи или рекомендации?

Спасибо!

решение1

Во-первых, я не уверен, какую версию OpenVPN вы используете, но 'remote-gateway' не является допустимой опцией в v2.3.2. Если вы используете более старую версию, проверьте локальную страницу руководства и удалите эту директиву, если необходимо.

СогласноOpenVPN вики, ошибка «Согласование ключа TLS не удалось...» почти всегда является результатом:

  1. Периметральный межсетевой экран в сети сервера отфильтровывает входящие пакеты OpenVPN (по умолчанию OpenVPN использует UDP или TCP-порт номер 1194).

    • В вашем случае это кажется маловероятным, но проверьте брандмауэр вашего маршрутизатора, чтобы убедиться.

  2. Программный брандмауэр, работающий на самом сервере OpenVPN, фильтрует входящие соединения на порту 1194.

    • Таблица фильтров, которую вы предоставили, выглядит нормально, если у вас обычно установлена ​​политика INPUT по умолчанию, чтобы принимать. В противном случае вам нужно разрешить порт UDP 1194:

      iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT

  3. Шлюз NAT в сети сервера не имеет правила переадресации порта TCP/UDP 1194 на внутренний адрес сервера OpenVPN.

  4. Конфигурация клиента OpenVPN не имеет правильного адреса сервера в своем конфигурационном файле. Директива remote в конфигурационном файле клиента должна указывать либо на сам сервер, либо на публичный IP-адрес шлюза сети сервера.

  5. Брандмауэр Windows блокирует доступ к бинарнику openvpn.exe. Возможно, вам придется добавить его в белый список (в список «Исключения»), чтобы OpenVPN работал.

Если у вас все еще есть проблемы, скорее всего, проблема в вашей инфраструктуре открытых ключей. Я не знаком с Alpine linux и не знаю, поставляется ли их пакет OpenVPN с easy-rsa, так что продолжайте изагрузить последнюю версиюи извлеките его в соответствующее место на вашем сервере и (предпочтительно) не подключенной к сети машине (ваш центр сертификации). Для простоты я предположу, что ваш сервер генерирует запросы для клиентов. В обеих системах перейдите в каталог, куда вы извлекли EasyRSA и...

cp vars.example vars
editor ./vars

В системе CA раскомментируйте и отредактируйте организационные поля соответствующим образом (EASYRSA_REQ_COUNTRY и т. д.). На сервере при желании измените "set_var EASYRSA_PKI" так, чтобы он указывал на соответствующее местоположение (например, /etc/openvpn/pki).

Сгенерировать запросы сертификатов на сервере:

./easyrsa init-pki
./easyrsa gen-req <your_server_name> nopass
./easyrsa gen-req <some_client_name> nopass

На несерверном устройстве создайте новый CA:

./easyrsa init-pki
./easyrsa build-ca

Скопируйте файлы .req в вашу систему CA, затем импортируйте и подпишите их:

./easyrsa import-req server /tmp/<your_server_name>.req
./easyrsa import-req client /tmp/<some_client_name>.req
./easyrsa sign-req server <your_server_name>
./easyrsa sign-req client <some_client_name>

Скопируйте недавно подписанные сертификаты, а также сертификат CA в соответствующее место на сервере и клиенте. Затем на сервере сгенерируйте параметры dh:

 ./easyrsa gen-dh

Наконец, скопируйте клиентский ключ на клиентский компьютер (если его там еще нет) и обновите свои конфигурации, указав новые расположения ключа и сертификата.

решение2

Убедитесь, что сертификат вашего сервера подписан с обозначением nsCertType=server (это устаревший вариант, который не используется по умолчанию, если вы использовали easyrsa3). В противном случае директива 'ns-cert-type server' в конфигурации вашего клиента приведет к сбою рукопожатия tls. Вместо этого используйте ' remote-cert-tls server'.

Связанный контент