Keine Verbindung zu Adminforge mit VPN

Ich verwende Surfshark VPN. Wenn ich VPN aktiviere bekomme ich keine Verbindung zu adminforge.de und auch keine Verbindung zu gruble.de.

lösen denn die Domains auf?
Unter Windows mit „nslookup“ und Linux „dig“.

die Domains lösen im Terminal auf…aber

Der kriegt das mit den SSL-Ciphern nicht hin. Laut How to Fix the PR_END_OF_FILE_ERROR (5 Methods) kann es am VPN Anbieter liegen.

Kannst du mal ein „curl -vi https://gruble.de“ machen?

curl -vi https://gruble.de                                       ✔ 
* Host gruble.de:443 was resolved.
* IPv6: 2a01:4f8:13a:160c::232, 2a01:4f8:231:1726::33
* IPv4: 195.201.173.232, 159.69.72.33
*   Trying [2a01:4f8:13a:160c::232]:443...
*   Trying 195.201.173.232:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLS connect error: error:00000000:lib(0)::reason(0)
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to gruble.de:443 
* closing connection #0
curl: (35) TLS connect error: error:00000000:lib(0)::reason(0)

Was kommt denn wenn du direkt mit telnet auf den port gehst oder mit openssl s_client?

Dein VPN Anbieter scheint da irgendwas mit SSL zu machen. Hier ein Beispiel über meinen VPN Anbieter aber über einen Proxy da ich nicht immer im VPN hier bin. Sollte aber Vergleichbar sein:

curl -vI --proxy socks5://192.168.x.x:1080 https://gruble.de
*   Trying 192.168.x.x:1080...
* Host gruble.de:443 was resolved.
* IPv6: 2a01:4f8:231:1726::33, 2a01:4f8:13a:160c::232
* IPv4: 195.201.173.232, 159.69.72.33
* SOCKS5 connect to [2a01:4f8:231:1726::33]:443 (locally resolved)
* SOCKS5 request granted.
* Connected to 192.168.x.x () port 1080
* using HTTP/1.x
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=gruble.de
*  start date: Nov 21 22:54:54 2024 GMT
*  expire date: Feb 19 22:54:53 2025 GMT
*  subjectAltName: host "gruble.de" matched cert's "gruble.de"
*  issuer: C=US; O=Let's Encrypt; CN=E5
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to 192.168.x.x (192.168.x.x) port 1080
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://gruble.de/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: gruble.de]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.11.1]
* [HTTP/2] [1] [accept: */*]
> HEAD / HTTP/2
> Host: gruble.de
> User-Agent: curl/8.11.1
> Accept: */*

Habe gerade festgestellt, dass es bei manchen Server Standorten funktioniert, bei anderen nicht…

ah sehr gut. dann würde ich das dort mal melden. Wer weiß was die Standorte da mit dem SSL machen …