Lokale custom DNS records met poort

[Homewrecker]

Hey,

Ik heb op mijn NAS x-aantal services draaien op verschillende poorten.
Ik zou voor elke service een aparte DNS entry willen zodat op heel mijn netwerk elke service met DNS naam kan aangesproken ipv telkens ip:poort te hoeven ingeven.

Ik had al gezien dat er veel gebruik gemaakt word van Nginx proxy manager, maar werkt dit ook lokaal?
Ik heb een basic Unifi setup met Pi-hole.

Alvast bedankt
Groeten

[Frogmen]

lokaal zal je altijd ook het IP adres moeten opgeven afhankelijk van je hele netwerk setup is een device ook onder zijn naam te bereiken. Kan mij voorstellen dat je in je PI hole ook DNS entries kan zetten.
Uiteraard kan je ook met een reverse proxy gaan werken maar dan maak je het complex zeker als het allemaal op 1 device werkt.
Overigens gezien je vraag zou ik me eerst nog goed in de materie verdiepen met betrekking tot DNS poorten etc.

[Ozzie]

DNS lost alleen het probleem op dat je een ip-adres moet intypen. Poortnummers zal je dan zelf iets voor moeten bedenken. Als je wil dat je iets in de browser kan benaderen zonder poortnummer zal er iets op poort 80 (HTTP) of port 443 (HTTPS) moeten draaien.

[Homewrecker]

Frogmen schreef op dinsdag 5 oktober 2021 @ 13:27:
lokaal zal je altijd ook het IP adres moeten opgeven afhankelijk van je hele netwerk setup is een device ook onder zijn naam te bereiken. Kan mij voorstellen dat je in je PI hole ook DNS entries kan zetten.
Uiteraard kan je ook met een reverse proxy gaan werken maar dan maak je het complex zeker als het allemaal op 1 device werkt.
Overigens gezien je vraag zou ik me eerst nog goed in de materie verdiepen met betrekking tot DNS poorten etc.

Reverse proxy, dat was eigelijk wat ik bedoelde

[Frogmen]

bedenk wel dat niet alles lekker via reverse proxy werkt dit is eigenlijk alleen voor webapplicaties. Andere diensten of services werken niet.

[ Voor 3% gewijzigd door Frogmen op 05-10-2021 13:47 ]

[Lawwie]

Nog eenvoudiger, bookmarks in je browser

[monstertje.xyz]

Ik heb alle interne diensten (welliswaar op een kubernetes clustertje) achter een ingress (traefik) draaien. Bijvoorbeeld mqtt, dit is echt geen HTTP. Er zijn echt heel weinig dingen die niet achter een vorm van reverse proxy kunnen draaien.

[ Voor 9% gewijzigd door monstertje.xyz op 05-10-2021 13:53 ]

[Homewrecker]

Frogmen schreef op dinsdag 5 oktober 2021 @ 13:46:
bedenk wel dat niet alles lekker via reverse proxy werkt dit is eigenlijk alleen voor webapplicaties. Andere diensten of services werken niet.

Het gaat in mijn geval enkel om webapplicaties.

[Rensjuh]

Heb je Apache draaien?
Dan kun je vhosts aanmaken, je kunt dan alles op dezelfde poort laten luisteren maar d.m.v. de virtual host op de juiste map / applicatie uit laten komen.

Apache vhost
Weet niet of je hier iets mee kunt?

[Verwijderd]

Homewrecker schreef op dinsdag 5 oktober 2021 @ 14:17:
[...]


Het gaat in mijn geval enkel om webapplicaties.

dan is een bookmarkje in je internetbrowser toch veel makkelijker...?

[Homewrecker]

Verwijderd schreef op dinsdag 5 oktober 2021 @ 14:22:
[...]


dan is een bookmarkje in je internetbrowser toch veel makkelijker...?

Makkelijker wel, maar voor een echte Tweaker niet voldoende

Rensjuh schreef op dinsdag 5 oktober 2021 @ 14:21:
Heb je Apache draaien?
Dan kun je vhosts aanmaken, je kunt dan alles op dezelfde poort laten luisteren maar d.m.v. de virtual host op de juiste map / applicatie uit laten komen.

Apache vhost
Weet niet of je hier iets mee kunt?

Thanks ik kijk het na.

[Paul]

Homewrecker schreef op dinsdag 5 oktober 2021 @ 13:19:
Ik had al gezien dat er veel gebruik gemaakt word van Nginx proxy manager, maar werkt dit ook lokaal?

Jazeker. Hooguit dat Let's Encrypt wat lastiger is (je kunt voor lokaal-only geen web challenge gebruiken dus je moet DNS challenge gebruiken) maar verder zou dat gewoon moeten werken.

[amx]

Reverse proxy als je van buiten erbij wil, pihole local cname records voor lokale DNS (?)

[Faifz]

Een reverse proxy is de enige oplossing als je de poorten niet wil ingeven. Dus voor al je DNS entries (a.example.com, b.example.com, etc.) verwijs je het naar een reverse proxy. De nginx proxy manager is een container (bv. docker als runtime), erg gemakkelijk voor beginners maar de klassieke manier is ook niet zo heel moeilijk.

Hou er wel rekening mee dat je een SSL certificaat nodig hebt op de reverse proxy (front-end) als een van je NAS services op SSL zouden werken. Dit kan een self-signed certificaat zijn of van een publieke CA (bv let's encrypt) maar daarvoor heb je een geldige domeinnaam nodig. Dus als je lokale DNS eindigt op .local of dergelijke, gaat het een self-signed certificaat zijn.

Ga je een voorbeeld geven door middel van een self-signed certificate te gebruiken. Eerst maak je het aan met de volgende commando:

code:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

code:

server {
        listen 443 ssl; #luistert op 443
        server_name plex.nas.com; #DNS hostname
    ssl_certificate  /etc/ssl/certs/nginx-selfsigned.crt; # public key
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key; # private key 
        access_log /var/log/nginx/access.log;

        location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass https://10.10.10.10:4354; #hier gebeurt het allemaal

}

}

Het voordeel van een reverse proxy is dat je alsnog SSL hebt voor back-end services die op HTTP draaien.

[Frogmen]

Faifz schreef op woensdag 6 oktober 2021 @ 05:00:

Het voordeel van een reverse proxy is dat je alsnog SSL hebt voor back-end services die op HTTP draaien.

Daarmee is alleen de verbinding tussen client en proxy https tussen proxy en applicatie server blijft http. Voor puur intern gebruik dus niet zo heel erg interessant.

Overigens zou je het kunnen oplossen door op de NAS als daar al een webserver draait subdomains te maken met een redirect erin die naar de juiste poort verwijst. Dan heb je geen extra server nodig nog wel DNS.

[Faifz]

Frogmen schreef op woensdag 6 oktober 2021 @ 09:22:
[...]

Daarmee is alleen de verbinding tussen client en proxy https tussen proxy en applicatie server blijft http. Voor puur intern gebruik dus niet zo heel erg interessant.

Waarom zou het niet interessant zijn? Als je SSL centraal kunt houden op een reverse proxy, hoef je de back-end services niet als SSL te configureren. Scheelt ook wel een hoop aan resources. Ik geef natuurlijk de voorkeur aan SSL tussen proxy en back-end in een serieuze enterprise omgeving, maar voor een thuis omgeving is het gewoon te ver gezocht en het is eerder optioneel.

Frogmen schreef op woensdag 6 oktober 2021 @ 09:22:
[...]Overigens zou je het kunnen oplossen door op de NAS als daar al een webserver draait subdomains te maken met een redirect erin die naar de juiste poort verwijst. Dan heb je geen extra server nodig nog wel DNS.

Oja, redirecting is een alternatief. Je bedoelt iets zoals:

code:

<VirtualHost *:80>
    ServerName plex.example.com
    redirect / http://192.168.30.50:4325/
</VirtualHost>

Maar een reverse proxy configuratie met apache2 ziet er niet zo heel anders uit hoor.

code:

<VirtualHost *:80>
    ServerName plex.example.com
    ProxyPreserveHost On

    <Proxy *>
        Order allow,deny
        Allow from all
    </Proxy>
    ProxyPass / http://192.168.30.50:4325/
    ProxyPassReverse / http://192.168.30.50:4325/
</VirtualHost>

[Frogmen]

@Faifz Ik heb het over in het geval van de TS kan een redirect heel goed. reverse proxy is een heel ander mechanisme met zijn eigen voordelen ook, maar voor intern thuis is dat niet van toepassing allemaal.

[Paul]

Met de hoeveelheid services die geen SSL doen, of wel SSL doen maar met een self-signed cert zonder uitleg hoe dat te vervangen, zie ik echt wel voordeel bij een reverse proxy vergeleken met een redirect, vooral omdat meer en meer browsers moeilijk gaan doen bij HTTP.

Andersom, niet alle services kunnen (out-of-the-box) overweg met een reverse proxy (5% of zo?). Meestal is het een simpele aanpassing in de config (X-Forwarded-For meegeven, of het IP-adres van de reverse proxy ergens in de applicatie invullen), maar soms is het simpeler om toch een redirect te gebruiken

[Raymond P]

@Frogmen Een redirect is imho bijna altijd onzinnig. Maak dan gewoon een bookmark of gebruik een application dashboard zoals bijvoorbeeld https://heimdall.site.

Nginx gebruiken als reverse proxy geeft een hoop meer opties en is zoals @monstertje.xyz niet beperkt tot http(s).

[Frogmen]

Raymond P schreef op donderdag 7 oktober 2021 @ 11:01:
@Frogmen Een redirect is imho bijna altijd onzinnig. Maak dan gewoon een bookmark of gebruik een application dashboard zoals bijvoorbeeld https://heimdall.site.

Nginx gebruiken als reverse proxy geeft een hoop meer opties en is zoals @monstertje.xyz niet beperkt tot http(s).

Dat ben ik zeker niet met je eens zeker op een nas kan je niet altijd iedere web applicatie rechtstreeks met een eigen dns naam aanroepen tuurlijk kan je een bookmark maken maar om te onthouden en te delen is een dns naam makkelijker http://192.168.23.124:29543/media vs http://media.nas.local
Laat dat laatste nou net zijn wat de TS wil. Waarom is dat dan onzinnig? wat is de zin van een extra stroomverbruikende server.

[Wachten...]

Als je reverse proxy gebruikt in Synology, dan kun je daarna in je pihole gewoon DNS records aanmaken naar het ipadres van je Synology. Alles is dan gewoon als volgt te bereiken binnen je netwerk

syno.mijnserver.nl
camera.mijnserver.nl
homeassistant.mijnserver.nl

Uiteraard is de benaming hierboven slechts een voorbeeld, maar draai het hier op die manier, en het werkt prima zowel binnen als buitenshuis.

Het enige waar ik tegenaan loop (en jij dus dan ook) is dat je in Pihole alles onder 1 naam ziet staan. Je kunt dus volgens mij niet zien of er iets geblockt is in een docker applicatie of Home assistant o.i.d.
Ik probeer dit nu wel uit te vogelen, want het maakt het troubleshooten wel een stuk makkelijker.

[ Voor 28% gewijzigd door Wachten... op 07-10-2021 19:14 ]

[Faifz]

Frogmen schreef op woensdag 6 oktober 2021 @ 19:39:
@Faifz Ik heb het over in het geval van de TS kan een redirect heel goed. reverse proxy is een heel ander mechanisme met zijn eigen voordelen ook, maar voor intern thuis is dat niet van toepassing allemaal.

Zo net eventjes getest, als je van HTTP naar HTTPS redirect doet - werkt het perfect. Maar van HTTPS naar HTTPS redirect werkt niet omdat ik geen SSL cert in de virtualhost heb staan. Dus weet niet of je een HTTPS > HTTPS redirect kunt doen zonder eerst een SSL cert voor te stellen.

Op mijn hypervisor heb ik PA-VM series staan, met daarachter een load-balancer en tal van back-end services zoals wordpress, nextcloud, VPN portals etc. en ze zijn ook bereikbaar van buitenaf.

Voor mijn plex server die op mijn NAS draait en niet op mijn hypervisor, gebruik ik liever een redirect omdat de load-balancer een limiet heeft van 20Mbps. Ik weet niet hoe je de default SSL cert vervangt op de unifi-controller, dus heb dit maar in proxy-mode staan. Alhoewel een redirect hier ook perfect zou kunnen, maar ik irriteer me aan self-signed certificaten.

Kan je geen ongelijk geven. Reverse proxies of load balancers kunnen erg ingewikkeld worden en heb het dan over Traefik, NSX-T/AVI, F5 BIG IP, Kemp etc. Maar NGINX is helemaal niet zo moeilijk in vergelijking met de rest dat ik heb opgenoemd.

[Paul]

Faifz schreef op donderdag 7 oktober 2021 @ 21:02:
Dus weet niet of je een HTTPS > HTTPS redirect kunt doen zonder eerst een SSL cert voor te stellen.

Om een SSL virtualhost te gebruiken heb je een certificaat nodig. Voor een SSL reverse proxy ook, tenzij je een SSL_BRIDGE (Citrix term), TCP Router (Traefic), stream (nginx) etc. gebruikt; dan decrypt de reverse proxy niet en wordt het certificaat van de achterliggende service gebruikt.

Met Let's Encrypt is een certificaat voor een website die publiek benaderbaar is aanvragen tegenwoordig kinderspel (`certbot --nginx`...) maar om zelf een eigen CA te maken en certificaten te genereren heb je ook niet meer nodig dan openssl en Google voor de meest simpele variant. Een tussenvorm is DNS authenticatie voor Let's Encrypt, dat is iets ingewikkelder dan bij een publiek benaderbare site en certbot alles laten regelen, maar werkt prima voor sites die niet extern benaderbaar zijn (of voor wildcard certs).

gebruik ik liever een redirect omdat de load-balancer een limiet heeft van 20Mbps

Welke gebruik je? Citrix ADC CPX Express? Ik ben @work de ADC beheerder, vind het heerlijk spul Maar thuis gebruik ik nginx en ben nu aan het kijken naar Traefic.

Ik weet niet hoe je de default SSL cert vervangt op de unifi-controller

https://community.ui.com/...95-43cd-9e6b-fc1a77807f87 heeft een aantal tips, waarvan de meest recente van 18 degen geleden, /data/unifi-core/config/unifi-core.key en .crt vervangen

Maar NGINX is helemaal niet zo moeilijk in vergelijking met de rest dat ik heb opgenoemd.

Over allemaal is voldoende info te vinden online. Zelf werk ik hele dagen met de Citrix ADC (voorheen Netscaler), maar de concepten zijn overal wel ongeveer hetzelfde. Je hebt één of meer achterliggende servers, die bieden een service aan, en die services bundel je naar een virtueel IP. Ga je ingewikkelder dingen doen (requests of responses herschrijven bijvoorbeeld) dan wordt het een ander verhaal

[Faifz]

Paul schreef op donderdag 7 oktober 2021 @ 21:30:
[...]

Welke gebruik je? Citrix ADC CPX Express? Ik ben @work de ADC beheerder, vind het heerlijk spul Maar thuis gebruik ik nginx en ben nu aan het kijken naar Traefic.

Momenteel gebruik ik Kemp, voorheen gebruikte ik Traefik maar een berg aan configuratie files was niet echt plezant meer. Dit artikel had ik een tijdje geleden geschreven, misschien heb je er iets aan: https://faatech.be/wordpr...roxy-with-docker-compose/

Ik heb ook ervaring met NSX-T's load balancer, maar het probleem is dat het afhankelijk is van NSX-T infrastructuur (software-defined networking blabla) en redelijk veel resources inneemt. Je hebt als alternatief AVI (tegenwoordig VMware NSX ALB), is wel een compleet apart product en vereist geen NSX-T. Momenteel ben ik hiermee aan het spelen.

Paul schreef op donderdag 7 oktober 2021 @ 21:30:
[...]
https://community.ui.com/...95-43cd-9e6b-fc1a77807f87 heeft een aantal tips, waarvan de meest recente van 18 degen geleden, /data/unifi-core/config/unifi-core.key en .crt vervangen

Blijkbaar had ik het heel snel opgegeven, maar doe het toch liever dan met een proxy/load-balancer.

Paul schreef op donderdag 7 oktober 2021 @ 21:30:
[...]Over allemaal is voldoende info te vinden online. Zelf werk ik hele dagen met de Citrix ADC (voorheen Netscaler), maar de concepten zijn overal wel ongeveer hetzelfde. Je hebt één of meer achterliggende servers, die bieden een service aan, en die services bundel je naar een virtueel IP. Ga je ingewikkelder dingen doen (requests of responses herschrijven bijvoorbeeld) dan wordt het een ander verhaal

Is precies het geval met Kemp en NSXT/AVI. Altijd een virtual IP en de back-end services erachter. Natuurlijk heb je NAT regels staan op de edge router/firewall die verwijzen naar dat adres.