Synology-Forum.nl
Overige software => DDNS / Quick Connect / EZ-Internet / Portforwarding => Topic gestart door: Gaffel op 14 oktober 2020, 22:12:39
-
Beste mensen,
ik heb een DS720+ op mijn netwerk aangesloten en die is via Port Forwarding werkend met een eigen domeinnaam.
Deze werkt prima.
Vandaag heb ik een tweede NAS een DS213+ aangesloten welke ik met quickconnect heb geconfigureerd.
Ik heb via Externe Toegang een DDNS adres aangemaakt van Synology, na de vraag om een certificaat van Lets encrypt automatisch aan te maken heb ik ja ingevuld. Deze staat als hoofdcertificaat keurig ingevuld bij Certificaten.
Heb daarna het HTTPS verkeer bij Netwerk ingesteld. Maar krijg steeds nog de melding dat de verbinding niet veilig is.
Heeft het iets te maken met de poorten 5000 en 5001 welke ook al naar mijn DS720+ verwijzen?
Wat is er mis, kan dit we werken zo, wie kan mij helpen.
Groeten,
Han
-
Log je wel met je Quick Connect naam in? Ik lees namelijk alleen een verhaal over ddns.
-
Hoii Briolet,
Ik log inderdaad in met xxxxxxxxxxxxxx. Quickconnect.to.
heb de omleiding naar HTTPS (poort 5001) al uitgeschakeld.
-
Heeft nog iemand anders een tip voor me.
Heb de volgende vragen:
1- Ik heb in mijn router al; een verwijzing staan naar mijn DS720+ voor de poorten 5000 en 5001.
Heeft dit consequenties voor Quickconnect die de verbinding naar mijn DS213+ maakt en dus ook naar dezelfde poortnummers werkt?
2- Heb ik iets niet goed gedaan om een beveiligde verbinding te waarborgen via HTTPS, ik heb dat gedaan zoals hierboven staat omschreven door Externe Toegang aan te maken voor Synology en dat vandaar uit een certificaat wordt aangemaakt voor Lets encrypt?
Bedankt alvast voor het meedenken.
Han
-
Ik log inderdaad in met xxxxxxxxxxxxxx. Quickconnect.to.
Ik heb nog nooit QC gebruikt, maar staat die naam ook in het certificaat? Ik heb eigenlijk geen idee hoe synology dit oplost.
-
1 - Een Certificaat op DDNS naam gaat natuurlijk niet werken met QC.
2 - QC is eigenlijk niet bedoeld om te gebruiken in een Browser, maar (hoofdzakelijk) bedoeld voor Apps en verbindingen te leggen met b.v. een externe NAS voor Backup.
3- QC maakt, volgens mij, gebruik van het standaard Certificaat van Synology.
-
Verder heeft een QuickConnect domeinnaam een andere extensie dan welke gebruikt voor een Synology DDNS domeinnaam.
Dus als er al een Let's Encrypt certificaat zou worden gegenereerd, dan slechts voor een van beide domeinnamen / extensies.
Niet voor beide.
QuickConnect is een handige functie als je geen port forwarders wilt instellen in een router. (Voor de "beginner").
Heb je dat eenmaal onder de knie (poorten doorsturen in een router), is het gebruik van QuickConnect verder weinig zinvol.
-
Bedankt voor de reactie mensen,
Ik denk dat ik, als ik dit allemaal lees, dat ik beter gebruik kan maken van port forwarding.
Maar ik heb geen idee, hoe ik een tweede NAS kan aansturen via mijn domein.
Kan iemand vertellen of dit kan en eventueel hoe?
-
Een 2e nas kan idd alleen via QC of door het gebruiken van andere poorten.
-
Bedankt Briolet voor je hulp, maar is het mogelijk met een domein of subdomein, ik noem maar wat, om een 2e Nas te bereiken?
-
Tweede nas kan je met eigen domein prima bereiken via reverse proxy.
Control Panel, Application Portal en daar bij het tabblad Reverse Proxy.
Ik verwijs daar meerdere Nassen door binnen mijn netwerk en ook andere devices, denk aan UniFi CloudKey en dat soort zaken.
-
Robert bedankt, ik zal me er verder in verdiepen, kom ik er niet uit dan kom ik er op terug!
-
Control Panel > Application Portal > Reverse Proxy > Create.
Bij Source vul je protocol, port en hostname = (sub)domeinnaam in.
Bij Destination vul je het protocol, het IP nummer van de 2e NAS (of willekeurig ander apparaat) en portnummer in.
-
Bedankt Wyodor voor de aanvullende info!!
-
Bij reverse proxy's staan de certificaten op de nas waar de verbinding binnen komt. Bij Let's Encrypt moet dus die nas het certificaat aanmaken.
Bij destination kun je eventueel het http protocol gebruiken omdat dit intern verkeer tussen twee nassen betreft.
reverse proxy's werken heel mooi, maar is niet iets wat ik beginners zou aanraden. En het werkt alleen voor hppt(s) verkeer. Niet voor ssh, vpn etc.
-
reverse proxy's werken heel mooi, maar is niet iets wat ik beginners zou aanraden.
En het werkt alleen voor hppt(s) verkeer. Niet voor ssh, vpn etc.
Heb je toevallig ook ervaring of het met het "NFS" protocol werkt?
Toevallig kwam gisteren bij een kennis die vraag voorbij, met gebruik van twee NAS'sen.
-
Het werkt gegarandeerd niet met NFS. En dat is geen toeval, omdat ik schreef dat het alleen met http(s) werkt. Alleen dat protocol stuurt een domeinnaam mee met de packet header. En die domeinnaam is nodig als 'schakelaar'.
-
Ik kan met NFS ook domeinnamen gebruiken in de plaats van IP-addressen, en zelfs DDNS domeinnamen (extern).
Werkt over en weer aan beide kanten van een connectie.
Dat heb ik voor connectie met één NAS (zonder reverse proxy) al wel mee getest. Vandaar de vraag eigenlijk.
Maar omdat ik nog niet eerder met reverse proxy heb gewerkt, ken ik niet echt te mogelijkheden ervan?
-
Ik kan met NFS ook domeinnamen gebruiken
Dat klopt, maar dan haalt je PC het bijbehorende IP bij een DNS server op en gebruikt verder alleen het IP voor de verbinding.
Hij het http(s) protocol gebeurd hetzelfde, maar die stuurt daarnaast ook het oorspronkelijke domein nog mee in de http header. En zonder kennis van het beoogde domein kun je het verkeer niet doorsturen.
Dat is overigens ook de reden dat je bij https verkeer nog steeds kunt zien welke site bezocht wordt. Deze header mag natuurlijk niet versleuteld worden omdat die nodig is voor de reverse proxy's en de virtual hosts.
-
Zou ik iets kunnen doen met een DNS server op de NAS, voor alleen het lokale "doorstuur gebeuren"?
Het vervelende bij NFS is dat ze (voor zover ik dacht) vaste poorten gebruiken,
dus kan aan beide kanten daar niet iets anders voor nemen voor de ene NAS, of de andere dan wat "standaard" gebruikelijk is.
Of wordt het nu teveel off-topic? En moeten we dit sub-draadje naar een nieuw onderwerp verplaatsen?
-
Een lokale dns server gaat ook niet werken, want die kun je extern niet bereiken. Een locale dns server werkt wel i.c.m. vpn. Maar dan kun je zelf ook direct locale IP adressen gaan gebruiken.
http is gewoon een eigen protocol met een eigen soort header. In heel oude versies van http, stonden de domeinnamen er ook niet in, maar dit is lang geleden toegevoegd om o.a. virtual hosts te kunnen gebruiken, waarbij je meerdere domeinen op één IP kunt huisvesten.
Ik heb voor de grap eens een pagina op dit forum geopend, terwijl Wireschark aktief was. Dan zie je dat de domeinnaam via het "client hello" pakket overgedragen wordt.
[attachimg=1]
En voor wie de layout van Wireshark niet kent: Bovenaan staan het overzicht van de pakketjes. Onderaan staat de ruwe hex dump. En in het midden staat de ontleding van het pakket, gesorteerd naar de kennis die Wireshark over dat pakket heeft.
Deze "cliënt Hello" is typisch voor http verkeer.
-
Als ik het zo zie en lees, vermoed dat het op die wijze te complex gaat worden.
We zullen er wel iets anders op moeten bedenken om een keuze voor twee NAS'sen via NFS van buitenaf meer toegankelijk te maken.
Bedank zover voor de uiteenzetting.
-
Ik heb nog nooit QC gebruikt, maar staat die naam ook in het certificaat? Ik heb eigenlijk geen idee hoe synology dit oplost.
Toevallig zag ik vandaag zo'n certificaat voor een Quick Connect verbinding. Ze maken er een aan met de domeinnaam de7.quickconnect.to en een wildcard voor die domeinnaam. Door het acme-2 protocol kan Synology dit in hun dns systeem aangeven en hoeft dit domein tijdens registratie niet naar de nas zelf te wijzen. In principe zou ook de ddns naam nog in dit certificaat geplaatst kunnen worden. Dit is bij dit certificaat niet gebeurd, zodat hij alleen voor quickconnect te gebruiken is. Edit: toch niet, want ik neem aan dat dit certificaat bij Synology op de server staat. QuickConnect zonder forwards, loopt altijd via de synology servers.
[attachimg=1]
-
Eigenlijk wel logisch, dat het zo is geregeld.
Overigens, ze hebben in diverse landen relay servers staan, nu is het Duitsland, morgen misschien Frankrijk.
Zal wel liggen aan de drukte/beschikbaarheid.
-
Nee, dat is uitvloeisel vanuit de AVG. Servers met persoonlijke informatie van inwoners in de EU moeten in de EU zijn gevestigd.
-
Dus ja, DU en FR is toch EU?
-
Sorry, dat gaat allemaal boven mijn pet hoor!
Ik heb hiervoor te weinig achtergrondkennis.
Het moet zo eenvoudig mogelijk voor me zijn!
-
Dus ja, DU en FR is toch EU?
Dacht dat je dat ruimer bedoelde, vroeger kon je bijv. ook verbonden worden met servers in Taiwan of Canada.
-
Het moet zo eenvoudig mogelijk voor me zijn!
Dat is het juist met quickconnect. Omdat de certificaten bij Synology staan, heb jij er niets mee te maken. Moet altijd goed zijn.
Pas als je zelf forwards in de router aanmaakt, gebruikt quickconnect die forwards om hun eigen servers te ontlasten en loopt het verkeer niet meer via de synology servers. Hoe het dan met certificaten werkt, weer ik niet, maar als je zelf forward, kun je beter direct het universelere ddns systeem gebruiken en QC niet meer gebruiken.
-
vroeger kon je bijv. ook........
Vroeger was alles anders. :P
-
Beste mensen,
Ik heb besloten om met een subdomein te werken en met Reverse Proxy en een aangepast Certificaat bij Lets encrypt in mijn hoofdnas, heb ik het aan de praat gekregen.
Allen bedankt voor jullie inbreng!
Groeten,
Han