Interner Proxy für VPN ohne public expose

[W0nderW0lf]

Ich habe dieses Adguard und Unbound konstrukt auf der OPNsense direkt.

[W0nderW0lf]

Hi again,
danke übrigens für die bisherige Hilfe.

ich habe mir meine DNS config nochmal genaustens angesehen. Ich hatte es bei meiner Wireguard Einrichtung neu angepasst.
Ich hatte mir dafür diesen Guide angesehen: https://windgate.net/setup-adguard-home-opnsense-adblocker/
Im prinzip habe ich es 1:1 wie dort beschrieben.

Nochmal um mein Verständnis wegen..
Wenn Unbound als DNS Server fungiert, muss dem ja irgendwie der FQDN genannt werden. Das mein DNS Query Request fehl schlägt, scheint ja dann eigentlich folglich richtig, weil meine subdomain ja kein Host an sich ist. Das ist nur eine eingestellte Subdomain die entweder als A-Record bei Cloudflare, oder bei Caddy als Subdomain hinterlegt ist. Wie bekommt mein DNS Server dann also mit wo genau die Adresse hinterlegt ist. Somit wird die Anfrage also an Cloudflare weitergeleitet, welcher dann die Antwort mit meiner Pub-IP zurück gibt.
Ich vermisse den Punkt an dem mein DNS Server merkt, dass es da local einen Proxy gibt der diese Antwort an den DNS Server weiter reicht.

Dadurch das ich bei meiner DNS/Adblock config nach mehrmaligen drüber gucken, keinen Fehler erkenne, muss es an dem fehlenden A Record liegen.
Ich habe händisch in Unbound>Überschreibungen>Host Überschreibungen einen A Record (ncloud.example.com = <opnsense IP>) angelegt, aber scheinbar wird das ignoriert. Ich erhalte weiterhin meine public IP "Standard query response, No error" als Antwort von unbound. Sofern ich den trace im Wireshark richtig lese. Ich weiß nicht ob der letzte Host, oder der erste Host mit der richtigen Antwort als Source angezeigt wird.

Ich habe bei mir im Unbound lediglich in DNS over TLS - 4 DNS Server gelistet.
Unter System>Einstellungen>Allgemein habe ich keinen DNS Server eingetragen.

Sonst noch eine idee?

[Monviech (Cedrik)]

Kein Problem, kann nur gerade nicht mehr helfen.

Ich benutze Unbound als rekursiven DNS Server ohne Schnickschnack. (Kein DNS over TLS, kein Adguard Home... etc...)

Wenn was nicht klappt einfach die Komplexivität verringern bis DNS richtig funktioniert.

[W0nderW0lf]

Ich habs gelöst.

Ich bin hier im Forum fündig geworden:
https://forum.opnsense.org/index.php?topic=23576.0

... in the Bootstrap DNS Servers under DNS Settings...

Code: [Select]

192.168.11.1:5353 (My firewall IP)
127.0.0.1:5353
Nachdem ich das bei mir eingetragen hab, hat der Zugriff mit lokalen IP's problemlos geklappt.

Jetzt hätte ich noch eine letzte Frage.
Wieso greift mein Header nicht? Hab ich den falsch formuliert? (Siehe Bild)

Danke nochmal für jede Hilfe. Ihr habt mir die entscheidenden Tipps gegeben.

[Monviech (Cedrik)]

Hallo super dass du weiterkommst.

Wegen dem Header, zeig mir bitte mal das Caddyfile.

[W0nderW0lf]

Ich habe vorerst nur den einen Header.

Code: [Select]

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# Global Options
{
log {
include http.log.access.37fc6c8b-42c2-41e0-baba-c38516660295
output net unixgram//var/caddy/var/run/log {
}
format json {
time_format rfc3339
}
}

dynamic_dns {
provider cloudflare <some token>
domains {
example.com *
}
}

email <redacted>
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


# Reverse Proxy Domain: "37fc6c8b-42c2-41e0-baba-c38516660295"
*.example.com {
log 37fc6c8b-42c2-41e0-baba-c38516660295
tls {
dns cloudflare <Token>
}

@3bc73ecf-09b3-40ed-9ae2-1a29fc02bca6 {
host ncloud.example.com
}
handle @3bc73ecf-09b3-40ed-9ae2-1a29fc02bca6 {
@0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
client_ip 100.65.0.0/24 192.168.1.0/24
}

handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up Strict-Transport-Security "max-age=15552000; "

fail_duration 30s
}
}
}
}
}

import /usr/local/etc/caddy/caddy.d/*.conf


[Monviech (Cedrik)]

Ich glaube das Problem ist das "; " am Ende. Da ist ein Leerzeichen, und ich weiß nicht ob das ; dort sein darf.

[W0nderW0lf]

Ich bin wiedermal ratlos.

Die Syntax schient wohl nix auszumachen, weil es eh nicht am Server ankommt. Ich bekomme aber noch mehr Fehler/Warnmeldeungen als vorher angezeigt.
Die Header in NGINX zu erstellen und zu nutzen war einfacher als das hier.

Was ich in der Einrichtungswarnung bei Nextcloud erhalte:

Code: [Select]

Einige Header sind in deiner Instanz nicht richtig eingestellt - Der HTTP-Header `X-Content-Type-Options` ist nicht auf `nosniff` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Robots-Tag` ist nicht auf `noindex,nofollow` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Frame-Options` ist nicht auf `sameorigin` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Permitted-Cross-Domain-Policies` ist nicht auf `none` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-XSS-Protection` enthält nicht `1; mode=block`. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `Referrer-Policy` ist nicht auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin" gesetzt. Dadurch können Verweisinformationen preisgegeben werden. Siehe die W3C Recommendation. - Der `Strict-Transport-Security`-HTTP-Header ist nicht gesetzt (er sollte mindestens `15552000` Sekunden betragen). Für erhöhte Sicherheit wird empfohlen, HSTS zu aktivieren. Weitere Informationen findest du in der Dokumentation ↗.
Was ich eingestellt habe:

Code: [Select]

handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up Referrer-Policy "no-referrer"
header_up Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
header_up X-Content-Type-Options "nosniff"
header_up X-Frame-Options "SAMEORIGIN"
header_up X-Permitted-Cross-Domain-Policies "none"
header_up X-Robots-Tag "noindex, nofollow"
header_up X-XSS-Protection "1; mode=block"

fail_duration 30s
}
}
}
Auf dem Server in den Logs finde ich z.B. sowas:

Code: [Select]

"reqId":"VUfbD1ANpY87CywcjSff","level":0,"time":"2024-06-24T07:38:13+00:00","remoteAddr":"172.17.0.1","user":"--","app":"webdav","method":"GET","url":"/remote.php/dav/",
"message":"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorizatio
n: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or
 the server is misconfigured","userAgent":"Nextcloud Server Crawler","version":"29.0.2.2","exception":{"Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Message":"No
 public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' he
ader found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server i
s misconfigured","Code":0,"Trace":[{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth
\\Plugin","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":456,"function":"em
it","class":"Sabre\\DAV\\Server","type":"->","args":["beforeMethod:GET",[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]]},{"file":"/var/www/html/3rdparty/sabre/dav/l
ib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/va
r/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/lib/Se
rver.php","line":374,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":35,"function":"ex
ec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/remote.php","line":172,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"re
quire_once"}],"File":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","Line":152,"message":"No public access to this resource., No 'Authorization: Basic' header
 found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mi
s-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured","exception":{},"CustomMessage":"No public access
to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Eit
her the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured
"}}

[Monviech (Cedrik)]

Ist bei der Nextcloud Trusted Proxies konfiguriert?

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

Wenn du Probleme mit den Headern hast, das ist jetzt gar nicht mehr so mein Gebiet. Vielleicht kannst du dort in der https://caddy.community bessere Hilfe finden.

[Monviech (Cedrik)]

Wobei ich glaube es fehlt das + bei dem Header. Aber unsicher hier. Gehe nur nach Anleitung

https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#headers

header_up +Some-Header "first value"

header_up +Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

[W0nderW0lf]

Das + scheint hier leider auch nicht zu helfen. Ich habe mir die Doku vorher auch mal angesehen. Ich bin auch unsicher, ob man vielleicht Header "ersetzen" bzw. mit seinem Header überschreiben muss.

header_down sets, adds (with the + prefix), deletes (with the - prefix), or performs a replacement (by using two arguments, a search and replacement) in a response header coming downstream from the backend.

Code: [Select]

handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up +Referrer-Policy "no-referrer"
header_up +Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
header_up +X-Content-Type-Options "nosniff"
header_up +X-Frame-Options "SAMEORIGIN"
header_up +X-Permitted-Cross-Domain-Policies "none"
header_up +X-Robots-Tag "noindex, nofollow"
header_up +X-XSS-Protection "1; mode=block"

fail_duration 30s
}

Proxy config

Code: [Select]

  'trusted_proxies' =>
  array (
    0 => '192.168.200.1', #Opnsense Interface für Unraid
  ),

Was ich leider bei Caddy in der GUI nicht finde, sind so Weiterleitungen wie diese hier aus der Nextcloud Doku:

Code: [Select]

   
    redir /.well-known/carddav /remote.php/dav/ 301
    redir /.well-known/caldav /remote.php/dav/ 301

Dafür das Caddy so einfach ist, ist es doch schon ganz schön kompliziert.

Interessant finde ich auch diese Meldung. Sowas hatte ich vorher mit NGINX nicht.

Code: [Select]

Dein Datenverzeichnis und deine Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, deinen Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass du es aus dem Document-Root-Verzeichnis des Webservers herausverschiebst.

[Patrick M. Hausen]

Was ich leider bei Caddy in der GUI nicht finde, sind so Weiterleitungen wie diese hier aus der Nextcloud Doku:

Code: [Select]

   
    redir /.well-known/carddav /remote.php/dav/ 301
    redir /.well-known/caldav /remote.php/dav/ 301


Das machst du ja auch in dem Webserver, unter dem deine Nextcloud-Instanz läuft und nicht auf dem vorgelagerten Reverse-Proxy.

[W0nderW0lf]

Da muss ich dir widersprechen.

The redirects for CalDAV or CardDAV does not work if Nextcloud is running behind a reverse proxy. The recommended solution is that your reverse proxy does the redirects.

Das gleiche hatte ich bei mir im NGINX auch drin gehabt.

[Patrick M. Hausen]

Quelle? Ich habe das genau so am laufen.

In Nginx:

Code: [Select]

        location = /.well-known/carddav { return 301 /remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /remote.php/dav/; }

Quelle: https://docs.nextcloud.com/server/29/admin_manual/installation/nginx.html

In Caddy auf der OPNsense hab ich einen Eintrag - externe Domain + Handler --> interne IP-Adresse, Port 80, keine Spezialitäten, gar nichts.

[W0nderW0lf]

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