Frage zum Reverse-Proxy Zugangskontrollprofil

[mdawid]

Hallo Zusammen,

seit dem neusten DSM 6.2 update gibt es eine neue Funktion im Abschnitt Reverse-Proxy -> Zugangskontrollprofil. Sowie ich das richtig verstanden habe, kann man hierüber festlegen, welche IP-Addressen zugriff auf bestimmte dienste haben.

Ich wollte das mal probeweise für ein Docker-Image ausprobieren und habe folgedes erstellt:

Reverse-Proxy:
Protokoll: HTTPS
Hostname: subdomain.domain.de
Port: 443

[x] HSTS
[x] HTTP/2
[x] Zugangskontrolle aktivieren

Zugangskontrollprofil: "Local or VPN Network"

Ziel:
Protokoll: HTTP
Hostname: 192.168.1.X
Port: 12345



Das Zugangskontrollprofil ist wie folgt definiert:

192.168.1.0 -> Zulassen
10.10.0.0 -> Zulassen
Alle -> Verweigern

---

Wenn ich jetzt versuche über https://subdomain.domain.de auf den Docker-Container zuzugreifen, dann bekomme ich ein HTTP-Error 403 (Forbidden).

Wenn ich im Zugangskontrollprofil "Alle" auf Zulassen einstelle, dann habe ich Zugriff.

Ich habe beides aus dem lokalen LAN und von aussen (LTE) probiert und beide male hatte ich kein Zugriff.

Die Idee war, wie der Name schon sagt, das Docker-Image über die Subdomain im Lokalen Netz über SSL abrufen zu können, aber eben nicht von außen.

Hat damit schon jemand was probiert?

Grüße,

Michael

 

[TeXniXo]

Hab das noch nicht probiert und mich nicht damit beschäftigt.
Aber was mir in deinem Text auffällt ... --> 192.168.1.0 - mit "0" am Ende kriegst du ja nix? Probier mal die IP von dem Client, vor dem du grad sitzst, ob es damit klappt?

 

[mdawid]

Hab das noch nicht probiert und mich nicht damit beschäftigt.
Aber was mir in deinem Text auffällt ... --> 192.168.1.0 - mit "0" am Ende kriegst du ja nix? Probier mal die IP von dem Client, vor dem du grad sitzst, ob es damit klappt?

Ja, das habe ich bewusst gemacht, da man laut Beschreibung von synology da CIDR Masken eintragen kann. Eine dedizierte IP-Adresse einzutragen macht für mich keinen Sinn.

 

[TeXniXo]

Es geht hier ja, wie du selbst erwähnt hast, um einen Test und um Fehlerursachen zu minimieren wäre das ein möglicher Schritt. Sinn oder Unsinn - lassen wir hier mal außer acht.

 

[Fusion]

Solange du keinen lokalen DNS Server hast werden Anfragen via sub.domain.de als letzten Sender vermutlich die externe IP des Routers tragen und damit abgewiesen.
Kannst ja mal dessen aktuelle öffentliche IP noch in die Freigabe nehmen und schauen, ob es dann klappt.
Eine konkrete Quell-IP wäre der zweite Test wie von @TeXniXo vorgeschlagen.
Hast du die CIDR als 192.168.1.0/24 eingegeben oder nur 192.168.1.0? Er nimmt (dummerweise) beides ohne zu meckern, aber ob es damit wirksam ist ist die andere Frage.

 

[blurrrr]

Mal ganz kurz zum "Netzwerkteil"... die CIDR-Schreibweise "IST" das "/24", also einfach nur die Zählung der Netzwerkbits innerhalb der Subnetmaske... Einfach nur die Angabe der Netz-ID hilft da "überhaupt" nicht weiter.

Für ein typisches SOHO-Netz:

255.255.255.0 = 11111111.11111111.11111111.00000000 = 24 Bits für den Netzwerkanteil = CIDR : /24

Für einen einzelnen Host:

255.255.255.255 = 11111111.11111111.11111111.11111111 = 32 Bits für den Netzwerkanteil = CIDR : /32

Bei "nur"-Angabe einer IP bzw. Netz-ID wird das System trotzdem von einem einzelnen Host ausgehen, da - man glaubt es kaum - die "0" theoretisch auch eine Host-IP sein kann (ebenso die 255). Da kommt es eben auf die Netz-Größe an... Beispiel:

192.168.0.0/23
255.255.255.0 = 11111111.11111111.11111110.00000000 = 23 Bits für den Netzwerkanteil = CIDR : /23

Netzstart: 192.168.0.0
...
Netzende: 192.168.1.255 (Broadcast)

Somit sind 192.168.0.255 und 192.168.1.0 theoretisch auch noch als IP-Adressen vergebbar und das Netz hätte 512 verfügbare Adressen -> -2 (Netz-ID+Broadcast), verblieben 510 "nutzbare" IP-Adressen.

Soll heissen: gibt man keine Netzwerkmaske an (egal in welcher Schreibweise), hat das System keinerlei Chance zu erkenne,, um was für eine Netzgrösse es sich handelt. Wenn irgendwo Eingabefelder bzgl. "einer" IP sind, dann braucht man meist auch nur eine IP einzutragen, aber das System wird schlussendlich eine entsprechende Netzwerkmaske anhängen bzw. eben von der /32 oder 255.255.255.255 ausgehen. Ein Netz kann man somit nicht einfach mit einer IP angeben, sondern es muss "zwingend" immer die Subnetmaske (egal in welcher Schreibweise) mit angegeben werden. Alternativ Netz-ID+Broadcast, daraus lässt sich auch die Subnetmaske errechnen.

 

[mdawid]

Solange du keinen lokalen DNS Server hast werden Anfragen via sub.domain.de als letzten Sender vermutlich die externe IP des Routers tragen und damit abgewiesen.
Kannst ja mal dessen aktuelle öffentliche IP noch in die Freigabe nehmen und schauen, ob es dann klappt.
Eine konkrete Quell-IP wäre der zweite Test wie von @TeXniXo vorgeschlagen.
Hast du die CIDR als 192.168.1.0/24 eingegeben oder nur 192.168.1.0? Er nimmt (dummerweise) beides ohne zu meckern, aber ob es damit wirksam ist ist die andere Frage.

Ich hab einen DNS server im lokalen Netz, der subdomain.domain.de auf die IP meiner DS auflöst . Sorry hab ich vergessen zu erwähnen.

Wenn ich auf meiner Windows 10 maschine ein nslookup mache, dann wird auch die IP der DS angezeit.

@blurrrr
Ich hab die IP-Adresse zunächst ohne subnetz maske angegeben (192.168.1.0), hab es jetzt auch mit der /24 notation versucht (192.168.1.0/24) aber auch das führt zum 403-Fehlercode.

@TeXniXo
Gerade habe ich die konkrete IP angegeben und auch das hat auch nicht geklappt. Bin gerade nicht zu hause, deßhalb versuche ich es aus dem VPN-Netz (10.10.0.0).

Mein PC (aus dem VPN netz IP=10.10.0.5).
Zugangskontrollprofil:
10.10.0.0/16 -> Zulassen
Alles -> Verweigern
-> ergebnis: 403

Mein PC (aus dem VPN netz IP=10.10.0.5).
Zugangskontrollprofil:
10.10.0.5 -> Zulassen
Alles -> Verweigern
-> ergebnis: 403

Kann sein, dass es am VPN liegt. Kann es nachher nochmal aus dem Heimnetz probieren.

 

[blurrrr]

Dürfen Clients aus dem VPN-Netz denn überhaupt den DNS-Server abfragen? (Einstellung am DNS-Server!)

 

[mdawid]

@ blurrrr
Ja dürfen sie, sonst würde ich ja die domaine nicht auf die lokale IP der DS auflösen.

Ich hab jetzt ein wenig herumgespielt, und es scheint, also ob es was mit den HSTS und HTTP/2 Einstellungen zu tun hat. Ich hab jetzt HTTP/2 abgeschaltet und nur HSTS drin, damit schein es zu gehen.

Btw, es handelt sich um einen subsonic docker-container, auf den ich umleiten möchte.

 

[blurrrr]

Sorry, siehste, wieder nur halb gelesen während der Arbeit

 

[diver68]

Dürfen Clients aus dem VPN-Netz denn überhaupt den DNS-Server abfragen? (Einstellung am DNS-Server!)

Kannst Du das freundlicherweise nochmal näher erklären? Würde mich interessieren.

Besten Dank im Voraus

 

[blurrrr]

Kannst doch die "Quell-IPs" beschränken - Haken rein und nix eintragen, wäre da schon etwas unvorteilhaft, so war es gemeint
(Firewall wäre nebst dem halt auch noch ein entsprechendes Thema)