Я установил 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.

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

Спасибо!

|источник

2 ответа2

1

Прежде всего, я не уверен, какую версию OpenVPN вы используете, но «remote-gateway» не является допустимым вариантом в v2.3.2. Если вы используете более старую версию, проверьте локальную справочную страницу и при необходимости удалите эту директиву.

Согласно OpenVPN wiki, ошибка «Сбой согласования ключа 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

На несерверном сервере создайте новый центр сертификации:

./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 params:

 ./easyrsa gen-dh

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

|источник
0

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .