http naar https redirect werkt niet goed nginx 404 not found

[Kasper1985]

Mijn vraag
Ik heb een reverse proxy opgezet op mijn home server/lab met nginx. Gebruik gemaakt van deze guides:

https://www.htpcguides.co...everse-proxy-nginx-linux/

https://www.htpcguides.co...ginx-reverse-proxy-linux/

Alleen de redirect naar https werkt niet. Als ik naar http://192.168.x.x ga krijg ik een 404 not found. Als ik naar (http://)mijnnaam.xs4all.nl ga krijg ik een 404 not found. De https varianten daarentegen werken top maar ik dacht dat het doel van een redirect nou juist was dat dat automatisch zou gaan als ik naar http:// zou gaan.

Overigens werkt het blok voor de synology nas ook niet maar daar zal ik een nieuw topic voor moeten openen denk ik. Dat blok eindigt in een timeout.

Wat staat er fout in mijn config? Na uren googelen weet ik het niet meer.

https://pastebin.com/JpRYqk1R

Relevante software en hardware die ik gebruik
Debian
Nginx


Wat ik al gevonden of geprobeerd heb
Ik heb verschillende variaties geprobeerd op het eerste server block dus de 80.

[CH4OS]

Maak in je config eens van return 301 redirect 301 in regel 4 van de config. Na aanpassen even NginX herstarten.

[ Voor 38% gewijzigd door CH4OS op 18-10-2017 21:31 ]

[Kasper1985]

@CH4OS dank voor de snelle reactie!

Als ik doe sudo nginx -t is dit de output:

nginx: [emerg] unknown directive "redirect" in /etc/nginx/sites-enabled/reverse:4
nginx: configuration file /etc/nginx/nginx.conf test failed

Dat werkt dus helaas niet

[CH4OS]

Dat was inderdaad even een gok van mij vanuit wat ik dacht, maar ben in de war met Apache2 bedenk ik mij nu. Ook op internet lees ik dat wat je hebt juist is.

@Kasper1985 Als je http://subdomein.xs4all.nl doet, werkt het dan wel? Volgens mij wel namelijk als ik de config zo zie. Hint: kijk even naar het IP-adres waarop je de server wil benaderen en de IP-adressen vanuit de config.

Kasper1985 schreef op woensdag 18 oktober 2017 @ 21:39:
In iedergeval waardeer ik het meedenken!

Wat ik trouwens ook vreemd vind is dit:

nginx: [warn] conflicting server name "mijnnaam.xs4all.nl" on 0.0.0.0:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Slaat dat op dat zowel http als https in hetzelfde bestand staan?

Je defineert dat subdomein dus twee keer binnen de HTTP configs (hij geeft immers poort 80 aan).

[ Voor 82% gewijzigd door CH4OS op 18-10-2017 21:44 ]

[Kasper1985]

In iedergeval waardeer ik het meedenken!

Wat ik trouwens ook vreemd vind is dit:

nginx: [warn] conflicting server name "mijnnaam.xs4all.nl" on 0.0.0.0:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Slaat dat op dat zowel http als https in hetzelfde bestand staan?

[Hero of Time]

Leuk je https blok, maar waar is location /? Als je naar http://jouwserver gaat, wordt je naar https://jouwserver gestuurd. Maar, er is niets dat wordt geserveerd op jouwserver/, er is alleen /radarr, /nasje, /sabnzb e.d.

Ga maar eens in je error log kijken.

Morgen kan ik op m'n werk kijken naar wat wij hebben en beter vergelijken.

[ Voor 13% gewijzigd door Hero of Time op 18-10-2017 21:44 ]

[CH4OS]

En bedenk je goed dat je de webpagina van de NAS ook bereikbaar maakt.
Met andere woorden https://subdomein.xs4all.nl/nasje gaat dan dus ook doodleuk naar jouw NAS. Kan mij voorstellen dat dat niet de bedoeling is.

[ Voor 63% gewijzigd door CH4OS op 18-10-2017 21:45 ]

[Kasper1985]

Op de NAS staat "webstation" uit alleen DSM is bereikbaar (al werkt dat dus niet) Daar zit een sterk wachtwoord op en 2 factor authentication van google. Er is maar 1 gebruikersnaam actief en de standaard root equivalent gebruikersnaam staat uit.

@Hero of Time Is dat het probleem? Moet ik simpelweg een locatie aanmaken voor / ?

Kasper

[Hero of Time]

Kasper1985 schreef op woensdag 18 oktober 2017 @ 21:47:
@Hero of Time Is dat het probleem? Moet ik simpelweg een locatie aanmaken voor / ?

Dat ligt eraan. Doe je 'mijndomein.xs4all.nl' intypen, of ga je gelijk naar 'mijndomein.xs4all.nl/sabnzb/'? Die laatste zou moeten werken. Maar je log zegt je precies waar je op je plaat gaat.

[CH4OS]

Zie ook mijn eerdere vraag hierboven. Je geeft aan als adres http://192.168.x.x/ te proberen. Maar in je config heb je daarop ook niets geconfigureerd staan en anders werken inderdaad enkel de gedefineerde locations.

[Kasper1985]

@Hero of Time nee ik ga direct naar mijndomein.xs4all.nl/servicenaam en dat geeft dus een 404 ipv de redirect naar https

@CH4OS Ik heb het eerder met 192.168.1.x getest maar dat werkte telkens niet toen ben ik bijwijze van trial en error dingen gaan aanpassen dit is de laatste variant.

[CH4OS]

Kasper1985 schreef op woensdag 18 oktober 2017 @ 21:51:
@Hero of Time nee ik ga direct naar mijndomein.xs4all.nl/servicenaam en dat geeft dus een 404 ipv de redirect naar https

Dan even in de log kijken, zoals HoT aangeeft.

[Hero of Time]

Goed, dan nog. LEES.. JE.. LOGS. Altijd. Je hebt dat niet eens gemeld in je TS en ondertussen een kwartier verder nog geen woord erover wat er nou in staat.

En voor je NAS, dat gaat natuurlijk niet goed. Je krijgt geen calls terug in de vorm van /nasje/doeiets.php ofzo, maar /doeiets.php. Als je dus al een login pagina krijgt, ga je daarna direct door naar / ipv /nasje en he, daar is niets. Ook elementen die van je NAS vanaf /css en /js geladen worden zijn volledig onbereikbaar.

[Kasper1985]

@Hero of Time Hier de logs:

https://pastebin.com/V3f2YufG

Dit is de error log van nginx.

Ik snap nu dat de nas issues geeft. Als ben ik wel tegen gekomen op mijn zoektocht dat het zo wel werkt maar wellicht met bepaalde toevoegingen in de config?

Alles wat ik wil bereiken is dat ik poort 5001 of 5000 niet hoef open te zetten naar het LAN IP van de NAS. Verder hoeft de debian server niks te doen dan requests op ip/nasje doorverwijzen naar het ip en poort van de NAS zodat die het verder af kan handelen.

Dit config bestand is ook puur en alleen als reverse proxy bedoelt. Vandaar dat er ook geen algemene index.html ofzo is dat is prima.

Kasper

[Hero of Time]

En je eigen interpretatie van wat er staat? Enige moeite wordt toch wel vereist hier. Je hoeft niet alles te weten, maar zaken interpreteren en uitleggen wat je denkt dat er aan de hand is, erop verder zoeken en dan komen met waar je tegenaan loopt is voor ons toch een stuk prettiger om te zien dan hier domweg je probleem neer te leggen en verwachten dat wij als helpdesk je vertellen wat je moet doen.

[Kasper1985]

@Hero of Time Ik ben sinds gisteren non stop aan het zoeken en zoals @CH4OS ook zei als je op internet gaat zoeken klopt dit en zou het moeten werken.

Ik kom hier niet voor niks. Ik heb uitgebreid lopen zoeken. Ik ben zondag avond begonnen met dit reverse proxy projectje.

Van dit log kan ik niet opmaken wat er aan de hand is. JIj noemde dat ik na een kwartier nog geen log had geplaatst dus ik heb snel een log gepost ondertussen zat ik met informatie uit het log verder te googelen (vandaar ook dat het posten van het log wat langer duurde) en niet met m'n pik in m'n hand te wachten tot jij gratis m'n probleem gaat oplossen mocht dat zijn wat je dacht.

Kasper

[CH4OS]

Kasper1985 schreef op woensdag 18 oktober 2017 @ 22:19:
@Hero of Time Ik ben sinds gisteren non stop aan het zoeken en zoals @CH4OS ook zei als je op internet gaat zoeken klopt dit en zou het moeten werken.

Dat sloeg wel enkel op de redirect, de rest van de config had ik nog niet goed bekeken.

[CH4OS]

code:

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        server_name subdomain.cptchaos.nl;

        # ssl settings
        ssl_protocols TLSv1.2;
        ssl_dhparam /etc/nginx/ssl/dhparam.pem;
        ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;
        ssl_prefer_server_ciphers on;
        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;
        ssl_ecdh_curve secp384r1;
        ssl_certificate /path/to/cert/fullchain.pem;
        ssl_certificate_key /path/to/key/privkey.pem;

        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        gzip off;

        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_set_header X-SSL on;

                proxy_pass http://<ip-adres>:<port>;
                proxy_read_timeout  60;
        }

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        location ~ /\.ht {
                deny all;
        }
}

Is wat ik gebruik als proxypass config voor diverse apps van andere VM's. De HTTP-varianten hou ik beschikbaar voor Let's Encrypt.

[ Voor 3% gewijzigd door CH4OS op 18-10-2017 22:26 ]

[Kasper1985]

De redirect is ook hetgeen wat niet werkt. De rest van de config werkt prima. op het nas gedeelte na maar die zal ik eruit halen en oplossen met een directe port forward. Schijnbaar gaat dat zo niet werken.

Enige wat ik niet snap is de redirect.

[Kasper1985]

@CH4OS gefixt!

Ander bestand geunlinked in sites-enabled. Had ik helemaal niet gezien maar was automatisch aangemaakt door iets dat ik geinstalleerd had. Die kaapte denk ik poort 80.

Dankjewel!

[Hero of Time]

Kasper1985 schreef op woensdag 18 oktober 2017 @ 22:19:
Van dit log kan ik niet opmaken wat er aan de hand is.

Niet? Timeout en connection refused zegt je niets? Als die 7 regels de enige foutmelding zijn en met je https echt alles gewoon werkt is het wel apart. Vooral dat je juist deze entries hebt op items die het blijkbaar wel gewoon doen.

Maar je bent er blijkbaar al uit. Missen dat er nog een config aan staat in sites-enabled kan je tot waanzin brengen. Zeker als die eerder geladen wordt dan de config die je juist aan de praat probeert te krijgen.

[Kasper1985]

@Hero of Time connection refused bracht me op het checken van de port forward in de router maar dat was heel vreemd geweest. 443 staat open en 80 staat dicht. Maar intern werkte het net zo hard niet als extern.

Verder was ik dus bezig om met informatie stukjes uit de errors te googelen.

Het probleem is van het volgen van dit soort guides dat je nul achtergrond informatie krijgt dus als je blindelings volgt wat er staat dan werkt het in een ideale situatie. Op het moment dat je daarvan afwijkt dan krijg je dus dit soort situaties.

Ik ben pas begonnen met het experimenteren met dit soort dingen sinds een maandje omdat ik nu bij een werkgever zit waar het relevant is. Vandaar dat het dus voor mij niet zo logisch is als voor jou als je zegt "Altijd logs lezen". Ja dat klinkt nu inderdaad enorm logisch en dat is een wijze les. Maar tot vanavond zat dat niet in m'n routine :-)

Nu Wel!

Dank!

Kasper

[Hero of Time]

Dan nog een tip: lees de logs goed met wat er staat. Begrijpend lezen krijg je al op de middelbare school. Dingen als "upstream timed out (110: Connection timed out) while connecting to upstream" zegt niets over wat er buiten gebeurt. Het zegt daarentegen alles wat de server zelf moet doen. Jij wil naar /nasje, de server moet dan verbinding maken met je nas. Als die geen antwoord geeft, heeft je server niets om naar jou te sturen. "Upstream timeout", andere kant neemt niet op en voicemail staat niet aan. Dat is dan pech. Zelfde met "connect() failed (111: Connection refused) while connecting to upstream". Je wilt naar binnen, belt aan, maar de deur wordt weer voor je neus dicht gegooid. Sta je dan, toegang geweigerd.

[Kasper1985]

@Hero of Time dat begrijp ik als je dat zo zegt. Voor mij zijn die dingen niet vanzelfsprekend en die moet ik dus googelen en dan kom ik langzaam maar zeker tot de conclusie die jij in 1 seconde trekt na het lezen van heel veel forum posts etc.

Echter als ik als iMac (intern) bij de nas aanbel dan doet ie de deur open en zet ie koffie of vraagt ie of ik een biertje wil.

Als de debian server (vanuit nginx) aanbelt is de deur dicht en staat ie in de kou.

Daar mis ik dus de achtergrond kennis en ervaring. Voor mij is het logisch dat als een extern apparaat aanklopt bij <debian> server en zegt "ik wil graag naar de nas maar ik weet het precieze adres niet> dat de debian server reageert met "Prima ik stuur je wel even door". Met de configuratie zoals ik die had staan.

Dat lukt namelijk met al die andere services wel zoals radarr sonarr etc. Maar die draaien lokaal dat is het enige verschil.

Inmiddels ben ik met enig zoekwerk wel tegengekomen dat veel meer mensen hier tegen aanlopen maar dat het dan wel lukt met nas.bla.example.com maar niet met bla.example.com.

Waar ik dus nu achter probeer te komen is of ik gewoon bla.mijnnaam.xs4all als virtuele host kan aanmaken als eigen bestandje of dat ik dan een ergens nog een A record aan moet maken voor nas.mijnnaam.xs4all.nl.

Ik denk dat ik daar maar mee wacht tot het weekend, m'n hoofd tolt een beetje.

[jant]

Kasper1985 schreef op woensdag 18 oktober 2017 @ 23:21:

Waar ik dus nu achter probeer te komen is of ik gewoon bla.mijnnaam.xs4all als virtuele host kan aanmaken als eigen bestandje of dat ik dan een ergens nog een A record aan moet maken voor nas.mijnnaam.xs4all.nl.

Alsof jij toegang zou hebben tot de zone van xs4all.nl. Ach, dat zou verdomd nog kunnen via de klantinterface voor je subdomeintje.


@Hero of Time maakt een paar legitieme punten in dit topic @Kasper1985. Neem dat ter harte.

[ Voor 17% gewijzigd door jant op 19-10-2017 00:12 ]

[Kasper1985]

@jant wat voor punten? Mag ik niet via dit forum dingen proberen uit te zoeken? Zo help ik ook anderen op weg als ze aan het testen en uit proberen zijn.

Ik mis het inlevingsvermogen hier een beetje. Als ik dingen verkeerd zie leg dat dan alsjeblieft constructief uit. Maar op deze manier schiet het niet op.

[Demo]

Ik zie in je config 'location /subdir', 'location /subdir/', 'proxy_pass http://adres' en 'proxy_pass http://adres/' door elkaar gebruikt worden. Uit ervaring weet ik dat bepaalde combinaties er voor zorgen dat subdir wel of niet aan de URI wordt geplakt die op de proxy wordt opgevraagd.
De redirect heb ik zelf verwezen naar https://$host$request_uri, ik zou me zo voor kunnen stellen dat de server nu probeert te redirecten naar "https://mijnnaam.xs4all.nl 127.0.0.1" aangezien dat de inhoud van $server_name is.
Verder forward je /organizr naar 127.0.0.1:80, terwijl dit server block al op die poort + hostname luistert. Als ik me niet vergis, gaat dit een mooie loop opleveren.

[Kasper1985]

@Demo dank! De redirect is inmiddels opgelost. De sites-enabled die automatisch was aangemaakt bij de installatie van organizr was de boosdoener.

Organizr werkte wel toen de redirect niet werkte en nu werkt organizr dus inderdaad niet meer.

Heel langzaam begin ik een beetje te snappen hoe dit allemaal werkt.

Ben maar weer opnieuw begonnen vanaf 0 met een schone lei.

Kasper