OpenVPN istemcisinde 'TLS Hatası: TLS anlaşması başarısız' düzeltildi


16

Genel İnternet üzerinden SMB trafiğini şifrelemek için Arch Linux sunucumda OpenVPN 2.3.6-1'i yapılandırıyorum. Ben Linux sanal makine müşterilerinden biri üzerinde kurulumu test, ben hatayı alıyorum: TLS Error: TLS handshake failed.

Hızlı bir şekilde okudum ( OpenVZ TLS'de OpenVPN Hatası: TLS anlaşması başarısız oldu (google önerilen çözümler yardımcı olmadı) ) ve varsayılan UDP'den TCP'ye geçmeye çalıştı, ancak bu sadece istemcinin bağlantının zaman aşımına uğradığını sürekli olarak bildirmesine neden oldu. Ayrıca şifre ve TLS kimlik doğrulamasını devre dışı bırakmayı denedim, ancak sunucunun başarısız olmasına neden oldu Assertion failed at crypto_openssl.c:523. Her iki durumda da, istemci ve sunucu yapılandırmalarında gerekli değişiklikler yapıldı.

Ben adresindeki talimatları (takip ediyorum https://wiki.archlinux.org/index.php/OpenVPN (en OpenVPN kadar sete) ve talimatları https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts ) anahtarlar ve sertifikalar oluşturmak için. Bu talimatlardan yaptığım tek sapmalar kendi bilgisayarlarımın isimlerini ve karşılık gelen anahtar / sertifika dosya isimlerini belirtmektir.

Ayrıca, İnternet üzerinden KOBİ trafiğini güvence altına alma hakkındaki orijinal soruma bakın: ( Samba paylaşımları için basit şifreleme )

Herkes bu sorunu nasıl çözebileceğimi açıklayabilir mi?

Detaylar:

Sunucu: Ethernet kablosu ile doğrudan ağ geçidine bağlı Arch Linux (güncel). Iptables yok.

İstemci: VirtualBox 4.3.28r100309 Windows 8.1 ana bilgisayarında, köprülü ağ bağdaştırıcısında Arch Linux (güncel) sanal makine. Iptables yok. Windows Güvenlik Duvarı devre dışı.

Gateway: Port 1194 için port yönlendirme etkin, güvenlik duvarı kısıtlaması yok.

Sırasıyla sunucu ve istemcideki yapılandırma dosyaları şunlardır. Bunları Arch Wiki'deki talimatlara göre oluşturdum.

/etc/openvpn/server.conf (Yalnızca yorum yapmayan satırlar):

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server-name.crt
key /etc/openvpn/server-name.key
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

/etc/openvpn/client.conf (Yalnızca yorum yapmayan satırlar):

client
dev tun
proto udp
remote [my public IP here] 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client-name.crt
key /etc/openvpn/client-name.key
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 1
comp-lzo
verb 3

Yukarıdaki yapılandırmalara sahip makinelerde openvpn çalıştırmanın çıktıları. Önce sunucuyu, sonra istemciyi başlattım.

openvpn /etc/openvpn/server.confSunucudaki çıktı :

Thu Jul 30 17:02:53 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 17:02:53 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 17:02:53 2015 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jul 30 17:02:53 2015 Diffie-Hellman initialized with 2048 bit key
Thu Jul 30 17:02:53 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 17:02:53 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 17:02:53 2015 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp5s0 HWADDR=##:##:##:##:##:##
Thu Jul 30 17:02:53 2015 TUN/TAP device tun0 opened
Thu Jul 30 17:02:53 2015 TUN/TAP TX queue length set to 100
Thu Jul 30 17:02:53 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 30 17:02:53 2015 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Jul 30 17:02:53 2015 /usr/bin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Thu Jul 30 17:02:53 2015 /usr/bin/ip route add 10.8.0.0/24 via 10.8.0.2
Thu Jul 30 17:02:53 2015 GID set to nobody
Thu Jul 30 17:02:53 2015 UID set to nobody
Thu Jul 30 17:02:53 2015 UDPv4 link local (bound): [undef]
Thu Jul 30 17:02:53 2015 UDPv4 link remote: [undef]
Thu Jul 30 17:02:53 2015 MULTI: multi_init called, r=256 v=256
Thu Jul 30 17:02:53 2015 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Thu Jul 30 17:02:53 2015 IFCONFIG POOL LIST
Thu Jul 30 17:02:53 2015 Initialization Sequence Completed

openvpn /etc/openvpn/client.confİstemcinin çıktısı :

Thu Jul 30 21:03:02 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 21:03:02 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/client-name.key' is group or others accessible
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/ta.key' is group or others accessible
Thu Jul 30 21:03:02 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 21:03:02 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 21:03:02 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu Jul 30 21:03:02 2015 UDPv4 link local: [undef]
Thu Jul 30 21:03:02 2015 UDPv4 link remote: [AF_INET][my public IP here]:1194
Thu Jul 30 21:04:02 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 30 21:04:02 2015 TLS Error: TLS handshake failed
Thu Jul 30 21:04:02 2015 SIGUSR1[soft,tls-error] received, process restarting
Thu Jul 30 21:04:02 2015 Restart pause, 2 second(s)

1
İstemciniz sunucudan hiçbir zaman yanıt almaz. Unutmuş olduğunuz bir güvenlik duvarınız var veya bağlantı noktası yönlendirmeniz çalışmıyor.
Michael Hampton

2
tcpdump -ni eth0 udp and port 1194 Sunucuda : gibi bir paket koklaması yapın ve paketlerin gelip gelmediğinden emin olun. Varsa, güvenlik duvarı bırakma paketleri ile ilgili bir sorun olabilir, eğer hayırsa, büyük olasılıkla yönlendiricide bağlantı noktası iletme ile ilgili bir sorun vardır. Bunu yönlendiricide de yapabilirsiniz. Bir şans verin ve daha yüksek bir bağlantı noktası kullanmayı deneyin, bu yaygın değildir, ancak ISS'niz 11194 / UDP veya 53 / UDP bağlantı noktası gibi bir şey dağıtır.
Michal Sokolowski

Evet, yönlendirme buydu. Genellikle UDP ile çalışmıyorum, bu yüzden kuralı oluştururken protokolü değiştirmeyi unuttum. Bunu cevap olarak göndereceğim.
Kyle

3
Paketler sunucuda tcpdump içinde görünüyorsa, openvpn'e düzgün bir şekilde ulaşmalarını sağlamanın bir yolu var mı?
Joost

Yanıtlar:


9

Ben de bu problemi yaşadım.

Sunucum için digitalocean sağlayıcı kullanıyorum ve sorun kayan ip özelliği ile oldu.

Bunu düzeltmek için openvpn yapılandırma ayarını güncellemelisiniz:

local <ip anchor>

ip bağlantısı, ip addrkomuttan toplanan bir ip adresi olmalıdır , örneğe bakın: resim açıklamasını buraya girin

Bu gönderiye verilen krediler


Bu sorunu bir pfsense cihazında da yaşadım. local <ip address of VPN server>Sunucuyu sunucu yapılandırmasına eklemek düzeltti. TCP için bu girişin gerekli olmadığını, hatayı vermek için sadece UDP olduğunu unutmayın.
Vincenzo Pii

5

Michael Hampton ve Michal Sokolowski'nin sorum hakkındaki yorumlarda önerdiği gibi, ağ geçidimde oluşturduğum liman yönlendirme kuralı ile ilgili bir problemdi. OpenVPN UDP kullanacak şekilde yapılandırılmıştır ve genellikle bu protokolü kullanmadığım için ağ geçidinde TCP'den UDP'ye geçmeyi unuttum. Yönlendirme kuralı artık UDP kullanıyor ve VPN'im çalışıyor.


0

İşletim sistemi çekirdeğini güncelledikten sonra görünürse. Veya gelen paketler sunucuda tcpdump içinde görünür, ancak yine de çalışmaz. Basit bir güvenlik duvarı devre dışı bırakma / etkinleştirme deneyin. Belki biri yardım eder.

sudo ufw disable
sudo ufw enable


0

Sunucu tarafında yanlış yapılandırılmış bir varsayılan ağ geçidi nedeniyle bu sorunu alıyordum. OpenVPN sunucusu istemciden bağlantı denemesi alıyordu, ancak yanıt hiçbir zaman doğru yönlendiriciye ulaşmadığı için kaybediliyordu.


Bunu nerede değiştirmek zorunda olduğunuzu hatırlıyor musunuz? Bu içeride miydi etc/openvpn/server.conf?
Arthur Attout

Sunucu tarafında yönlendirme tabloları ile bir şey yanlış olduğunu düşünüyorum. İle kontrol edin ip route.
lanoxx

0

Sadece bu problemi yaşadım. .Ovpn dosyamı kontrol ederken? .Ddns.net'in bir IP adresine değiştirildiğini gördüm, bu yüzden bağlanmadı. IP'yi? .Ddns.net adresine geri değiştirdim ve bağlandı.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.