SSL connection timeout
- alexhell
- Unerledigt
-
-
Hat die VM Web Zugriff? .. mal rauspingen etc.
Auch das Datum der VM kann ne Rolle spielen (falsch eingestellt?)
-
ja, pingen kann ich ohne Probleme.
wie checke ich das Datum?
-
Einfach mal via SSH ein date abwerfen
-
-
Naja .. aber das sollte eigentlich fürs Zertifikat unerheblich sein, ging mir nur darum falls das Jahr verhunzt ist und das Datum außerhalb der Gültigkeit ist (Zerts sind ja dank Apple nur noch 12/14 Monate lang gültig)
-
kann es sein, dass das cert für die NAS gilt aber nicht für die VM?
-
Der o.g. Befehl wird doch von der VM aus abgegeben, oder? Die weiss vom NAS doch nix
-
Ich dachte, weil ich eine feste IP habe, mit der ich bei der fritzbox ankomme. Dann werden die Pakete auf die einzelnen Maschinen hinter der Fritzbox verteilt: NAS, Docker, VM etc.
Eine Frage: Beim Virtuellen Switch, muss ich da NAT einschalten oder nicht? Der Switch wird von der VM nicht erkannt, wenn NAT eingeschaltet ist. Aber man kann das nachträglich einschalten.
-
Weiss nicht was bei dir eingestellt ist, HOST,Bridge oder NAT Modus
-
bei VM?
Die bekommen doch automatisch eine IP-Adresse. Da geht Host oder NAT gar nicht?Ich dachte jetzt eher, ob der virtual switch vielleicht ohne NAT einen Port nicht durchreichen kann oder so.
-
was spuckt denn die vm hier aus?
openssl s_client -connect github.com:443
-
Code
Alles anzeigenCONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 312 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
das ist das feedback
-
Und wenn es auf dem QNAP ausgeführt wird?
Aus dem QNAP bekomm ich Tonnenweise Output. Wenn's auch mau auf dem QNAP aussieht, ist bei dir im Netzwerk was im Argen, wenns auf dem QNAP OK ist dann mags was am Vswitch oder Routing sein.
-
Code
Alles anzeigen[~] # openssl s_client -connect github.com:443 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 verify return:1 depth=0 C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com verify return:1 --- Certificate chain 0 s:C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com i:C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIFajCCBPGgAwIBAgIQDNCovsYyz+ZF7KCpsIT7HDAKBggqhkjOPQQDAzBWMQsw CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTAwLgYDVQQDEydEaWdp ... vMkXEPvNvv4t30K6xtpG26qmZ+6OiISBIIXMljWnsiYR1gyZnTzIg3AQSw4Vmw== -----END CERTIFICATE----- subject=C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 2804 bytes and written 376 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_128_GCM_SHA256 Session-ID: E93845AA4158290E42C85E749EA35A894F7C3CDFE06290D47197355E5111DAB5 Session-ID-ctx: Resumption PSK: D86A76557DFC8062EDD27AC25807F0487966953B4A45017D4DEC4E95C42C1E80 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - 3f 50 92 41 66 cd f7 ea-3e cc 0b 8e 2f 94 a2 42 ?P.Af...>.../..B 0010 - bf 39 7d 73 3e 9a ff 0e-ef 77 73 1d df 7e 84 fc .9}s>....ws..~.. Start Time: 1677518755 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_128_GCM_SHA256 Session-ID: FEE97EA0330B0CFC2438F07CC3917A70ED35D5B8BEC944676DCA69119B12596E Session-ID-ctx: Resumption PSK: 7A04CE8AA49DDF0D39B2C3CDD09C9A4340B7F803ACA3FEA8DEAF6543E83AFFE9 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - 28 57 d0 d4 df f9 9c e9-87 dd 75 8f 79 0a f1 fb (W........u.y... 0010 - 58 80 98 00 d0 ca e3 fd-fb 21 06 9f aa ff 8d 11 X........!...... Start Time: 1677518755 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK closed
-
Das sieht besser aus .. hmm
Grad mal auf ner UbuntuVM auf nem TBS-453DX ausprobiert.. spuckt ähnliches aus .. also keine Probleme (sorry nicht auf Deutsch gewechselt, sollte aber alles Lesbar sein)
pasted-from-clipboard.pngpasted-from-clipboard.png
Wird irgendwas am Router geblockt oder so ?
-
Erst einmal Danke für das geduldige "Aus der Nase ziehen"!!!
Bei mir sieht es ähnlich aus. Als bridged network habe ich Intel Gigabit Ethernet und nicht VirtIO.
Router blockt wohl nicht. VM kann selbständig Portfreigaben machen und einzelen Ports habe ich schon manuell fix geöffnet.
Kann natürlich sein, dass eine andere VM oder die NAS einen Port belegt... davon habe ich leider keine Ahnung.
-
VM kann selbständig Portfreigaben machen und einzelen Ports habe ich schon manuell fix geöffnet.
Portfreigaben? Wozu Portfreigaben? Du öffnest dein NAS für Zugriffen von außen aus dem Internet. Wer soll auf dein NAS Zugreifen? Ransomware?
Für das, was du vorhast, brauchst du keine Portfreigaben. Aber mit Portfreigaben auf das NAS gab es schon einige erfolgreiche Angriffe durch Erpressungssoftware, da Qnap Sicherheitsmängel hatte. Daher solltest du keine Portfreigaben im Router machen, es sei denn, du weißt genau, was du machst und kannst das Sicherheitsrisiko abschätzen.
(In Firmennetzen, wo auch ausgehende Verbindungen blockiert werden, sieht das anders aus. Aber so wie ich das sehe, hast du keine Firmenfirewall. Oder ist die Qnap-Firewall auf dem NAS eingeschaltet?)
Kann natürlich sein, dass eine andere VM oder die NAS einen Port belegt.
Doppelte Portbelegungen gibt es nicht, da die zweite Anwendung beim Versuch, den Port zu öffnen, eine Fehlermeldung erhält.
Doppelte IP-Adressen sind aber möglich und können zu einem solchen Fehlerbild führen.
Welche IP-Adresse hat deine VM? Die kannst du über ip address ermitteln.
Gibt es ein zweiten Gerät mit der Adresse im lokalen Netz (eventuell im Router schauen, der hat eine Liste)? Ist die Adresse manuell oder per DHCP vergeben? Liegt die Adresse im DHCP-Bereich des Routers? Ist es eine andere Adresse als die deines NAS?
Manchmal verschluckt sich der Router auch. Bei einer Fritzbox kann ein Reboot helfen. In hartnäckigen Fällen ist es nötig, das Gerät, das die Fritzbox unter Heimnetz->Netzwerk mit der IP deiner VM anzeigt, einmal manuell zu löschen.
-
Grds. vergibt der Router per DHCP die IP Adressen. Ich lege dann auf dem Router manuell fest, dass dieser Maschine dann immer die selbe IP vergeben wird.
Und ja, wenn z.B. 2x Port 80 oder 443 verlangt wird, kommt es zu einem Konflikt.
-
Aber die Richtung ist ja LAN>WAN und nicht WAN>LAN, da kann das NAT frei werkeln und Ports werden intern verwaltet.
Es geht ja hier darum das die VM aus irgendeinem Grund kein SSL Zertifikat von Github bekommt. Da sind eingehende Ports ja komplett egal.