Synology-Forum.nl
Hardware ondersteuning => Netwerk algemeen => Topic gestart door: Ruud59 op 21 november 2021, 14:35:01
-
Ik heb een nieuwe NAS ingericht d.m.v. een hyper backup vanaf mijn oude NAS.
Tijdens dat proces stond de nieuwe NAS aangesloten via een hubje onder mijn bureau.
Nu de migratie succesvol leek heb ik de nieuwe NAS op de plaats gezet van de oude NAS, direct naast de router.
Nu kan ik de NAS niet meer bereiken via een browser. Via find.synology.com of de Synology Assistant wordt de NAS ook niet gezien.
De netwerkverbindingen onder windows naar de gedeelde mappen werken wel gewoon.
rara...
-
ipadres:5001 of nasnaam:5001 geeft de melding 'bad request'
[attachimg=1]
Bij het invoeren doet de browser een voorstel die ik heb overgenomen:
https://ipadres:5001/#/signin
Nu krijg ik wel contact en kan ik inloggen.
Wel moet ik eerst meldingen over een potentieel veiligheidsrisico negeren.
So far so good, maar wel vreemd allemaal.
Bij het infocenter zie ik achter Quick connect een streepje "-" staan.
Ik maak de quick connect opnieuw aan en deze werkt vervolgens ook.
Waarschijnlijk gebaseerd op waarmee ik de connectie heb gemaakt.
ipadres:5001 of nasnaam:5001 geven nog steeds de melding 'bad request', maar ik kan verbinding maken en inloggen via quick connect.
Ik heb niet het gevoel dat het allemaal volgens de regels gaat.
-
Wat verder speurwerk verricht...
Onder 'externe toegang' kan je onder 'Routerconfiguratie' de verbinding testen. Ik krijg dan de volgende melding:
zie bijlage.
Als je op volgende klikt, kan je het 'automatisch doorsturen' laten instellen op de router.
Maar...
Is het verstandig om dit te doen?
De router werkte voorheen ook goed met de "oude" NAS
Het gaat hier op externe toegang, maar misschien raakt het ook het interne probleem...
-
ipadres:5001 of nasnaam:5001 geven nog steeds de melding 'bad request'
?? Heb je überhaupt wel naar de foutmelding van nginx gekeken??
-
nee, de kreet was me niet opgevallen. Eerlijk gezegd.
Het is blijkbaar een webserver, maar wat betekent dat?
-
De foutmelding is echt maar één regel.
A plain HTTP request was send to a HTTPS port
Je moet echt moeite doen dit over het hoofd te zien.
-
Briolet, Dit is geen onwil, maar gebrek aan kennis.
De melding heb ik wel gezien, maar zegt me helemaal niets.
Wil je deze voor me vertalen?
Nog beter, wat moet ik doen om de melding weg te nemen?
-
Nog even wat logging ter info tijdens de volgende actie:
"Nu de migratie succesvol leek heb ik de nieuwe NAS op de plaats gezet van de oude NAS, direct naast de router".
Daarvoor had ik de NAS uitgezet en na aansluiten weer aangezet.
[attachimg=1]
Wat daar gebeurt is mij ook een compleet raadsel. De netwerkstekker zit in LAN1 en de NAS gaat iets met LAN2 doen.
Verder worden zaken gestopt, gestart en disabled...
Het nadeel van een NAS is de noodzaak van een netwerk met voor mij vaak onverklaarbare problemen en zaken die je moet configureren zonder enige functionele context.
Dit probleem is nu ook weer ontstaan door gewoon de NAS op een ander punt in het netwerk in te prikken. Hoezo dan.
-
Briolet, Dit is geen onwil, maar gebrek aan kennis.…
Maar er staat toch heel expliciet dat je HTTPS moet gebruiken en geen HTTP. Poort 5000 is voor HTTP verkeer en poort 5001 is voor HTTPS verkeer. Dat moet ook gestaan hebben op de plek waar je vandaan hebt dat je poort 5001 kunt gebruiken.
-
Ik kan wel lezen wat er staat, maar daarmee begrijp ik het nog niet.
Ik begrijp niet waarom dit nu zo moet werken en wat dit verder betekent.
Ten eerste gebruikte mijn vorige NAS dus poort 5000 en de nieuwe NAS poort 5001, waarom deze verandering.
Ten tweede wordt bij de inrichting van de NAS zaken als quick connect ingesteld die dus foutief zijn.
Ten derde werkte het vanochtend wel met de NAS aan een HUB en niet met de NAS aan de router.
Daar verbaas ik me over.
We kunnen zeggen: "wat maakt dat 'S-je' nu uit", maar het betekent toch iets.
-
Briolet zegt het toch? ;)
je moet gewoon naar https://ipnummer:5001
of https://naamnas:5001 gaan
Die s staat voor secure... en is een beveiligde verbinding.
Die 5000 word omgeleid naar 5001, wat dus een beveiligde verbinding is.
-
Het lijkt nu een beetje een discussie te worden en zo is dat niet bedoeld, maar ik hoop dat mijn frustratie een beetje begrepen wordt.
Ik heb die frustratie geuit, maar ik hoop ik niet dat dat als een persoonlijke aanval wordt beschouwd. Dat is helemaal niet de bedoeling en ik ben blij met de reacties, want dat leidt tot nieuwe inzichten, nieuwe kennis en hopelijk ook goede oplossingen.
Jij zegt ook weer; "je moet gewoon".
Ik weet dat de s voor secure staat, maar waarom moet ik die gewoon gebruiken?
Je prikt de NAS ergens ander in het netwerk en vervolgens moet je een secure verbinding gaan gebruiken.
Via find.synology.com of de Synology Assistant wordt de NAS niet meer gezien. De netwerkverbindingen onder windows naar de gedeelde mappen werken wel gewoon. Voor mij allemaal erg onduidelijk en ik wil dan graag weten wat de oorzaak is en "gewoon een S gebruiken" is dan niet bevredigend genoeg, want ik weet nog steeds niet waarom.
-
Nog 1 keer dan, dan hou ik er over op....
Je hebt HTTP... zeg maar een protocol voor verbindingen...
later kregen we HTTPS... )S staat voor SECURE' dat is hetzelfde, maar die verbinding is dan beter beveiligd tegen pottenkijkers.
Dus die nas forceert HTTPS.. boven HTTP....omdat dit dus VEILIGER is.
Een discussie is niet erg, als je het even niet begrijpt ook niet... maar google gewoon even wat is verschil HTTP.....HTPPS en je weet het.
Verder als je die inlogs zo doet als ik je net gaf, dan werkt het. #problemsolved ;)
die mappen werken omdat dit via SMB gaat... je browser gaat via HTTP of HTTPS:.. en je nas dus via HTTPS
-
Misschien staat de volgende optie (rood) aan, terwijl je dat niet wilt ?
[attach=1]
-
Stapper; Ik hoef niet te googlen, want ik weet het verschil tussen HTTP en HTTPS.
Deze kennis zegt echter niets over de relatie tussen de problemen die je ziet, wat het veroorzaakt en wat de oplossing vervolgens moet zijn. Die relatie zou ik graag duidelijk hebben.
Maar goed, ik ga de aanroep gebruiken zoals gewenst en daarmee problemsolved.
Birdy; Ik heb die optie niet. Verschillende DSM-versies?
[attachimg=1]
-
Volgens mij ontbreekt het hier aan elementaire kennis hoe je een url in een browser invult.
Wil je HTTP, dan vul je in : http://.......
Wil je HTTPS. dan vul je in: https://....
Volgens mij blijf je http:// invullen bij een https poort. (Dat is wat de foutmelding aangeeft)
Birdy: Ik denk dat het juist wel goed gaat als je dat rode aankruis. Want dan kun je wel http ingeven in de browser en krijg je een redirect naar https. Maar gezien de kennis van de werking van browsers, denk ik dat dit bij TS weer andere problemen geeft.
-
Toch even:
Birdy; Ik heb die optie niet. Verschillende DSM-versies?
Had gekeken in DSM6, in DSM 7 is die optie verplaatst:
[attach=1]
-
De optie staat bij mij idd aangevinkt.
-
Toch even als test, haal het vinkje eens weg en save.
-
Maar wat wordt dan de test?
http://.......;5001 geeft foutmelding; al dan niet redirected
http://.......;5000 gaat goed; misschien omdat het vinkje nu weg is
https://.......;5001 gaat ook goed; uiteraard
Ik vind het overigens niet respectvol dat er mensen zijn, die meteen roepen dat kennis bij een ander ontbreekt, terwijl ze die iemand niet kennen en ze vaak ook alleen maar de bekende oplossingen roepen zonder de oorzaken echt te kennen.
Ik krijg ook alleen maar de oplossing van het "s"-je aangereikt, terwijl niemand iets heeft geroepen over het waarom via find.synology.com of de Synology Assistant de NAS niet meer werd gevonden.
Overigens werkt dat nu wel weer (nadat één keer een connectie via http(s) is gelukt?)
-
Maar goed, ik ga de aanroep gebruiken zoals gewenst en daarmee problemsolved.
pffff die relatie heb ik toch klip en klaar uitgelegd? ::)
-
pffff die relatie heb ik toch klip en klaar uitgelegd? ::)
Ja, dat klopt, als je het niet gebruiken van de 's' als oorzaak ziet.
-
dat zag ik niet als oorzaak...
De oorzaak ben jij... ;)
veel succes ermee..
-
De oorzaak ben jij...
Aah, eindelijk duidelijkheid. Nu de oplossing nog 8)