https werkt niet met quickconnect

[Babylonia]

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.

[Briolet]

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'.

[Babylonia]

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?

[Briolet]

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.

[Babylonia]

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?

[Briolet]

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.



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.

[Babylonia]

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.

[Briolet]

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.

[Birdy]

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.

[Babylonia]

Nee, dat is uitvloeisel vanuit de AVG.  Servers met persoonlijke informatie van inwoners in de EU moeten in de EU zijn gevestigd.

[Birdy]

Dus ja, DU en FR is toch EU?

[Gaffel]

Sorry, dat gaat allemaal boven mijn pet hoor!
Ik heb hiervoor te weinig achtergrondkennis.
Het moet zo eenvoudig mogelijk voor me zijn!

[Babylonia]

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.

[Briolet]

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.

[Birdy]

vroeger kon je bijv. ook........

Vroeger was alles anders.