Author Topic: Interner Proxy für VPN ohne public expose (Read 3165 times)

Monviech (Cedrik) · « **Reply #30 on:** June 24, 2024, 12:17:01 pm »

Caddy ist einfach wenn man Standard will, weil es vieles automatisch macht.

Wie bei allem kann es auch hier schnell kompliziert werden wenn es um mehr als den reinen Standard geht. Webroot ändern, header, redirects, rewrites etc... geht. So wie bei nginx und apache2 auch.

Was dann einfach oder schwer ist, entscheidet jeder für sich.

Dass es mit den Headern nicht klappt ist wahrscheinlich irgend ein Logikfehler aber ich kenne mich hier zu wenig aus. Wenn es aber eine Schwäche der Template generierung vom Caddyfile ist, kann ich es beheben wenn ich weiß was der Fehler ist.

EDIT: Redirects sind in der Caddy GUI (noch nicht) eingebaut. Hat bisher keiner auf github gefragt.

EDIT2: Ich frage wegen den headern mal die Caddy Entwickler ob das so stimmt oder nicht.

Patrick M. Hausen · « **Reply #31 on:** June 24, 2024, 12:20:17 pm »

Quote from: W0nderW0lf on June 24, 2024, 12:15:10 pm

Steht hier in Service Discovery als erstes drin

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies

Halte ich für Quatsch:

Code: [Select]

$ curl -v https://**********/.well-known/carddav
* Host **********:443 was resolved.
* [HTTP/2] [1] OPENED stream for https://**********/.well-known/carddav
< HTTP/2 301 
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 10:17:49 GMT
< location: http://**********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162
< 
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host ********** left intact

Monviech (Cedrik) · « **Reply #32 on:** June 24, 2024, 02:50:00 pm »

Ich habe eine Antwort von den Caddy Maintainern:

- Security headers sind wie ein Vertrag zwischen Browser und Web Applikation. Sie sollten also in der Nextcloud direkt gesetzt werden. Für den Reverse Proxy sind sie dann transparent.
- Wenn das aus irgend einem Grund nicht geht, sollte "header_down" verwendet werden. Aber das ist unnötig, da diese Header immer in der Applikation selbst gesetzt werden sollen.

Patrick M. Hausen · « **Reply #33 on:** June 24, 2024, 02:50:59 pm »

Danke. Siehe meinen CURL-output.

W0nderW0lf · « **Reply #34 on:** June 24, 2024, 05:01:55 pm »

Quote from: Patrick M. Hausen on June 24, 2024, 12:20:17 pm

Halte ich für Quatsch:

Code: [Select]
$ curl -v https://**********/.well-known/carddav * Host **********:443 was resolved. * [HTTP/2] [1] OPENED stream for https://**********/.well-known/carddav < HTTP/2 301 < alt-svc: h3=":443"; ma=2592000 < content-type: text/html < date: Mon, 24 Jun 2024 10:17:49 GMT < location: http://**********/remote.php/dav/ < referrer-policy: no-referrer < server: Caddy < server: nginx < strict-transport-security: max-age=15768000; includeSubDomains; preload < x-content-type-options: nosniff < x-frame-options: SAMEORIGIN < x-permitted-cross-domain-policies: none < x-robots-tag: noindex, nofollow < x-xss-protection: 1; mode=block < content-length: 162 < <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html> * Connection #0 to host ********** left intact

Ich hab's mir ja nicht aus dem Finger gesaugt. ^^ Wenn das offiziell so dokumentiert ist, gehe ich auch davon aus das die schon wissen warum sie das schreiben.

Mein Curl sieht ähnlich aus wie deiner. Keine Fehler. Und das ist auch das was mich stutzig macht. Den aufruf mache ich über den weg von innen. Wenn ich aber über den Browser navigiere sieht das wieder anders aus.

Code: [Select]

curl -v https://ncloud.example.com/.well-known/carddav
* Host ncloud.example.com:443 was resolved.
* IPv6: (none)
* IPv4: 192.168.1.1
*   Trying 192.168.1.1:443...
* Connected to ncloud.example.com (192.168.1.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* 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_128_GCM_SHA256 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.example.com
*  start date: Jun 21 13:40:44 2024 GMT
*  expire date: Sep 19 13:40:43 2024 GMT
*  subjectAltName: host "ncloud.example.com" matched cert's "*.example.com"
*  issuer: C=US; O=Let's Encrypt; CN=E5
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 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
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://ncloud.example.com/.well-known/carddav
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: ncloud.example.com]
* [HTTP/2] [1] [:path: /.well-known/carddav]
* [HTTP/2] [1] [user-agent: curl/8.8.0]
* [HTTP/2] [1] [accept: */*]
> GET /.well-known/carddav HTTP/2
> Host: ncloud.example.com
> User-Agent: curl/8.8.0
> Accept: */*
> 
* Request completely sent off
< HTTP/2 301 
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html; charset=iso-8859-1
< date: Mon, 24 Jun 2024 11:08:10 GMT
< location: http://ncloud.example.com/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: Apache/2.4.59 (Debian)
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 335
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://ncloud.example.com/remote.php/dav/">here</a>.</p>
<hr>
<address>Apache/2.4.59 (Debian) Server at ncloud.example.com Port 80</address>
</body></html>
* Connection #0 to host ncloud.example.com left intact

Ich habe nochmal ein wenig verglichen und frage mich, ob das ein Fehler seitens Caddy, oder ein fehler meinerseits ist.

Wenn ich die Access Liste entferne, den HSTS Header über "header_down" nachreiche und wieder von außen auf Nextcloud zugreife, erhalte ich keine Warnmeldung.
Alle Header werden Ordnungsgemäß angezeigt. die .htaccess Warnmeldung verschwindet und ich habe keine Fehler mehr.

Nur wenn ich die Access Liste wieder rein nehme erhalte ich wieder massig Fehler und warnings über den Browser angezeigt.

Monviech (Cedrik) · « **Reply #35 on:** June 24, 2024, 06:28:24 pm »

@Patrick

Kannst du testen ob es bei dir auch passiert, wenn eine Access List die Nextcloud einschränkt, dass es die Header Probleme gibt?

Meine Nextclouds sind leider in der Cloud (lol) und sind in einem Plesk. Kann es grade nicht richtig testen.

Patrick M. Hausen · « **Reply #36 on:** June 24, 2024, 09:11:04 pm »

Von innen, ohne Access List, IP-Adresse ist aber natürlich die externe IP der OPNsense:

Code: [Select]

< HTTP/2 301 
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 19:04:57 GMT
< location: http://*********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162

Dasselbe mit Access List:

Code: [Select]

< HTTP/2 301 
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 19:07:41 GMT
< location: http://*********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162

Also: same same. Ich habe auch keine header_down Konfiguration oder sonst etwas. Alle Header und die Redirects für die Service Discovery ist im Nginx der Nextcloud konfiguriert, wie es m.E. sein sollte. Die Caddy Config ist die einfachst mögliche, Domain, Handler, aus.

Einziger möglicher Unterschied: ich verwende zwischen Caddy und den Backends nach Möglichkeit kein HTTPS sondern Plain HTTP. In einem 100% geswitchten VLAN basierten Netz soll mir mal einer zeigen, wie er von einer gehackten Maschine den Traffic zwischen Caddy und einer anderen Maschine abgreifen will

Und ich muss mich im Backend nicht mit Zertifikaten rumärgern. Die sind ja alle in isolierten Netzen. Und dann hab ich zum Teil Java-Anwendungen und SSL mit Java ist so eklig ... ne ne ne, das darf alles der Reverse Proxy machen.

Monviech (Cedrik) · « **Reply #37 on:** June 24, 2024, 09:59:40 pm »

Danke fürs testen.

Im reverse proxy hab ich kein TLS aktiviert gesehen, also fällt der unterschied weg.

Dann ist was in der Nextcloud falsch konfiguriert.

Aber ich denke jetzt sind wir hier am Ende angelangt. Viel helfen kann ich nicht mehr da es ja grundsätzlich funktioniert wenn die Infrastruktur zu stimmen scheint.

W0nderW0lf · « **Reply #38 on:** June 25, 2024, 07:33:05 am »

Vielen Dank nochmal für das Testen und die bisherige Hilfe.

Die Verschlüsselung kann vielleicht ein Grund sein für das Problem. Auf der anderen Seite wollte ich lediglich meine Weiche von außen nach innen verlegen, ohne großartig was umzustellen, bis auf eben die FW. Meine Nextcloud war im Grunde schon gut voreingestellt. Also ich musste wenig bis gar nichts konfigurieren. Es funktioniert ja an sich. Ich erhalte nur eben die Fehlermeldungen. Ich muss das ganze nochmal ein bisschen im Detail analysieren. Aber fraglich ob ich hier im Forum weitere Hilfe zu dem Thema erhalte, weil vermutlich sonst niemand so eine konfiguration auf die Beine gestellt hat.

Ich persönlich hasse Zertifikats Warnungen und "Ausnahmen". Es ist einfach ein nice to have, eine funktionierende Verschlüsselung innerhalb des eigenen Netzes zu haben. Gibt mir halt ein gutes Gefühl nach all den Jahren der Unsicherheit.

W0nderW0lf · « **Reply #39 on:** June 25, 2024, 09:34:26 am »

Sorry für den Spam hier, aber erst jetzt sehe ich diesen Error im Caddy.

Code: [Select]

	"error","ts":"2024-06-25T06:53:33Z","logger":"http.log.access.37fc6c8b-42c2-41e0-baba-c38516660295","msg":"handled request","request":{"remote_ip":"100.65.0.10","remote_port":"47471","client_ip":"100.65.0.10","proto":"HTTP/1.1","method":"PROPFIND","host":"ncloud.example.com","uri":"/remote.php/dav/files/odin/","headers":{"Cookie":["REDACTED"],"Content-Length":["107"],"Content-Type":["text/xml; charset=UTF-8"],"Depth":["0"],"Authorization":["REDACTED"],"User-Agent":["Mozilla/5.0 (Android) Nextcloud-android/3.29.0"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"","server_name":"ncloud.example.com"}},"bytes_read":0,"user_id":"","duration":3.001101121,"size":0,"status":502,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}

"status":502,"resp_headers" = Bad Gateway

Ich denke damit kann ich erstmal arbeiten.

Author Topic: Interner Proxy für VPN ohne public expose (Read 3165 times)

Monviech (Cedrik)

Re: Interner Proxy für VPN ohne public expose

Patrick M. Hausen

Re: Interner Proxy für VPN ohne public expose

Monviech (Cedrik)

Re: Interner Proxy für VPN ohne public expose

Patrick M. Hausen

Re: Interner Proxy für VPN ohne public expose

W0nderW0lf

Re: Interner Proxy für VPN ohne public expose

Monviech (Cedrik)

Re: Interner Proxy für VPN ohne public expose

Patrick M. Hausen

Re: Interner Proxy für VPN ohne public expose

Monviech (Cedrik)

Re: Interner Proxy für VPN ohne public expose

W0nderW0lf

Re: Interner Proxy für VPN ohne public expose

W0nderW0lf

Re: Interner Proxy für VPN ohne public expose