Ich benutzePiVPNauf meinem Xubuntu-Server, um ein VPN zu erstellen. Ich weiß, dass PiVPN speziell für Raspberry Pis entwickelt wurde, aber es ist sehr einfach einzurichten und zu bedienen, also habe ich beschlossen, es auch auf meinem Xubuntu x64-Rechner zu verwenden.
Die Verbindung über .ovpn-Dateien funktioniert unter Windows mit OpenVPN Connect einwandfrei, beim Verbindungsversuch auf einem meiner drei Pop!_OS-Rechner (Ubuntu 22.04) kommt jedoch keine Verbindung zustande.
Hier ist die .ovpn-Datei:
client
dev tun
proto udp
remote myserv.org 1194
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name myveryspecialx509name name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 5
<ca>
-----BEGIN CERTIFICATE-----
s0m3c3rt1f1c4t3
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
s0m3d1ff3r3n7c3r71f1c473
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
s0m3pr1v473k3y
-----END ENCRYPTED PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
s0m3st4t1ck3y
-----END OpenVPN Static key V1-----
</tls-crypt>
Hier ist meine Syslog-Ausgabe auf meinem Pop!_OS-Client beim Versuch, über den Netzwerkmanager mithilfe der OVPN-Datei und den Standardeinstellungen eine Verbindung herzustellen:
Aug 22 19:39:05 ben NetworkManager[821]: <info> [1661189945.9755] vpn[0xd34db33f,blahblahblah,"blah"]: starting openvpn
Aug 22 19:39:05 ben NetworkManager[821]: <info> [1661189945.9762] audit: op="connection-activate" uuid="blahblahblah" name="blah" pid=31467 uid=1000 result="success"
Aug 22 19:39:09 ben nm-openvpn[31529]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Aug 22 19:39:09 ben nm-openvpn[31529]: OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Aug 22 19:39:09 ben nm-openvpn[31529]: library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
Aug 22 19:39:09 ben nm-openvpn[31529]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 22 19:39:09 ben nm-openvpn[31529]: TCP/UDP: Preserving recently used remote address: [AF_INET6]some:ipv6:address:1194
Aug 22 19:39:09 ben nm-openvpn[31529]: UDP link local: (not bound)
Aug 22 19:39:09 ben nm-openvpn[31529]: UDP link remote: [AF_INET6]some:ipv6:address:1194
Aug 22 19:39:09 ben nm-openvpn[31529]: NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Aug 22 19:39:09 ben nm-openvpn[31529]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Aug 22 19:40:09 ben nm-openvpn[31529]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug 22 19:40:09 ben nm-openvpn[31529]: TLS Error: TLS handshake failed
Aug 22 19:40:09 ben nm-openvpn[31529]: SIGUSR1[soft,tls-error] received, process restarting
Aug 22 19:40:09 ben NetworkManager[821]: <warn> [1661190009.4674] vpn[0xd34db33f,blahblahblah,"blah"]: connect timeout exceeded
Aug 22 19:40:09 ben nm-openvpn-serv[31515]: Connect timer expired, disconnecting.
Aug 22 19:40:09 ben nm-openvpn[31529]: SIGTERM[hard,init_instance] received, process exiting
Grundsätzlich trennt der Client die Verbindung nach 60 Sekunden einfach mit der Meldung, dass ein TLS-Handshake fehlgeschlagen ist.
Ich kann bestätigen, dass dies auf einem Windows-Computer mit OpenVPN-Verbindung einwandfrei funktioniert und dass Port 1194/UDP sowohl auf meiner Software als auch auf der Firewall meines Hardwareservers geöffnet und zugänglich ist.
Jede Hilfe wird sehr geschätzt.
Antwort1
Wenn die TLS-Schlüsselverhandlung nicht innerhalb von 60 Sekunden zustande kam, würde ich zunächst vermuten, dass irgendwo Pakete verloren gehen. Die Konfigurationsdatei und die Protokolldatei geben darüber keinen Aufschluss. Sie müssen dies mit tcpdump und/oder Wireshark untersuchen.