Synology-Forum.nl
Hardware ondersteuning => Netwerk algemeen => Topic gestart door: boco op 05 april 2018, 14:31:06
-
Dag allemaal,
Een paar weken geleden heb ik een nieuwe DS 918+ gekocht die ik op mijn kantoor gebruik. Thuis heb ik een DS 411+II.
De twee DS's wil ik graag synchroniseren - ik ben een zelfstandig ontwerper en werk voornamelijk op het kantoor, maar af en toe werk ik ook thuis en wat ik op zoek naar ben is dus 2-way sync oplossing.
Bij Synology support hebben zij aangeraden om hier Cloud Station Server/Client voor te gebruiken - ik heb het op beide DS's geïnstalleerd (918+ is de server en 411+II is de client) en eerst alles van de oude naar de nieuwe DS met File Station gekopieerd via LAN, wat redelijk snel liep (op zo'n 50-100Mbps).
Maar toen ik de Server in het kantoor heb geplaatst kwam ik achter dat de synchronisatie tussen de twee DS's heel erg traag was - gemiddeld rond de 75Kbps (soms tot 200Kbps) - wat vrijwel zinloos is, omdat ik dagelijks met Photoshop bestanden van honderden MB's werk, en deze duren nu uren (of dagen) om te synchroniseren.
Internet verbinding op beide locaties kan niet het probleem zijn - thuis is het rond 50Mbps DL en 25Mbps UL en op kantoor (glasvezel) 150Mbps DL en 85Mbps UL.
Ik heb overal geprobeerd een oplossing hiervoor te vinden, tot dat ik remote-access aan de support van Synology heb gegeven en zij kwamen erachter dat poort 6690 op beide netwerken gesloten is. Dit vond ik heel raar, omdat ik het op beide routers heb open gezet, maar inderdaad, na het bericht van Synology blijken ze gesloten te zijn.
Synology support hebben verder geen oplossing voor mij kunnen bedenken.
Hierna heb ik alles geprobeerd wat ik ergens op forums (ook voor de specifieke routers - Linksys E4200 thuis, achter Telfort Experia Box v8 in bridge modus, en op kantoor een nieuwe Netgear R7000P) maar helaas lukt het niet en de poorten blijken nog steeds gesloten te zijn.
O.a. heb ik alle apparatuur opnieuw gestart, firewall uitgeschakeld, enz., maar niets lost het op.
Als iemand hier een idee voor heeft hoor ik het graag!
Veel dank alvast en groetjes,
Boco
NB - ik weet dat mijn vraag met meerdere topics te maken heeft, dus ik hoop dat ik het onder het juiste onderwerp heb gezet - als niet mijn excuses hiervoor..
-
Dit vond ik heel raar, omdat ik het op beide routers heb open gezet, maar inderdaad, na het bericht van Synology blijken ze gesloten te zijn.
Om verwarring te voorkomen, we hebben het hier over port forwarding.
M.a.w., je hebt een port 6690 op beide Routers (thuis/werk) forwarded naar het lokale adres van je NASsen (thuis/werk).
Je zegt, ze blijken "gesloten", dus, niet forwarded ?
Daarbij:
- Als het zo is wat Synology Support zegt, dan klopt dat niet echt, omdat je kennelijk WEL verbinding hebt alleen, het is traag.
Maar toen ik de Server in het kantoor heb geplaatst kwam ik achter dat de synchronisatie tussen de twee DS's heel erg traag was - gemiddeld rond de 75Kbps (soms tot 200Kbps)
- Als je de Sync start en er is geen contact onderling, dat wordt dit toch gemeld ?
Dus, ik vind het wat verwarrend, wel/niet poorten forwarded.
Betreft: Cloud Station Server/Client.
Wat bedoel je met Cliënt ?
Wat exact heb je geïnstalleerd op welke NAS ?
-
dank voor de snelle reactie en excuses als ik het nier goed had beschreven/geplaatst..
Om verwarring te voorkomen, we hebben het hier over port forwarding.
M.a.w., je hebt een port 6690 op beide Routers (thuis/werk) forwarded naar het lokale adres van je NASsen (thuis/werk).
Je zegt, ze blijken "gesloten", dus, niet forwarded ?
ik heb inderdaad poort 6690 op beide router forwarded naar de betreffende DS, maar als ik via http://canyouseeme.org/ of https://www.yougetsignal.com/tools/open-ports/ kijk lijken deze niet forwarded te zijn (dit was de reactie van Synology). Als ik trouwens andere poorts op deze websites check (80, 443) zijn ze wel 'open' (dus forwarded?).
- Als je de Sync start en er is geen contact onderling, dat wordt dit toch gemeld ?
wat precies bedoel je hiermee? ik vind het in ieder geval ook erg verwarrend ::)
Betreft: Cloud Station Server/Client.
Wat bedoel je met Cliënt ?
Wat exact heb je geïnstalleerd op welke NAS ?
op de DS918+ (werk) heb ik Cloud Station Server geïnstalleerd en op de DS411+II (thuis) heb ik Cloud Station ShareSync geïnstalleerd. Verder niets.
-
wat precies bedoel je hiermee? ik vind het in ieder geval ook erg verwarrend
Wat ik hiermee bedoel:
Als Cloud Station ShareSync zijn taak gaat uitvoeren (Sync dus), dan moet Cloud Station ShareSync contact hebben met de NAS waarop Cloud Station is geïnstalleerd, is dat niet zo, dan krijg je een error.
Buiten dat, je hebt toch een taak gemaakt ?
Het eerste wat je dan voorgeschoteld krijgt is:
[attachimg=1]
Als je de gegevens van de Remote Cloud Station NAS hebt ingevuld, dan wordt er direct contact gemaakt met de Remote NAS:
[attachimg=2]
om vervolgens een sync map te kunnen kiezen.
M.a.w.:
- je moet contact gehad hebben met de remote NAS, anders heb je geen taak kunnen maken.
- dat port 6690 niet forwarded is (wat Synology dus ook zegt) is dus onzin.
Ik wil alleen maar even uitsluiten dat het geen port forward issue is:
Ik heb overal geprobeerd een oplossing hiervoor te vinden, tot dat ik remote-access aan de support van Synology heb gegeven en zij kwamen erachter dat poort 6690 op beide netwerken gesloten is. Dit vond ik heel raar, omdat ik het op beide routers heb open gezet, maar inderdaad, na het bericht van Synology blijken ze gesloten te zijn.
En, http://canyouseeme.org/ of https://www.yougetsignal.com/tools/open-ports/ zijn niet betrouwbaar.
Ik heb al zo vaak dat eens getest met verkeerde uitkomsten.
Waar je wel op kunt vertrouwen is het tweede plaatje. ;)
Uiteindelijk is het probleem, dat het allemaal langzaam gaat, toch ?
-
Dank Birdy voor nog een snelle reactie 8)
Ik wil alleen maar even uitsluiten dat het geen port forward issue is:
Oké, duidelijk, maar toch vind ik het een beetje vreemd - in het begin wist ik namelijk niet dat ik iets met poort 6690 moest doen, maar ook zonder het forwarden van deze poort werkte de synchronisatie wel (zoals in de stappen in jou plaatjes). Alleen was de snelheid erg traag en vandaar dat ik op zoek naar een oplossing ging. Toen pas kwam ik achter dat ik voor Cloud Station poort 6690 moet forwarden, maar zoals beschreven heeft het geen verschil gemaakt (wat de snelheid betreft in ieder geval).
maar dan zitten wij inderdaad met:
Uiteindelijk is het probleem, dat het allemaal langzaam gaat, toch ?
inderdaad :(
Heb je hier wel een idee voor?
Groetjes,
Boco
-
Ok.....hoe heb je de verbinding gemaakt m.a.w., wat heb je ingevuld in mijn print screen1 eerste veld ?
-
QuickConnect ID (ik heb het eerst met ddns geprobeerd, maar dat ging niet)
En ik heb inmiddels nog even deze gevonden en gedownload: https://www.solarwinds.com/free-tools/port-scanner/ - het werkt lokaal en schijnt vertrouwbaar te zijn - en het geeft aan dat poort 6690 'closed' is (ik ben nu thuis - morgen kan ik het ook op het werk checken). Misschien heeft het toch iets hiermee te maken?
-
QC is leuk, dan heb je geen port forwarding nodig (mag wel/hoeft niet), dat zou kunnen verklaren dat je WEL een verbinding hebt !
Echter, QC loopt over een Relay Server van Synology en, wil wel eens traag zijn (meningen verschillen hierover).
ik heb het eerst met ddns geprobeerd, maar dat ging niet
Ahh...test nu eens met het Externe IP-adres van de remote Router, i.p.v. QC.
Als DAT ook niet lukt, dan heb je poort 6690 niet goed forwarded.
-
dank Birdy!
QC is leuk, dan heb je geen port forwarding nodig (mag wel/hoeft niet), dat zou kunnen verklaren dat je WEL een verbinding hebt !
Echter, QC loopt over een Relay Server van Synology en, wil wel eens traag zijn (meningen verschillen hierover).
wat zou dan een betere/snellere optie kunnen zijn?
Ahh...test nu eens met het Externe IP-adres van de remote Router, i.p.v. QC.
Als DAT ook niet lukt, dan heb je poort 6690 niet goed forwarded.
hmm.. hoe/waar vind ik het externe ip-adres van die router?
En ik zit trouwens nu op kantoor en zat weer naar die Port Scanner te kijken - hier geeft ie aan dat 6690 TCP wel forwarded is - maar dan snap ik niet waarom het op de andere router niet zo is (als het in ieder geval klopt) - port-forwarding op de Linksys is namelijk erg simpel en ik heb het voor meerdere dingen gedaan, dus het moet gewoon werken..?
-
hmm.. hoe/waar vind ik het externe ip-adres van die router?
Op locatie kijken met https://whatismyipaddress.com/
-
Op locatie kijken met https://whatismyipaddress.com/
oké! ga ik vanavond doen als ik weer thuis ben.
En verder een gedachte over de ontdekkingen via Port Scanner?
Groetjes!
-
Je moet https://whatismyipaddress.com/ wel doen aan de kant waar je backup heen gaat, dat is toch niet thuis maar op je werk?
-
Je moet https://whatismyipaddress.com/ wel doen aan de kant waar je backup heen gaat, dat is toch niet thuis maar op je werk?
oeps, ja, je had gelijk :)
MAAR als ik dan naar Cloud Station ShareSync ga en Manage > Edit Connection kies kan ik alleen maar het wachtwoord wijzigen - gebruikersnaam en server zijn grijs en kunnen niet geedit worden.. Of moet ik dan Manage > Unlink kiezen en alles opnieuw invullen?
-
Maar ik ga er toch vanuit dat je op afstand bij die nas kunt? Volgens mij kun je dat IP adres in sommige logfiles vinden.
En anders in je account by Synology. Bij DDNS toegang wordt daar in elk geval ook je IP adres vastgehouden. Of dat ook bij QC is weet ik niet.
Anders toch wachten totdat je op die locatie bent.
-
Of moet ik dan Manage > Unlink kiezen en alles opnieuw invullen?
Inderdaad, je zal een nieuwe taak moeten maken en weer (her)koppelen met de eerder gemaakte backup.
-
hmm.. het is mij niet gelukt om met het externe IP adres een verbinding te maken - maar even voor de zekerheid - de bedoeling is om bij het eerste veld het adres zo in te vullen: 11.111.11.111? of moet er nog iets bij komen?
-
niets erbij
-
het werkt niet :(
wat kan ik nu doen?
als ik het goed van jou reacties heb begrepen, kan het toch zijn dat poort 6690 thuis niet goed is forwarded - maar ik heb het 10 keer nagekeken en het moet kloppen, dus ik snap het echt niet..
-
Even voor de goede orde:
Thuis:
DS411+II met Cloud Station ShareSync, is de Client.
Kantoor:
DS918+ met Cloud Station Server, is de Boss.
kan het toch zijn dat poort 6690 thuis niet goed is forwarded
Dus, niet thuis forwarden (had eerder aangegeven van wel, mag wel maar, heeft geen zin) maar vooral op kantoor poort 6690 forwarden naar de DS918+.
Als eenmaal de link is gemaakt, gaat het 2 kanten op, de Client neemt het initiatief (poller).
-
Even voor de goede orde:
Thuis:
DS411+II met Cloud Station ShareSync, is de Client.
Kantoor:
DS918+ met Cloud Station Server, is de Boss.
klopt allemaal.
Dus, niet thuis forwarden (had eerder aangegeven van wel, mag wel maar, heeft geen zin) maar vooral op kantoor poort 6690 forwarden naar de DS918+.
Als eenmaal de link is gemaakt, gaat het 2 kanten op, de Client neemt het initiatief (poller).
poort 6690 op kantoor is wel forwared (tenminste volgens het Port Scan programma)
er is dus een link, als het goed is, maar met het externe IP adres die ik via https://whatismyipaddress.com/ heb gevonden kan ik geen verbinding (bij de Client) maken.
Ik zit ineens wel te denken dat het op de kantoor verbinding zitten zo'n 20 andere bedrijven - in dit geval kan het zijn dan het gevonden externe IP adres van het hele pand is en niet direct van ons?
-
Ik zit ineens wel te denken dat het op de kantoor verbinding zitten zo'n 20 andere bedrijven - in dit geval kan het zijn dan het gevonden externe IP adres van het hele pand is en niet direct van ons?
Dat zou best wel eens het geval kunnen zijn.
Dus, er is 1 "Hoofd Router" met 1 Extern IP-adres, waarna 20 andere "Bedrijf Routers" zitten ?
Dus, je doet een poort forwarding op je eigen Router, die geen Extern IP-Adres heeft, begrijp ik en, dat gaat niet werken.
Maar let op, ik ben geen expert op dit gebied maar, logisch gezien, kan dit niet werken.
Ik zou met de beheerder even gaan praten, hoe het zit.
De vraag is dus: is het IP-Adres, die je ziet met https://whatismyipaddress.com/ van de eerste router ?
Je zou dit ook bij je mede ondernemers even kunnen checken.
Overigens, volgens mij heb ik een dergelijke situatie al eens eerder hier voorbij zien komen.
-
dankjewel Birdy!
Ja.. ik vind het best stom van mij dat ik hier niet eerder aan dacht - zeker aangezien ik al zo lang mee bezig ben (:
dan moet ik weer tot maandag wachten en dan met het pandbeheer even checken. Ik laat het nog weten!
Goed weekend!
-
:thumbup: Ben zeker benieuwd hoe het daar in z'n werk gaat. ;D
-
Met "traceroute" kun je wel het aantal routers tussen jou en het internet terug vinden.
$ traceroute www.synology-forum.nl
traceroute to www.synology-forum.nl (80.246.180.160), 64 hops max, 52 byte packets
1 airport-4g (10.0.1.1) 5.181 ms 0.705 ms 0.685 ms
2 ubee (10.0.3.1) 1.695 ms 1.827 ms 0.857 ms
3 10.255.142.1 (10.255.142.1) 6.813 ms 8.226 ms 7.579 ms
4 zl-rc0001-cr102-xe-1-1-5-0.core.as9143.net (213.51.185.170) 6.258 ms 7.661 ms 11.926 ms
5 asd-tr0021-cr101-bundle-ether101.aorta.net (84.116.194.17) 10.114 ms 8.851 ms 15.817 ms
6 nl-ams02a-rc2-lag-8-0.aorta.net (84.116.130.98) 9.831 ms 9.815 ms 9.477 ms
7 nl-ams04a-ri3-ae8-0.aorta.net (84.116.130.97) 10.076 ms 10.636 ms 9.658 ms
8 ae1-60.br1.gs.network.is.nl (80.249.209.67) 10.618 ms 8.924 ms 16.131 ms
9 ae3-0.cr1.gs.network.is.nl (213.133.37.170) 9.906 ms 9.418 ms 19.737 ms
10 s2979.nxs.nl (80.246.180.160) 10.510 ms 10.290 ms 17.929 ms
Nr 1en 2 hebben een response die kort is. Dat zijn dus locale routers. Op het moment dat de tijd oploopt, zit je extern.
NB traceroute kan bij windows anders heten. (tracert ?)
-
Klopt, in Windows is het tracert, in CMD.
-
Maar toen ik de Server in het kantoor heb geplaatst kwam ik achter dat de synchronisatie tussen de twee DS's heel erg traag was - gemiddeld rond de 75Kbps (soms tot 200Kbps) - wat vrijwel zinloos is, omdat ik dagelijks met Photoshop bestanden van honderden MB's werk, en deze duren nu uren (of dagen) om te synchroniseren.
Samen met 20 andere bedrijven op één modem, dan zal je snelheid moeten inleveren...
-
dank @Birdy en @Briolet - ik ga er maandag naar kijken.
goed weekend!
-
Samen met 20 andere bedrijven op één modem, dan zal je snelheid moeten inleveren...
ik weet niet precies hoe het daar zit, maar het gaat om zakelijke glasvezel internet - gemiddeld krijgen wij zo'n 150Mbps DL en 50Mbps DL (met VPN!) of zelfs 250Mbps DL en 120Mbps UL (zonder VPN) - dus ik kan niet klagen 8)
-
Hallo weer!
ik zit weer op mijn werk en dit krijg ik met tracert:
[attachimg=1]
als ik het goed begrijp van je uitleg @Briolet is geen enkel router lokaal?
-
ik heb mijn vraag trouwens alsnog aan de technische beheerder van het pand voorgelegd - misschien is er toch iets fout met het poort forwarding - ik laat het weten als ik iets terug hoor..
Groetjes!
-
Dat 2e IP (185.230.125.33) is een nummer uit Zwitserland. (Die naam suggereert het ook een beetje)
185.206.226.118 is een brits IP nummer.
Alle volgende t/m hop nr 8 zijn ook brits. Pas bij hop 9 zit je weer in Nederland en kom je vervolgens bij dit forum uit.
Ik heb geen idee waarom het bedrijf een verbinding via Zwitserland heeft lopen en waarop de lokale routers niet in een traceroute voorkomen. Zo'n omweg geeft wel belachelijk grote ping waardes.
-
Ik heb geen idee waarom het bedrijf een verbinding via Zwitserland heeft lopen en waarop de lokale routers niet in een traceroute voorkomen.
Ah! dat was de VPN ::)
Zonder VPN kreeg ik inderdaad een andere lokale router te zien - dan kan het alsnog daar aan liggen - ik ga dus eerst de reactie van de technische beheerder van het pand afwachten..
-
zojuist na een lange stilte een reactie van Synology support ontvangen:
Based on log message, it seems your network is not stable.
Apr 07 03:03:13 [ERROR] proto-ui.cpp(286): failed to connect to server at 92.111.19.127:51802
Apr 07 03:03:13 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 07 03:03:13 [ERROR] proto-ui.cpp(286): failed to connect to server at fe80:0:0:0:231:32ff:fe85:b852:6690
Apr 07 03:03:13 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 07 03:03:13 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 07 03:03:13 [ERROR] long-poller.cpp(348): Failed to send/recv long poll request. (code: -2)
Apr 07 03:03:13 [ERROR] long-poller.cpp(183): Failed to long poll event for connection 2, fallback to pull event. (code: -2)
Apr 07 03:03:13 [ERROR] connection.cpp(628): Failed to find connection for server 'boco918' (use_quick_connect_server = No) (reason: 'Cannot connect to server, we've tried our best.')
Apr 07 03:03:13 [INFO] error-handler.cpp(70): Worker (4190947): Handle error: I/O error.
Apr 07 03:03:14 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 07 03:03:14 [INFO] error-handler.cpp(70): Worker (419988): Handle error: I/O error.
Could you please, help to check your network setting? If you are using the QuickConnect id to connect the 2 NAS:
1. Please help us to check the DNS Server and Gateway settings are properly configured on Diskstation.
Usually, the gateway and DNS should be your router's IP address, and we suggest to use a Public DNS server as DNS server instead of your Router.
You can set up DNS server to 8.8.8.8 or 8.8.4.4 (Google's public Server) in Control Panel > Network.
2. Please go to Control Panel > Network > Network Interface > edit > IPv6, change the setting from "Auto" to "Disable"; in IPv4 tab, please uncheck "jumbo frame" option.
3. Please go to Control Panel > External Access, and enable Heartbeat again.
4. It is possible the function [Firewall] or [Auto Block] of Synology NAS is blocking your accessing. To release the rules of [Firewall], suppose now you still could access DSM GUI, you could go to DSM > Control Panel > Firewall > Uncheck all rules and click save.
5. Please go to DSM > Control Panel > Regional Options to sync the time with one NTP server.
Ik heb dus alle punten even gecontroleerd - het enige wat veranderd moest worden was de DNS naar 8.8.8.8 wijzigen.
Nu is er iets veranderd:
[attachimg=1]
je kunt dus zien dat de verbinding hoge punten van bijna 1200Kbps bereikt, maar dan zakt het het helaas ook snel omlaag (ik heb het zojuist even gecheckt en het staat weer op 10Kbps :( )
Iemand een idee?
-
Ok, nu eerst even vaststellen:
- De verbinding is er met gebruikmaking van of IP-Adres of DDNS of QC ?
- - M.a.w. de port forwarding is goed ? (met QC hoeft dat niet maar, mag wel).
- Ben je geheel opnieuw aan het syncen ?
- - Als dat waar is, dan zou ik een meer contante (hoge) upload zien.
of
- Heb je de oude sync (die je thuis had gedaan) herkoppeld ?
Als dat waar is, dan is er geen constante upload, je krijgt pieken en dalen.
Alhoewel, in het algemeen, vind ik 1MB upload niet echte geweldig als de beheerder aangeeft 30MB/sec ::)
-
Doe anders eens een test op kantoor in PuTTY:
time wget -O /dev/null http://speedtest.ams01.softlayer.com/downloads/test500.zip
-
Goedemorgen!
@Birdy - ik zit weer op kantoor en heb PuTTY gedownload - maar hoe/wat moet ik verder doen? (sorry, maar ik heb er weinig/geen verstand van..)
- De verbinding is er met gebruikmaking van of IP-Adres of DDNS of QC ?
- - M.a.w. de port forwarding is goed ? (met QC hoeft dat niet maar, mag wel).
QC
- Ben je geheel opnieuw aan het syncen ?
- - Als dat waar is, dan zou ik een meer contante (hoge) upload zien.
of
- Heb je de oude sync (die je thuis had gedaan) herkoppeld ?
Als dat waar is, dan is er geen constante upload, je krijgt pieken en dalen.
oude sync herkoppeld - maar er zijn al grote wijzigingen (nieuwe bestanden) van een paar GB geweest, dus volgens mij hoort het bezig te zijn..?
Alhoewel, in het algemeen, vind ik 1MB upload niet echte geweldig als de beheerder aangeeft 30MB/sec
Ja - dat vind ik ook!
-
Zie hier (https://www.synology-forum.nl/algemeen/nas-benaderen-met-ssh-winscp-putty/) onder: DSM6 en hoger: Wil je alleen PuTTY (CLI: Linux/DSM kennis vereist):
-
dank voor de link @Birdy - het is gelukt!
[attachimg=1]
en nu?
-
Goed resultaat :!:
Dus, dat is het niet.
oude sync herkoppeld - maar er zijn al grote wijzigingen (nieuwe bestanden) van een paar GB geweest, dus volgens mij hoort het bezig te zijn..?
Zoals gezegd: "dan is er geen constante upload, je krijgt pieken en dalen."
Is die sync dan nu nog bezig ? Zo ja, sinds ?
-
Goed resultaat :!:
Dus, dat is het niet.
fijn om te horen :)
Zoals gezegd: "dan is er geen constante upload, je krijgt pieken en dalen."
Is die sync dan nu nog bezig ? Zo ja, sinds ?
Ja - de sync is nog steeds bezig - al een paar dagen inmiddels - maar alleen met de nieuwe grote bestanden (ongeveer 8GB samen). Ik heb het gevoel dat het al een paar keer opnieuw is begonnen (maar ik kan het niet zeker terugzien). De pieken en dalen lijken echter heel extreem - het gaat over van ongeveer 500Kbps naar 2Kbps iedere paar seconden..
-
Zal vandaag eens kijken of ik "onder water" een log file kan vinden waarin mogelijk e.e.a. duidelijk wordt.
-
Aan de Cloud Station ShareSync kant, dus thuis:
File Station: maak even een map aan in een gedeelde map b.v. "logfiles"
Geef in PuTTY het volgende commando:
cp /volume1/@CloudStationClient/log/* /volume1/[b]<een gedeelde map>/logfiles[/b]
File Station: zip de map logfiles en plaats die zip in dit Topic, dan zal ik er eens naar kijken.
-
O ja, @boco in die log files wordt ook vermeld welke files er verzonden/bijgewerkt worden.
Als je niet wilt dat deze info hier in het openbaar geplaatst wordt (als bijlage), stuur mij dan even een PM, dan geef ik je mijn e-mail adres.
Je kunt natuurlijk ook zelf in de files kijken en mogelijk ontdekken wat er aan de hand is. ;)
-
Dank @Birdy - ik ben pas donderdag weer op kantoor - dan ga ik er naar kijken en iets laten weten.
En in de tussentijd heb ik ook even thuis de PuTTY command geprobeerd en het resultaat is volgens mij veel minder:
[attachimg=1]
De verbinding hier is wat minder als op mijn werk, maar zo traag moet het ook niet zijn - zie speedtest.net resultaat van zojuist:
[attachimg=2]
ik weet niet of je hier iets aan hebt..?
-
Laatste plaatje, upload is behoorlijk laag, max 1MB/sec, dat kan dus de reden zijn.
Althans, je upload toch naar kantoor?
En wat betreft de log files, die moet je dus hebben van je NAS thuis.
-
Aangezien de upload thuis niet hoger komt dan 7.79/Mbps (1MB) met een Abo van 25/Mbps (3MB), zou ik de UTP kabel tussen de Linksys E4200 en de Experia Box v8 eens vervangen.
-
oké - ik ga straks een nieuwe UTP kabel halen - maakt het veel uit nou of het CAT.6 of CAT.5e is? - de huidige is een 2m lang CAT.5e.
En hoe kom je aan 1MB en 3MB van de 7.79/Mbps en 25/Mbps?
De snelheden variëren veel trouwens - ik heb zojuist weer een speedtest.net gedaan en krijg de volgende:
[attachimg=1]
-
Cat 5e is voldoende voor gigabit.
-
En hoe kom je aan 1MB en 3MB van de 7.79/Mbps en 25/Mbps?
1 Mbps (megabit/ps) = 0.125 MB/s
Dus, deel Mbps door 8 en je komt op MB's
-
UTP kabel is vervangen - ik merk geen verschil - hoe kan ik het testen?
File Station: maak even een map aan in een gedeelde map b.v. "logfiles"
Geef in PuTTY het volgende commando:
Code: [Selecteer]
cp /volume1/@CloudStationClient/log/* /volume1/<een gedeelde map>/logfiles
File Station: zip de map logfiles en plaats die zip in dit Topic, dan zal ik er eens naar kijken.
moet die gedeelde map eigenlijk ook gesynchroniseerd zijn met de DS918+?
-
Nope
-
dscc.log*.* files ontvangen en bekeken:
Laatste goede sync was:
Apr 06 21:29:02 [INFO] error-handler.cpp(70): Worker (4025284): Handle error: Successful.
Volgende file volgt:
Apr 06 21:42:41 [INFO] stream.cpp(385): sending /volume1/SHARED/…..<FILE-X>.
Echter, zie dan ineens poort 51802 verschijnen:
Apr 06 22:00:44 [INFO] conn-finder.cpp(954): QuickConnect(<QC-ID>.quickconnect.to): Successfully get server info.
Apr 06 22:00:44 [ERROR] proto-ui.cpp(286): failed to connect to server at <LOCAL-IP>:6690
Apr 06 22:00:54 [ERROR] proto-ui.cpp(286): failed to connect to server at <IPV6-IP>:6690
Apr 06 22:00:54 [ERROR] proto-ui.cpp(286): failed to connect to server at <EXTERN-IP>:51802
Maar goed, misschien dat je wat met het poort nummer van Cloud Share Sync hebt zitten rommelen ?
Sinds 8 april weer de juiste poort:
Apr 08 05:36:03 [ERROR] proto-ui.cpp(286): failed to connect to server at <EXTERN-IP>:6690
Maar connecties blijven falen en blijft proberen om steeds dezelfde FILE-X te syncen.
Dus, ik ga verder naar 11 april en zie dezelfde errors sinds 8 April:
Apr 11 16:23:38 [WARNING] stream.cpp(1177): Channel: -2
Apr 11 16:23:38 [ERROR] stream.cpp(1776): Error stack:
Apr 11 16:23:38 [ERROR] protocol-client.cpp(411): Failed to receive message header. (code: -2)
Apr 11 16:23:38 [ERROR] protocol-client.cpp(184): Failed to send protocol. (code: -2)
Apr 11 16:23:39 [INFO] protocol-client.cpp(196): This channel is with an I/O error, erasing the connection info to enforce finding connection in the next run.
Apr 11 16:23:39 [ERROR] long-poller.cpp(348): Failed to send/recv long poll request. (code: -2)
Apr 11 16:23:39 [ERROR] long-poller.cpp(183): Failed to long poll event for connection 2, fallback to pull event. (code: -2)
Apr 11 16:23:39 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:39 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:39 [INFO] conn-finder.cpp(581): ip '<QC-ID>' is not a IPv4 address
Apr 11 16:23:39 [INFO] error-handler.cpp(70): Worker (7198140): Handle error: I/O error.
Apr 11 16:23:39 [INFO] conn-finder.cpp(915): QuickConnect: Successfully get server info for '<QC-ID>' from global server
Apr 11 16:23:39 [ERROR] proto-ui.cpp(286): failed to connect to server at <IPV6-IP>
Apr 11 16:23:39 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 11 16:23:42 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:42 [ERROR] long-poller.cpp(348): Failed to send/recv long poll request. (code: -2)
Apr 11 16:23:42 [ERROR] long-poller.cpp(183): Failed to long poll event for connection 2, fallback to pull event. (code: -2)
Apr 11 16:23:42 [ERROR] proto-ui.cpp(286): failed to connect to server at <LOCAL-IP>:6690
Apr 11 16:23:42 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 11 16:23:43 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:43 [INFO] error-handler.cpp(70): Worker (7198170): Handle error: I/O error.
Apr 11 16:23:45 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:45 [ERROR] long-poller.cpp(348): Failed to send/recv long poll request. (code: -2)
Apr 11 16:23:45 [ERROR] long-poller.cpp(183): Failed to long poll event for connection 2, fallback to pull event. (code: -2)
Apr 11 16:23:46 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:46 [INFO] error-handler.cpp(70): Worker (7198199): Handle error: I/O error.
Apr 11 16:23:48 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:48 [ERROR] long-poller.cpp(348): Failed to send/recv long poll request. (code: -2)
Apr 11 16:23:48 [ERROR] long-poller.cpp(183): Failed to long poll event for connection 2, fallback to pull event. (code: -2)
Apr 11 16:23:50 [ERROR] proto-ui.cpp(286): failed to connect to server at <EXTERN-IP>:6690
Apr 11 16:23:50 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 11 16:23:50 [ERROR] proto-ui.cpp(286): failed to connect to server at <EXTERN-IP>:6690
Apr 11 16:23:50 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 11 16:23:50 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:50 [INFO] error-handler.cpp(70): Worker (7198228): Handle error: I/O error.
Apr 11 16:23:50 [ERROR] proto-ui.cpp(286): failed to connect to server at <GEEN IDEE WAT DIT VOOR EEN ADRES IS>
Apr 11 16:23:50 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 11 16:23:51 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:51 [ERROR] long-poller.cpp(348): Failed to send/recv long poll request. (code: -2)
Apr 11 16:23:51 [ERROR] long-poller.cpp(183): Failed to long poll event for connection 2, fallback to pull event. (code: -2)
Apr 11 16:23:53 [INFO] protocol-client.cpp(148): Failed to establish a new channel (-2), trying to find a new connection.
Apr 11 16:23:53 [INFO] error-handler.cpp(70): Worker (7198257): Handle error: I/O error.
Apr 11 16:23:53 [INFO] error-handler.cpp(70): Worker (7198141): Handle error: I/O error.
Apr 11 16:23:58 [INFO] error-handler.cpp(70): Worker (7198292): Handle error: Successful.
Apr 11 16:23:59 [WARNING] stream.cpp(1177): Channel: -2
Apr 11 16:23:59 [ERROR] stream.cpp(1776): Error stack:
Apr 11 16:23:59 [ERROR] protocol-client.cpp(184): Failed to send protocol. (code: -1)
Apr 11 16:24:00 [INFO] error-handler.cpp(70): Worker (7198287): Handle error: Successful.
Apr 11 16:24:02 [WARNING] stream.cpp(1177): Channel: -2
Apr 11 16:24:02 [ERROR] stream.cpp(1776): Error stack:
Apr 11 16:24:02 [ERROR] protocol-client.cpp(184): Failed to send protocol. (code: -1)
Waarbij FILE-X (is dus even een fake naam) steeds terugkomt.
M.a.w., het syncen blijft steken op FILE-X !
Nu denk ik, dat die FILE-X (ik stuur je een PM met die info) de schuld is van alles (hoogst onwaarschijnlijk maar, wel verdacht) maar, ik zou de Cloud Share Sync even stoppen en FILE-X even verplaatsen naar een map die niet synced wordt.
Daarna Cloud Share Sync weer starten.
Dit, om gewoon te zien of de sync nu wel goed verder gaat.
Verder had het geen zin om de file dscc_cgi.log en dscc_monitor.log te bekijken, omdat daar in het kort staat wat ik in de dscc.log*.* files staan.
Overigens, ik was wel instaat om met je Quick Connect op de inlog pagina van je DS918 te komen.
-
Dankjewel @Birdy!
Maar goed, misschien dat je wat met het poort nummer van Cloud Share Sync hebt zitten rommelen ?
nee - ik heb niets mee gedaan - zeker niet op die datum (?)
Nu denk ik, dat die FILE-X (ik stuur je een PM met die info) de schuld is van alles (hoogst onwaarschijnlijk maar, wel verdacht) maar, ik zou de Cloud Share Sync even stoppen en FILE-X even verplaatsen naar een map die niet synced wordt.
Daarna Cloud Share Sync weer starten.
Dit, om gewoon te zien of de sync nu wel goed verder gaat.
Het klopt dat FILE-X al dagen blijft opnieuw starten - deze heb ik namelijk in de sync map geplaatst toen de rest volledig gesynchroniseerd was, om te kijken of het zoals behoren ook ging synchroniseren (niet dus..).
Dit komt door dat ik voor de WERK map, die voor mij het belangrijkste is om te synchroniseren, nog niet heb gesynchroniseerd (om problemen/dataverlies te voorkomen) - dit wil ik pas doen zodra ik zeker weet dat alles goed loopt - voorlopig gebruik ik die "SHARED" map om te testen, en FILE-X heb ik gekozen als voorbeeld van een grote (8GB) bestand om te kijken hoe het gaat.
Maar goed - ik heb de sync even gestopt, FILE-X verplaatst en de sync weer gestart - nu geeft ie aan dat alles gesynchroniseerd is, dus ik kan niet weten hoe/wat zou gebeuren als ik weer grote bestanden zou moeten synchroniseren. Zal ik er weer een andere grote bestand proberen te plaatsen?
Overigens, ik was wel instaat om met je Quick Connect op de inlog pagina van je DS918 te komen.
- dat is toch de bedoeling?
-
nee - ik heb niets mee gedaan - zeker niet op die datum (?)
Hm...dat is dan heel vreemd.
nu geeft ie aan dat alles gesynchroniseerd is
Het goede nieuws is dus, dat na het verwijderen van die FILE-X, de connectie direct weer goed was.
Zal ik er weer een andere grote bestand proberen te plaatsen?
Zou ik zeker even een andere grote file proberen.
- dat is toch de bedoeling?
Jazeker, het was voor mij alleen maar de eerste test of ik bij je NAS kon komen, gezien de vele connectie fouten.
-
Hm...dat is dan heel vreemd.
Ja, vind ik ook - ik heb wel op beide router een paar keer poort 6690 (opnieuw-) geprobeerd te forwarden, maar die poort 51802 zegt mij helemaal niets.
Het goede nieuws is dus, dat na het verwijderen van die FILE-X, de connectie direct weer goed was.
Ja, maar eigenlijk alles was al gesynchroniseerd - de map was verder van de oude NAS naar de nieuwe volledig gekopieerd, dus het enige verschil was FILE-X..
Zou ik zeker even een andere grote file proberen.
Ik ga het zo doen - ik houd je op de hoogte..
EN
Zojuist nog een reactie van Synology support (die hebben trouwens even remote-access toegang tot mijn DS's)
I have found that you have used your QuickConnect ID to create the sync task, the sync speed will be relatively slow while using QuickConnect. I would recommend you use the IP address instead of the QuickConnect to see if helps
Als het daar aan zou liggen vind ik het uiteraard prima om het IP adres ipv QC te gebruiken, echter als ik het adres die ik via http://whatismyipaddress.com/ krijg invul kan ik geen verbinding maken.. of doe ik daar iets verkeerd?
-
Ja, maar eigenlijk alles was al gesynchroniseerd - de map was verder van de oude NAS naar de nieuwe volledig gekopieerd, dus het enige verschil was FILE-X..
Klopt, heb ik ook gezien, het was ook alleen maar mijn constatering. ;D
I have found that you have used your QuickConnect ID to create the sync task, the sync speed will be relatively slow while using QuickConnect. I would recommend you use the IP address instead of the QuickConnect to see if helps
Dat had ik je al verteld in deze reactie (https://www.synology-forum.nl/netwerk-algemeen/trage-cloud-serverclient-synchronisatie/msg247787/#msg247787). ;)
echter als ik het adres die ik via http://whatismyipaddress.com/ krijg invul kan ik geen verbinding maken.. of doe ik daar iets verkeerd?
Heb je whatismyipaddress.com wel op kantoor gedaan dus, niet thuis ?
-
oké, nu is de sync van het nieuwe bestand (4.2GB) even bezig - maar nog steeds niet snel (genoeg) en ook niet constant:
[attachimg=1]
I have found that you have used your QuickConnect ID to create the sync task, the sync speed will be relatively slow while using QuickConnect. I would recommend you use the IP address instead of the QuickConnect to see if helps
Dat had ik je al verteld in deze reactie. ;)
Ja, dat was ik niet vergeten :) maar ik heb het eigenlijk toch niet kunnen proberen omdat ik met het IP adres geen verbinding kon maken..
En als wij het even weer over port forawrding hebben - op mijn werk adres lijkt 6690 wél forwarded te zijn, terwijl thuis niet. Thuis zit alleen maar de Experia Box V8 in bridge modus achter de Linksys E4200 en verder niets, dus ik snap echt niet waarom het toch niet forwarded schijnt te zijn? Ik heb zelf contact opgenomen met Telfort en zij gaven aan dat zij zelf geen poorts blokkeren..
echter als ik het adres die ik via http://whatismyipaddress.com/ krijg invul kan ik geen verbinding maken.. of doe ik daar iets verkeerd?
Heb je whatismyipaddress.com wel op kantoor gedaan dus, niet thuis ?
Ja, op kantoor 8)
-
omdat ik met het IP adres geen verbinding kon maken..
Nu nog steeds niet ?
Dus, de nu lopende sync loopt via QC?
En als wij het even weer over port forawrding hebben - op mijn werk adres lijkt 6690 wél forwarded te zijn, terwijl thuis niet
Je hoeft thuis poort 6690 ook niet te forwarden, zie hier (https://www.synology-forum.nl/netwerk-algemeen/trage-cloud-serverclient-synchronisatie/msg247832/#msg247832).
Ja, op kantoor
OK....dan moet het toch kunnen met dat Externe IP-Adres.
Gisteravond kon ik n.l. Het externe IP-Adres (kantoor) gewoon pingen en bereiken met tracert.
-
Overigens, v.w.b. het externe IP-adres, ik heb gezien in de logs, dat het adres, die met QC wordt opgehaald, heel anders is dan wat je hier hebt getoond met tracert (https://www.synology-forum.nl/netwerk-algemeen/trage-cloud-serverclient-synchronisatie/msg247922/#msg247922).
In de log zie ik n.l. 92.xxx.xx.117 en die vind ik niet terug in tracert.
Ik zou het eens proberen met DDNS en dan kijken of je wel verbinding krijgt.
En ja, je upload is nog steeds bijzonder traag.
-
Nu nog steeds niet ?
Nee, met het adres die ik op http://whatismyipaddress.com/ krijg in ieder geval niet :(
Dus, de nu lopende sync loopt via QC?
Ja.
Je hoeft thuis poort 6690 ook niet te forwarden, zie hier.
Oké - maar ook als het om een 2-way sync gaat?
OK....dan moet het toch kunnen met dat Externe IP-Adres.
Gisteravond kon ik n.l. Het externe IP-Adres (kantoor) gewoon pingen en bereiken met tracert.
Zou je misschien anders even het adres die jij had gevonden even per PM willen sturen? dan kan ik het nogmaals daarmee proberen..
Overigens, v.w.b. het externe IP-adres, ik heb gezien in de logs, dat het adres, die met QC wordt opgehaald, heel anders is dan wat je hier hebt getoond met tracert.
Ja - dat klopt - dit was met VPN aan - dit had ik toen ook later aangegeven :)
In de log zie ik n.l. 92.xxx.xx.117 en die vind ik niet terug in tracert.
Zegt mij ook niets - kan het misschien iets met Synology Suport te maken?
Ik zou het eens proberen met DDNS en dan kijken of je wel verbinding krijgt.
Dit was mij ook (eerder) niet gelukt - ik kan het proberen als het IP adres echt niet werkt..?
-
Oké - maar ook als het om een 2-way sync gaat?
Yep, als eenmaal de connectie is gelegd, gaat het 2-way, Cloud Station is de boss, zeg maar.
Zou je misschien anders even het adres die jij had gevonden even per PM willen sturen?
Doe ik.
-
Dank @Birdy
Het was niet gelukt met het IP adres :( (voor de zekerheid - deze had ik gewoon moeten knippen en plakken in de eerste veld, toch?)
Maar ik vind het sowieso een beetje verwarrend - het IP adres is toch van de router en niet van de DS?
Kan het zijn dat dit adres van de router van het hele pand is? (en als ja, hoe moet ik bij het adres van mijn eigen router komen)
-
deze had ik gewoon moeten knippen en plakken in de eerste veld, toch?
Yep.
het IP adres is toch van de router en niet van de DS
Klopt.
Kan het zijn dat dit adres van de router van het hele pand is?
Nee, omdat ik kan zien in de log file(s) dat Quick Connect uiteindelijk het Extern IP-adres ophaalt en gebruikt.
Ik verwacht dan ook, dat het adres, die ik je zojuist gegeven heb, kunt terugvinden in 1 van de dscc.log*.* files, sinds de sync weer loopt.
-
deze had ik gewoon moeten knippen en plakken in de eerste veld, toch?
Yep.
het IP adres is toch van de router en niet van de DS
Klopt.
Kan het zijn dat dit adres van de router van het hele pand is?
Nee, omdat ik kan zien in de log file(s) dat Quick Connect uiteindelijk het Extern IP-adres ophaalt en gebruikt.
Ik verwacht dan ook, dat het adres, die ik je zojuist gegeven heb, kunt terugvinden in 1 van de dscc.log*.* files, sinds de sync weer loopt.
Hmm.. maar waarom kan ie dus geen verbinding maken? (ik heb het trouwens met en zonder SSL geprobeerd) - met QC is het zó gebeurt..
[attachimg=1]
en wat kan ik anders doen?
-
Ik heb werkelijk geen ideeën maar, ik wil het zelf eens proberen, als je het goed vind.
Zo ja, maak even een gebruiker en geef die alleen rechten om Cloud Station ShareSyc te mogen gebruiken.
PB mij dan de inlog.
Dan doe ik alleen de connectie test en kan dan gelijk in m'n log kijken wat er gebeurt.
-
Laat maar @boco het gaat al fout als ik zomaar een gebruiker en password gebruik, de connectie faalt gewoon, dus het checken van gebruiker en password, kan al niet worden gedaan.
Apr 12 16:42:02 [ERROR] proto-ui.cpp(286): failed to connect to server at <ExternIP Kantoor>:6690
Apr 12 16:42:02 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 12 16:42:13 [ERROR] proto-ui.cpp(286): failed to connect to server at <ExternIP Kantoor>:6690
Apr 12 16:42:13 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 12 16:42:13 [ERROR] Connection/test.cpp(58): TestConnection to '<ExternIP Kantoor>' failed
Ik heb er gewoon geen verklaring voor, QC gebruikt n.l. hetzelfde IP-Adres :!:
OF de port forwarding is gewoon niet goed (QC heeft het n.l. niet nodig, die forwarding, als je op IP-Adres of DDNS doet dan juist wel)
-
Laat maar @boco het gaat al fout als ik zomaar een gebruiker en password gebruik, de connectie faalt gewoon dus, het checken van gebruiker en password, kan niet worden gedaan.
Apr 12 16:42:02 [ERROR] proto-ui.cpp(286): failed to connect to server at <ExternIP Kantoor>:6690
Apr 12 16:42:02 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 12 16:42:13 [ERROR] proto-ui.cpp(286): failed to connect to server at <ExternIP Kantoor>:6690
Apr 12 16:42:13 [ERROR] conn-finder.cpp(195): TestConnect: error code -200, error message: 'channel error while connecting to server'
Apr 12 16:42:13 [ERROR] Connection/test.cpp(58): TestConnection to '<ExternIP Kantoor>' failed
Ik heb er gewoon geen verklaring voor, QC gebruikt n.l. hetzelfde IP-Adres :!:
Ja, dat dacht ik al :(
Maar hoe kan dit nou? zo kan ik dus ook niet met DDNS verbinding maken.
Waar zou het aan kunnen liggen? is er misschien een ander IP adres die hiervoor kan gebruiken - ik snap er echt niets van :oops:
-
Port forwarding, blijft over, ik heb het idee dat de beheerder 6690 niet toelaat.
Ik begrijp dat je ook VPN gebruikt ?
Van Thuis naar Kantoor ?
Dan heb je ook port forwarding nodig en waarschijnlijk laat de beheerder juist die poort(en) WEL toe.
En, als dat wel werkt, dan kun je het ook via VPN naar kantoor doen, gebruik dan het lokale IP-Adres van de NAS.
-
Dank @Birdy
VPN gebruik ik alleen op de computers, dus ik denk niet dat het iets met de NAS te maken heeft (?).
Maar morgen ga ik in ieder geval weer contact opnemen met de netwerk beheerder van het pand en kijken of ze alsnog port 6690 kunnen forwarden specifiek naar onze router..
Ik laat het horen!
-
VPN gebruik ik alleen op de computers, dus ik denk niet dat het iets met de NAS te maken heeft (?).
Kan wel, je kunt n.l. VPN Server op je NAS draaien maar, ik begrijp al dat je die optie niet gebruikt. ;)
-
Suggestie:
Meest eenvoudige test voor mij om te controleren of verbinding mogelijk is, is via telnet
telnet <extern ipnr> 6690
Indien je een zwart scherm krijgt heb je verbinding.
Krijg je 'Could not open connection to the host....' dan is er iets fout met de verbinding.
Dit zou je kunnen uitproberen vanuit kantoorPC (zonder en met VPN) naar het externe ip nr van je kantoor en naar thuis maar ook vanuit thuis naar je exteren ipnr van kantoor en thuis.
Dan weet je of je via poort verbinding tussen de 2 locaties kunt maken.
Als er op je kantoor lokatie maar 1 router staat zou in die router een forward moeten staan naar je kantoor NAS.
Staat er op je kantoor meeerdere routers dan wordt het een ingewikkelder verhaal.
Just my 5 cents
-
Gedaan:
[attachimg=1]
Maar goed, de dscc.log*.* files geven het ook aan. ;)
Staat er op je kantoor meeerdere routers dan wordt het een ingewikkelder verhaal.
Het pand (kantoor) heeft 1 router ingang, daarna hebben de kantoren een eigen router dus, een ingewikkelder verhaal.
Waarom het via QC wel lukt ? Omdat QC geen port forwarding gebruikt, initieel.
Dus, met of zonder port forwarding, QC werkt.
-
Dank @hansiedown , @Birdy
Helaas heb ik vandaag de technische beheerder van het pand niet te pakken gekregen - dan moet ik het weer maandagochtend proberen.. een update volgt..
-
Hoi! Even een update:
Inmiddels heeft de beheerder van het pand poort 6690 naar onze router geforward, maar ik heb helaas geen verschil/verbetering gemerkt..
En vanochtend heb ik ruim 2 uur (!) een Team View sessie met Synology support gehad - de medewerker was diverse dingen aan het aanpassen zoals MTU value (die tot nu toe uitgeschakeld was), DNS server naar 8.8.8.8 gewijzigd, Heartbeat uit (en weer aan-) geschakeld en ook meerdere commando's en tests uitgevoerd via PuTTY.
Het was hem trouwens ook niet gelukt om direct met het externe IP adres een verbinding met de NAS te maken en ook niet met DDNS.
Uiteindelijk heeft hij geconcludeerd dat alles (inclusief netwerk/internet verbindingen) naar behoren was, dus hij heeft nog 2 debug log's van beide NAS uitgedraaid en deze gaat hij aan de "developers voorleggen".
Nog geen echt nieuws dus, maar hopelijk kunnen ze erachter komen wat hier het probleem is.
Ik laat het wel weten als ik een update ontvang.. 8)