Toegang naar NAS vanuit internet afhankelijk van provider

[Birdy]

Ik vermoed dat het een en ander met Upnp werkt.

Denk UDP, zie hier.
Daar staat ook waarom het niet zou kunnen werken (zeer vluchtig gelezen )

[Ben(V)]

In dat verhaal staat dat het niet zou werken als je een router hebt met een bi-directionale NAT, wat geen enkele conssumer router is.

Denk niet dat ze udp gebruiken maar zou kunnen.
Er zijn verschillende mogelijkheden.
zie:
https://en.wikipedia.org/wiki/NAT_hole_punching


Waarom het soms mislukt en ze terug moeten vallen op een connectie via de SYnology Server.
Dat zou kunnen als ze in plaats van overdragen van de connectie link er voor kiezen via upnp een poort in de router gedurende de connectie open te zetten.
Als upnp in je router uitgeschakelt is werkt die methode niet.

[Birdy]

Als upnp in je router uitgeschakelt is werkt die methode niet.

UpNp aanzetten wordt juist afgeraden om de bekende redenen.
Als dus iedereen die QC gebruikt en UpNp dicht heeft staan, dan wordt het altijd relay Server.

Eigenlijk sniffer gebruiken om daar achter te komen.

[Ben(V)]

Ja als ik m'n biertje opheb zal ik eens gaan experimenteren.

Heb tot op heden quickconnect links laten liggen, omdat werken via de Synology servers me niet aanstond.
Na dat verhaal gelezen te hebben spreekt het me meer aan.

[Birdy]

Of je neemt nog een biertje 

Maar, ik keek er ook van op toen ik dat document (white paper) aantrof en las.
Ben benieuwd 

[Ben(V)]

Ja het is eigenlijk wel lekker hier in de tuin.

Maar ik ga het wel een keer uitzoeken.
Even wireshark aanzetten maakt vaak veel duidelijk.

[Briolet]

maar alles gaat dan via de servers van Synology en dat komt de performance niet ten goede.

Dat is niet helemaal waar, ben ik achtergekomen, het loopt pas via de (relay) server als andere pogingen niet lukken.

Quick Connect is gewoon een nieuw iets van synology die nog steeds verbeterd wordt. Dus dingen die vorig jaar waar waren, hoeven nu niet meer zo te zijn.

Maar omdat Synology ook een eigen gratis DDNS diens heeft, snap ik eigenlijk niet waarom iemand überhaupt nog QC gebruikt.

[Ben(V)]

Snap ik wel.
Is veel eenvoudiger.
DDNS is voor veel mensen te moeilijk.

[Birdy]

Ik snap het ook:

QC geen poort forwarding nodig.
DDNS (Of alleen IP) wel poort forwarding nodig en extra beveiliging.

[Briolet]

Er zijn verschillende mogelijkheden.
zie:
https://en.wikipedia.org/wiki/NAT_hole_punching

Dan moeten de routers die verbinding wel open laten. De meeste routers laten een inactieve verbinding zeker een uur open staan. Dat kost echter allemaal ruimte in de NAT tabel. Ziggo heeft al zijn routers zo ingesteld dat dergelijke inactieve poorten al na 5 minuten gesloten worden. Veel sneller dan veel programmas verwachten. b.v. WhatsApp herbevestigd de verbinding b.v. alleen elke 15 minuten met als gevolg dat inkomende berichten soms 15 minuten vertraagd aankomen omdat de poort alweer dicht stond.

Aan een methode, zoals QC, één soort problemen oplost, maar een nieuw soort problemen introduceert, heb je er weinig aan in mijn optiek. (Schreef iemand die QC zelf nog nooit geactiveerd heeft)

[Ben(V)]

Heb je het nu over upnp poorten die door de router weer dichtgezet worden of over die hole punching techniek?
Wat ik ervan begrijp (maar ik kan het verkeerd hebben) wordt met die laatste techniek de connectie opgezet vanuit de NAS zelf en staan er geen poorten geforward.

[Birdy]

Wat ik ervan begrijp (maar ik kan het verkeerd hebben) wordt met die laatste techniek de connectie opgezet vanuit de NAS zelf en staan er geen poorten geforward.

Klopt.

[Babylonia]

@Babylonia
Nee dat is niet waar, als je het verhaal leest dan zie je dat ze een hole punching methode gebruiken en geen port forwarding nodig hebben.

Ik snap dat QuickConnect geen port forwarding nodig heeft. Alleen in de controle van QC zullen ze het wel nalopen of het is ingesteld.
Mijn eigen ervaring is dat indien port forwarding niet is ingesteld, de respons een stuk trager verloopt dan met port forwarding.
Dus met andere woorden indien port forwarding wel aanwezig is, zal dat in de QC functie meegenomen worden als sneller alternatief.
In dat geval kun je QC dan net zo goed helemaal links laten liggen.

[Briolet]

Heb je het nu over upnp poorten die door de router weer dichtgezet worden of over die hole punching techniek?

Ik citeer toch duidelijk jouw link naar de punching techniek in mijn bericht. Dus geen relatie met UPnP.

Als ik die punching techniek goed begrijp dat wordt er van binnen uit een poort naar een externe server opgezet. Bij de meeste routers blijft die verbinding lang staan. Maar sommige routers (zoals de Ubee en Cisco van Ziggo) sluiten die poorten weer als er gedurende 5 minuten geen data over heen gaat. Als QC daar niet op bedacht is, dan kan de server geen contact met de nas krijgen omdat de poort al weer dicht zit.

Op het Ziggo forum is hier een hele discussie over geweest i.v.m. WhatsApp vertragingen. Maar dit is natuurlijk niet uniek voor WhatsApp maar gebeurde ook met SSH verbindingen etc. Als QC dit gebruikt en de verbinding niet elke 5 minuten even ververst, kan het daar ook mee gebeuren.

[Ben(V)]

Denk dat er wel een "keep alive" ingebouwd zit en anders wordt die verbinding weer gewoon opnieuw opgezet.
Wat wel weer overhead betekent.

Geloof dat ik nog steeds geen fan van quickconnect wordt.