Synology-Forum.nl
Overige software => DDNS / Quick Connect / EZ-Internet / Portforwarding => Topic gestart door: TonP op 28 mei 2015, 20:47:16
-
Dag Allemaal,
Ik heb alles ingesteld en kan vanaf internet prima op mijn DS412. Alles werkt. Vanaf mijn werk lukt dit prima, vanaf mijn telefoon ook.
Nu wil ik photo's ed delen met vrienden. Maar nu blijkt dat er diverse vrienden zijn die de NAS niet kunnen bereiken.
Als ik bij die vrienden via hun wifi probeer in te loggen lukt dat inderdaad niet. Schakel ik over op 3G dan werkt het weer.
Ik heb sterk de indruk dat het afhankelijk is van de internet provider.
Voor de duidelijkheid;
Als ze /photo benaderen dan verschijnt het scherm met de vier blokjes en de tekst "verbinden maken" maar daar blijft het dan bij. Onder in het scherm staat "wachten op ip....) en na x tijd komt de melding dat de server niet reageert.
Wie o wie heeft een idee waar dat aan kan liggen.
-
Probeer eens met /photo/ dus een extra / op het einde
-
Dag Hansiedown,
Ondanks dat ik weinig vertrouwen had in je "oplossing" toch maar even geprobeerd, je weet maar nooit, maar dat maakt, zoals ik had verwacht, geen verschil.
Probleem blijft dat idem.
Helaas.
-
Welk IP gebruik je?
Bij vrienden vanaf WiFi in ieder geval dus ook gewoon je externe IP-nummer gebruiken van je internet aansluiting.
Thuis vanaf je interne netwerk, je interne IP-adres van de NAS.
-
Dag Babylonia
Geprobeerd met IP adres en quickconnect. Maakt allemaal geen verschil. Bij sommige vrienden werkt het ook. Een ook via 3G werkt het via mijn mobiel. Het werkt ook als ik via mijn mobiel een hotspot maak en daar de computer van een vriend aan koppel. Maar niet via het wifi / eigen internet router van die vriend(en).
Het heeft echte iets te maken met de link tussen de providers.
Ziggo zakelijk naar ziggo prive werkt niet.
Ziggo zakelijk naar ziggo zakelijk geen probleem.
Ik begrijp er (nog) niks van.
Bedankt voor de response.
-
Firewall regels te scherp? Rechten?
-
Het lijkt me geen provider kwestie. Photo station wordt via poort 80 benaderd en dat is de meest standaard internetpoort die geen provider zal blokkeren.
Het lijkt me meer een IP blokkade in de firewall instelling van de nas.
-
Probeer eens met /photo/ dus een extra / op het einde
Dit heeft te maken dat niet elke browser een 'tailing' slash ondersteund als deze niet expliciet is opgegeven.
Was een poging waard.
-
@TonP
Meest simpele test om te kijken of er verbinding mogelijk is, is het volgende:
Verbonden met het betreffende netwerk, start een dosbox (voor windows) een gebruik het volgende commando (in de aanname dat Telnet is geinstalleerd op je werkstation)
telnet <ipnummer waar je naar toe wilt><spatie>80
Krijg je een zwart scherm of een heleboel tekst dan werkt de 'connectie' correct.
Krijg je een connection refused of connect failed dan wil het zeggen dat de verbinding niet mogelijk is.
Aditionele info: Het opgeven van <spatie>80 betekend dat we met dezelfde 'poort' als de applicatie photo station een verbinding willen maken.
Vraag: Als ik het goed lees heb je een Ziggo zakelijk abbonnement, is dat me 1 vast IP nummer of met meerdere vaste IP nummers (en mogelijk hierdoor verwarring of verkeerde instellingen.)
-
Excuus voor de late reactie.
Ik heb inmiddels alle tips geprobeerd maar dat mocht allen niet baten.
Tot ik vandaag een eigenaardige ontdekking deed.
Ik heb telkens verbinding gemaakt via de quickconnect. Vanaf diverse systemen werkt dat prima maar zoals eerder gezegd niet vanaf elk systeem. Zodra je verbinding maakt via quickconnect.to/mijnnaam/photo dan verandert dat in mijnnaam.nl.quickconnect.to/photo/
Maar daarmee is op die systemen geen toegang mogelijk.
Door een of ander raar iets veranderde de .nl plots in .uk en vanaf dat moment werkt het wel.
Ik begrijp hier dus echt niets van. Op zommige systemen werkt de link dus met .nl erin en op andere systemen moet er .uk staan op het werkend te krijgen.
Als iemand nog een tip heeft waar dit vandaan komt dan hoor ik het graag.
-
Laat dat CuickConnect er dan buiten en verbindt beter rechtstreeks met de IP-nummers die ervoor staan.
- voor je interne netwerk de IP van de NAS in je interne netwerk
- bij connectie vanaf een externe verbinding, het IP-nummer van je internet aansluiting (met port forwarding in je router naar de NAS)
Voor zover je geen port forwarding heb ingesteld, kijk eens naar info, tips, hulpjes bij de volgende reactie < HIER > (http://www.synology-forum.nl/firmware-algemeen/how-to-instellen-nieuwe-synology-nas-server/msg126895/#msg126895)
Als dat dan werkt, kun je een DDNS domeinnaam gaan gebruiken. (Prettiger voor je vrienden).
-
Dag Babylonia
Geprobeerd met IP adres en quickconnect.
Volgens deze quote heb je het ook met IP adres geprobeert, maar dat lijkt me nu toch tamelijk onwaarschijnlijk.
Dat de ene keer nl en de andere keer uk gebruikt wordt zal wel liggen aan waar de desbetreffende provider geregistreed staat.
Als dat uk is zal hij waarschijnlijk die kiezen.
Het beste is om gewoon via ip te connecten, dat quickconnect is een leuk idee, maar alles gaat dan via de servers van Synology en dat komt de performance niet ten goede.
-
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.
Synology geeft dan ook aan:
Communicating over the Relay Server can cause a significant delay in data delivery, and is thus the last method a client will take in attempt to reach the server
Het complete verhaal vind je hier. (https://global.download.synology.com/download/Document/WhitePaper/Synology_QuickConnect_White_Paper.pdf)
Verder ben ik ook van mening dat port forwarding nog altijd sneller is (nadeel is dat je goed moet beveiligen) of gebruik van VPN verbindingen.
Route plaatje QC:
[attachimg=1]
-
Dat is niet helemaal waar, ben ik achtergekomen, het loopt pas via de (relay) server als andere pogingen niet lukken.
Die andere pogingen behelzen praktisch gezien eigenlijk als je de methode van port forwarding in je modem/router hebt ingesteld.
Maar als je port forwarding hebt ingesteld, is de keus om QuickConnect te gebruiken overbodig, en kun je beter een DDNS domeinnaam kiezen.
-
@Birdy
Goede link.
Er zit dus wat meer achter dat quickconnect dan ik dacht.
@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.
Kort samengevat werkt het als volgt.
Een service op je Nas heeft connectie via een port naar de Synology servers(dus Nas geinitieerd).
Als er van buiten een quickconnect request komt via de Synology servers, dan wordt er een extra poort vanaf de Nas geopend richting de Synology servers.
Deze verbindingen wordt daarna overgedragen aan het device dat de aanvraag deed.
Er is nu een virtuele tunnel gemaakt tussen NAS en device, zonder dat er portforwarding nodig is (hole punching methode).
Pas als dat niet werkt zal er een verbinding over de synology servers gemaakt worden met de nodige nadelen(traag).
Wat mij nog niet duidelijk is waarom die hole punch methode kan falen en ze terug moeten vallen op een connectie via de Synology servers.
Ik vermoed dat het een en ander met Upnp werkt.
Als je portforwarding en DDNS gebruikt moet je ook nog vpn toevoegen om een tunnel te maken om dezelfde functionaliteit te krijgen.
-
Ik vermoed dat het een en ander met Upnp werkt.
Denk UDP, zie hier (https://en.wikipedia.org/wiki/UDP_hole_punching).
Daar staat ook waarom het niet zou kunnen werken (zeer vluchtig gelezen ;) )
-
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.
-
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.
-
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.
-
Of je neemt nog een biertje :lol:
Maar, ik keek er ook van op toen ik dat document (white paper) aantrof en las.
Ben benieuwd ;D
-
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.
-
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.
-
Snap ik wel.
Is veel eenvoudiger.
DDNS is voor veel mensen te moeilijk.
-
Ik snap het ook:
QC geen poort forwarding nodig.
DDNS (Of alleen IP) wel poort forwarding nodig en extra beveiliging.
-
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)
-
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.
-
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
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.
-
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.
-
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.
-
Schopje ter info,
Maak zelf geen gebruik van QC maar heb ontdekt dat het gebruik maakt van VPN.
Indien QC gebruikt wordt, wordt er een tun1000 aangemaakt.
Communicatie verloopt via UDP poort 443.
SHA1 als authenticatie
Geen cipher (encryptie)
Niet erg sterk dus.
Er wordt contact gezocht met global.quickconnect.to.
Wat betreft keep alive, er wordt 3x geprobeerd verbinding te maken.
Hier zijn enkele aanwijzingen te vinden:
/usr/syno/etc/synorelayd
/usr/syno/etc.defaults/synorelayd
-
Ik heb dezelfde problematiek als de TS. Ik kan thuis en onderweg prima mijn NAS benaderen. Via webbrowser of iOS-apps, allemaal geen probleem. Behalve als ik een keer op bezoek ben bij mijn ouders en daar van het wifi-netwerk gebruik maak. Dan is toegang krijgen, via welke manier dan ook, onmogelijk. Ook met het lezen van alle eerdere reacties ben ik er nog niet uit hoe dat op te lossen.
HEt blijft raar dat het alleen optreedt bij dat ene wifi-netwerk. Voor de rest nooit een probleem om erin te komen.
Is dat een groot probleem? Niet voor mij. Maar mijn ouders en ik gebruiken elkaars Synology als backup. En daarmee wordt het dus wel wat belangrijker. Mijn vader probeert via FTP toegang te krijgen tot mijn Synology om zo periodiek de belangrijke bestanden te syncen. Tot op heden zonder resultaat.
Ik blijf meelezen en sta open voor suggesties.
Alvast bedankt.
-
Afhankelijk van de (standaard) beveiligingsinstellingen in de NAS zelf, als je vanuit een bepaalde locatie eerst bijv. 3x verkeerd hebt ingelogd (foutje in username / password), wordt dat IP-adres geblokkeerd en komt het in een blacklist.
Zul je het IP-nummer eerst weer vrij moeten geven in de NAS.
Controleer eens in de NAS naar geblokkeerde IP-nummers.
Misschien dat je Firewall-regels in de NAS zodanig hebt staan m.b.t. regio's, dat misschien mogelijke IP-nummers in de buurt van de grensstreek net verkeerd kunnen worden opgepakt???