[Synology] Vraag en antwoord - deel 2

[SmiGueL]

Zorian schreef op dinsdag 28 februari 2017 @ 11:11:
Nou is het dus zo dat als ik thuis ben en ik naar de NAS ga hij altijd automatisch naar http://192.168.1.100:5000 gaat.

Zelf heb ik een bookmark die naar http://11.22.33.44:5000 gaat, maar als ik bijvoorbeeld jou zou willen

Begrijp ik goed dat je al die moeite wilt doen zodat je die 1 of 2 bookmarks niet hoeft aan te passen?

Hint: Pas je bookmarks aan.

Edit:
@Zorian Had niet door dat je thuis niet op domein kon verbinden (kan het zelf volgens mij wel gewoon, maar ligt wss aan m'n router) Kun je in je browser dat IP / die pagina niet toevoegen als veilig zodat die melding weg blijft? Dan is het toch ook opgelost?

[ Voor 28% gewijzigd door SmiGueL op 28-02-2017 11:55 ]

[Zorian]

SmiGueL schreef op dinsdag 28 februari 2017 @ 11:28:
[...]


[...]


Begrijp ik goed dat je al die moeite wilt doen zodat je die 1 of 2 bookmarks niet hoeft aan te passen?

Hint: Pas je bookmarks aan.

Half. Zoals ik zei forward de QuickConnect zichzelf dus naar http://11.22.33.44:5000, echter werkt QC niet altijd. Vandaar dat ik nog een fallback heb in de vorm van http://nas.domein.nl:5000 (welke meteen ook makkelijker te onthouden is).
Beiden doen het echter niet als ik thuis ben, want dan is ie alleen te benaderen via http://192.168.1.100:5000 (en QC forward dus ook daarheen dan).

[afterburn]

@Zorian: Heb je dan ook het (default) certificaat in de Synology aangepast, zodat deze wordt gebruikt voor de admin pagina? Standaard gebruikt de admin pagina namelijk het Synology.com certificaat wat meegeleverd wordt. Je zal dit wel handmatig moeten wijzigen naar een ander certificaat als je dat wilt gebruiken.

[Zorian]

afterburn schreef op dinsdag 28 februari 2017 @ 11:35:
@Zorian: Heb je dan ook het certificaat in de Synology aangepast, zodat deze wordt gebruikt voor de admin pagina? Standaard gebruikt de admin pagina namelijk het Synology.com certificaat wat meegeleverd wordt. Je zal dit wel handmatig moeten wijzigen naar een ander certificaat als je dat wilt gebruiken.

Daar heb ik nog niks mee gedaan aangezien ik het niet voor elkaar kreeg een ander/beter certificaat in elkaar te draaien. Heb HTTPS dus ook uit staan.

[ShadowLord]

Zorian schreef op dinsdag 28 februari 2017 @ 11:32:
[...]

Half. Zoals ik zei forward de QuickConnect zichzelf dus naar http://11.22.33.44:5000, echter werkt QC niet altijd. Vandaar dat ik nog een fallback heb in de vorm van http://nas.domein.nl:5000 (welke meteen ook makkelijker te onthouden is).

Stel je NAS/QuickConnect in dat het het domein gebruikt ipv je externe IP. Om dit te doen, ga naar Control Panel (mogelijk moet je hem even in 'Advanced mode' zetten), en kies onder 'Connectivity' voor 'External Access'. In het menu wat je nu ziet, ga naar het 3e tabblad (Advanced). Hier kun je je domeinnaam invullen. Je zal merken dat wanneer je NAS nu (bijvoorbeeld) mail verstuurd hij de domeinnaam noemt ipv het (interne) IP adres.
Zelf gebruik ik overigens geen QuickConnect (heb niet voor niets een domeinnaam ), dus weet niet 100% zeker of dit ook helpt voor QuickConnect maar ik verwacht van wel. Zie ook: https://www.synology.com/...on_public_access_advanced

Beiden doen het echter niet als ik thuis ben, want dan is ie alleen te benaderen via http://192.168.1.100:5000 (en QC forward dus ook daarheen dan).

In dat geval doet je router niet goed aan [url="tps://en.wikipedia.org/wiki/Network_address_translation#NAT_loopback"]NAT loopback[/url]. Want als dat wel werkt kun je alsnog gewoon bij je NAS via het externe domein.

Zorian schreef op dinsdag 28 februari 2017 @ 11:11:
Hoe voeg je overigens meerdere IP's/domeinen toe aan 1 certificaat bij Let's Encrypt? En moet dit nou echt een domein zijn zoals bijvoorbeeld tweakers.net of mogen IP's ook?

Bij het doorlopen van de wizzard in DSM voor het aanmaken van een certificaat vraagt hij hier om. Het veld dat je zoekt is het 'Subject Alternative Name'. Hier kun je een aantal extra domeinnamen opgeven (gescheiden door een ';') die ook zullen werken met het certificaat.

[Zorian]

ShadowLord schreef op dinsdag 28 februari 2017 @ 12:11:
[...]

Stel je NAS/QuickConnect in dat het het domein gebruikt ipv je externe IP. Om dit te doen, ga naar Control Panel (mogelijk moet je hem even in 'Advanced mode' zetten), en kies onder 'Connectivity' voor 'External Access'. In het menu wat je nu ziet, ga naar het 3e tabblad (Advanced). Hier kun je je domeinnaam invullen. Je zal merken dat wanneer je NAS nu (bijvoorbeeld) mail verstuurd hij de domeinnaam noemt ipv het (interne) IP adres.
Zelf gebruik ik overigens geen QuickConnect (heb niet voor niets een domeinnaam ), dus weet niet 100% zeker of dit ook helpt voor QuickConnect maar ik verwacht van wel. Zie ook: https://www.synology.com/...on_public_access_advanced


[...]

In dat geval doet je router niet goed aan [url="tps://en.wikipedia.org/wiki/Network_address_translation#NAT_loopback"]NAT loopback[/url]. Want als dat wel werkt kun je alsnog gewoon bij je NAS via het externe domein.


[...]

Bij het doorlopen van de wizzard in DSM voor het aanmaken van een certificaat vraagt hij hier om. Het veld dat je zoekt is het 'Subject Alternative Name'. Hier kun je een aantal extra domeinnamen opgeven (gescheiden door een ';') die ook zullen werken met het certificaat.

Ik heb nu met succes een certificaat voor http://nas.domein.nl erin weten te rammen. Die extra dingen opgeven resulteerde erin dat ie een dikke NOPE gaf bij het importeren.
Als ik de NAS nu bezoek via http://nas.domein.nl:5000 forward ie meteen netjes naar https://nas.domein.nl:5001 en hij zegt dat de verbinding veilig is..
Echter is de NAS nu onbereikbaar via lokaal IP omdat hij zegt dat er zoveel certificaat mismatch is dat de verbinding wordt verbroken. Logisch, want hij geldt enkel voor "nas.domein.nl".

[afterburn]

Dan moet je dus zoals ik zei een lokale DNS draaien die nas.domein.nl resolved naar een lokaal adres, of even een hostfile entry aanmaken op je lokale computer.

[Zorian]

afterburn schreef op dinsdag 28 februari 2017 @ 13:35:
Dan moet je dus zoals ik zei een lokale DNS draaien die nas.domein.nl resolved naar een lokaal adres, of even een hostfile entry aanmaken op je lokale computer.

Ik heb een Edgerouter Lite die de DNS afhandelt, dus mag aannemen dat het wel ergens is in te stellen... Zal eens rondgluren daar.

//Kan het dus niet vinden. Laat maar zitten. Ik gooi QC wel uit en gebruik wel gewoon https://nas.domein.nl:5001 voortaan.

[ Voor 13% gewijzigd door Zorian op 28-02-2017 13:46 ]

[mithras]

Zorian schreef op dinsdag 28 februari 2017 @ 13:39:
[...]

Ik heb een Edgerouter Lite die de DNS afhandelt, dus mag aannemen dat het wel ergens is in te stellen... Zal eens rondgluren daar.

//Kan het dus niet vinden. Laat maar zitten. Ik gooi QC wel uit en gebruik wel gewoon https://nas.domein.nl:5001 voortaan.

Als het goed is zou die ERL wel domain-name options kennen in dhcp. Je NAS zou met mDNS moeten werken en dus de hostname via avahi/bonjour kenbaar moeten maken. Je kan intern dan ook nas.mijndomein.nl gebruiken.

[robin1979]

Cyrus The Virus schreef op dinsdag 28 februari 2017 @ 06:41:
[...]


Als ik via windows netwerk doe bijvoorbeeld \\DS412 (de netwerknaam van mijn nas) dan krijgt hij hem niet gevonden. Dit heb ik op 3 verschillende PC's meegemaakt. afgelopen zaterdag voor het eerst opgemerkt.

Gebruik \\ds412.local\

[Cyrus The Virus]

robin1979 schreef op dinsdag 28 februari 2017 @ 21:16:
[...]


Gebruik \\ds412.local\

`
dat werkt ook niet, ik ben eens gaan kijken in mijn asus router met merlin en zag het volgende in de log:

code:

Feb 28 21:32:29 dnsmasq-dhcp[245]: DHCPSOLICIT(br0) xx:xx:xx:3b:bd

elke seconde komt dit voorbij dat laatste stuk is het mac adres van mijn synology google levert niet echt een oplossing alleen iets met ipv6 die heb ik nu uitgezet.

[elsinga]

Vraagje: ik gebruik nu Cloud Sync om een off-site backup te hebben van belangrijke data op mijn DS412+ bij Stack. Gewoon omdat het kan.

Daarnaast heb ik een DS415play met minder diskruimte en daar sync ik met gedeelde map synchronisatie ook een deel van de bestanden naartoe. Alleen synct dat op een dusdanige manier dat ik op de 415play niets kan verwijderen, ook met full admin rights heb ik volgens Filestation niet de juiste permissies. Daarnaast is het nog steeds een sync en dus zonder bescherming tegen verwijderen en beschadiging van bestanden.

Ik wil eigenlijk een nette backup van bepaalde bestanden op de 415play, maar niet met Hyperbackup omdat ik daarmee de bestanden op de 415play niet op dezelfde plek terugvind als op de 412+. En ik wil de 415play ook gebruiken om vanaf te streamen, is de 412+ vrij voor downloads en zo.

Het mooiste zou het zijn als ik de volgende zaken kan combineren:
- een encrypted off-site backup van alle data (nu 5.5TB) op de DS412+, tegen lage kosten
- een (op het netwerk lokale) sync van foto's, video's en muziek van de DS412+ naar de 415play, zodat ik daar vanaf alles kan streamen

Stack kan ik alleen als WebDAV benaderen en is geen echte backup. Is er een manier om mijn Stack accounts (ja, meerdere) te kunnen gebruiken als echte backup, liefst met versioning? Of moet ik dan naar een andere (en dus betaalde) aanbieder?

Is er een package die een nette sync kan uitvoeren van 412+ naar 415play, waarbij de rechten niet enorm verkloot worden en ik gewoon aan beide kanten filebeheer kan doen?

[Quakie]

Marcel_EA schreef op vrijdag 24 februari 2017 @ 13:44:
[...]


Pfff daar word je niet blij van!
Hoop voor je dat het snel geregeld is.

Vrijdag verstuurd, maandag aangekomen, vandaag wordt een nieuwe unit verzonden (komt uit de uk)

Super blij en bizar dat het binnen 3 dagen geregeld kan worden. Voor mij ook reden om ook niet te druk bezig te zijn met de CPU bug.. Ik had min of meer al medegedeeld kregen dat unit vervangen zou worden en dat was begin Feb voordat cpu bug naar buiten kwam. Dit is buiten de 2 jaar garantie. Ik heb zelf er voor gekozen om verder te gaan met synology support omdat ik het leuk vind qua troubleshooten en omdat ik zuinig ben op mijn spullen dus liever mijn oude unit had gehouden. Er kan nl niet gezegd worden of het een refurb of nieuwe unit is. Dit alles is trouwens via mobile-harddisk.nl gegaan. Ik bestel daar dit soort dingen omdat ik het een fijne zaak vind met snelle reacties en in mijn ogen goede service.

[ Voor 41% gewijzigd door Quakie op 01-03-2017 11:56 . Reden: extra info ]

[WRT54G]

Quakie schreef op woensdag 1 maart 2017 @ 11:46:
[...]


Vrijdag verstuurd, maandag aangekomen, vandaag wordt een nieuwe unit verzonden (komt uit de uk)

Super blij en bizar dat het binnen 3 dagen geregeld kan worden. Voor mij ook reden om ook niet te druk bezig te zijn met de CPU bug.. Ik had min of meer al medegedeeld kregen dat unit vervangen zou worden en dat was begin Feb voordat cpu bug naar buiten kwam. Dit is buiten de 2 jaar garantie. Ik heb zelf er voor gekozen om verder te gaan met synology support omdat ik het leuk vind qua troubleshooten en omdat ik zuinig ben op mijn spullen dus liever mijn oude unit had gehouden. Er kan nl niet gezegd worden of het een refurb of nieuwe unit is. Dit alles is trouwens via mobile-harddisk.nl gegaan. Ik bestel daar dit soort dingen omdat ik het een fijne zaak vind met snelle reacties en in mijn ogen goede service.

Thanks voor de heads up!
Ik heb inmiddels ook een reply op mijn ticket:
"Dear user,
I can't connect to your NAS,Is it open?"

Uhhh dat kan kloppen aangezien ik de schijven van hen eruit moest halen en via een PC met WD Data Lifeguard moest testen...

De 4x 4TB WD Reds zijn inmiddels allen getest met (extended test van) WD Data Lifeguard en waren allemaal 100% ok. Helaas toen ik de eerste schijf uit de DS415+ trok (hot swap) liep de boel weer vast.
Nu ik de schijven getest heb en weer terug gestopt heb werd de eerste schijf niet meer herkend en moet de raid 5 array gerebuild worden.
Wel Synology Support gemaild dat de Syno weer bereikbaar is.
Ben benieuwd hoe dit afloopt...

[Quakie]

Marcel_EA schreef op woensdag 1 maart 2017 @ 12:09:
[...]


Thanks voor de heads up!
Ik heb inmiddels ook een reply op mijn ticket:
"Dear user,
I can't connect to your NAS,Is it open?"

Uhhh dat kan kloppen aangezien ik de schijven van hen eruit moest halen en via een PC met WD Data Lifeguard moest testen...

De 4x 4TB WD Reds zijn inmiddels allen getest met (extended test van) WD Data Lifeguard en waren allemaal 100% ok. Helaas toen ik de eerste schijf uit de DS415+ trok (hot swap) liep de boel weer vast.
Nu ik de schijven getest heb en weer terug gestopt heb werd de eerste schijf niet meer herkend en moet de raid 5 array gerebuild worden.
Wel Synology Support gemaild dat de Syno weer bereikbaar is.
Ben benieuwd hoe dit afloopt...

Slimme actie.. ook paar keer gehad.. doe je precies wat ze zeggen....maar ondertussen haha

Nou mooi dat je ze extern kon testen.. ik kon het alleen via dsm doen. Geen pcs in huis.

Nou hopelijk heb je lange adem, want mijn ervaring is dat je niet teveel tekst moet neerzetten. 1 probleem en zo kort en bondig mogelijk antwoorden.

[WRT54G]

Ja, ik laat me benieuwen.
Zal hier mijn updates wel plaatsen.
Voorlopig is de raid 5 array voor 34% gerebuild. Hopelijk loopt de boel nu niet vast.

[vandermark]

Ik maak al ruim een jaar gebruik van een let's encrypt certificaat maar sinds kort werkt de auto-renewal niet meer....

Port 80 staat open en buiten reguliere dsm updates is er niks veranderd. Ik kom er niet uit wat ik moet doen om het te verhelpen, hebben jullie tips/ideeën?

[WRT54G]

vandermark schreef op woensdag 1 maart 2017 @ 13:38:
Ik maak al ruim een jaar gebruik van een let's encrypt certificaat maar sinds kort werkt de auto-renewal niet meer....

Port 80 staat open en buiten reguliere dsm updates is er niks veranderd. Ik kom er niet uit wat ik moet doen om het te verhelpen, hebben jullie tips/ideeën?

Ik ben hier ook tegen aangelopen. Bij mij was het een probleem doordat ik met web station een aantal vhosts had staan die botste konden de certificaten niet vernieuwd worden.

Ik heb toen een klein script "geschreven" welke voor mij prima werkt!
Deze laat ik in DSM taak beheer 1x in de week 's nachts draaien.

letsencrypt-renew.sh

code:

#!/bin/bash

# Rename virtualhost file
mv /var/packages/WebStation/etc/VirtualHost.json /var/packages/WebStation/etc/VirtualHost.json.tmp

# Restart nginx after vhost rename
synoservicecfg --restart nginx

# Manual Let's Encrypt renewal
/usr/syno/sbin/syno-letsencrypt renew-all

# Rename virtualhost file back to normal
mv /var/packages/WebStation/etc/VirtualHost.json.tmp /var/packages/WebStation/etc/VirtualHost.json

# Restart nginx service again after vhost rename
synoservicecfg --restart nginx

[vandermark]

Marcel_EA schreef op woensdag 1 maart 2017 @ 13:45:
[...]


Ik ben hier ook tegen aangelopen. Bij mij was het een probleem doordat ik met web station een aantal vhosts had staan die botste konden de certificaten niet vernieuwd worden.

Ik heb toen een klein script "geschreven" welke voor mij prima werkt!
Deze laat ik in DSM taak beheer 1x in de week 's nachts draaien.

letsencrypt-renew.sh

code:

#!/bin/bash

# Rename virtualhost file
mv /var/packages/WebStation/etc/VirtualHost.json /var/packages/WebStation/etc/VirtualHost.json.tmp

# Restart nginx after vhost rename
synoservicecfg --restart nginx

# Manual Let's Encrypt renewal
/usr/syno/sbin/syno-letsencrypt renew-all

# Rename virtualhost file back to normal
mv /var/packages/WebStation/etc/VirtualHost.json.tmp /var/packages/WebStation/etc/VirtualHost.json

# Restart nginx service again after vhost rename
synoservicecfg --restart nginx

Tx, ik krijg dan helaas deze foutmelding per email:

code:

Dear user,

Task Scheduler has completed a scheduled task.

Task: renew encryptcertificaat
Start time: Wed, 01 Mar 2017 14:06:06 GMT
Stop time: Wed, 01 Mar 2017 14:07:00 GMT
Current status: 0
Standard output/error:
mv: cannot stat '/var/packages/WebStation/etc/VirtualHost.json': No such file or directory
mv: cannot stat '/var/packages/WebStation/etc/VirtualHost.json.tmp': No such file or directory


Sincerely,
Synology DiskStation

[WRT54G]

Dan denk ik dat jij een ander probleem hebt dan dat ik had.
Als ik de error bekijk dan ziet het er naar uit dat jij Web Station niet gebruikt, klopt dat?

[vandermark]

Marcel_EA schreef op woensdag 1 maart 2017 @ 14:25:
Dan denk ik dat jij een ander probleem hebt dan dat ik had.
Als ik de error bekijk dan ziet het er naar uit dat jij Web Station niet gebruikt, klopt dat?

Nee, klopt maar het staat wel aan.

[mithras]

vandermark schreef op woensdag 1 maart 2017 @ 13:38:
Ik maak al ruim een jaar gebruik van een let's encrypt certificaat maar sinds kort werkt de auto-renewal niet meer....

Port 80 staat open en buiten reguliere dsm updates is er niks veranderd. Ik kom er niet uit wat ik moet doen om het te verhelpen, hebben jullie tips/ideeën?

Ik heb standaard poort 80 niet openstaan. Zodra cert verloopt voer ik enkel dit uit (staat hieboven ook):

/usr/syno/sbin/syno-letsencrypt renew-all

Dat moet voldoende zijn.

[WRT54G]

vandermark schreef op woensdag 1 maart 2017 @ 14:30:
[...]


Nee, klopt maar het staat wel aan.

Als hij aanstaat maar je hebt geen vhost geconfigureerd dan is er idd geen VirtualHost.json file aanwezig.
Probeer het eens met alleen het volgende commando:

code:

/usr/syno/sbin/syno-letsencrypt renew-all

Deze doet een handmatige update van LE.

[vandermark]

mithras schreef op woensdag 1 maart 2017 @ 14:30:
[...]
Ik heb standaard poort 80 niet openstaan. Zodra cert verloopt voer ik enkel dit uit (staat hieboven ook):

/usr/syno/sbin/syno-letsencrypt renew-all

Dat moet voldoende zijn.

Ok, ik heb dus een taak gemaakt met enkel die regel. Nu kreeg ik deze email:

code:

Dear user,

Task Scheduler has completed a scheduled task.

Task: renew encryptcertificaat
Start time: Wed, 01 Mar 2017 14:31:43 GMT
Stop time: Wed, 01 Mar 2017 14:32:35 GMT
Current status: 0
Standard output/error:


Sincerely,
Synology DiskStation

Dus het zou gelukt moeten zijn? Onder certificaten is nog niks vernieuwd...

[WRT54G]

vandermark schreef op woensdag 1 maart 2017 @ 14:33:
[...]


Ok, ik heb dus een taak gemaakt met enkel die regel. Nu kreeg ik deze email:

code:

Dear user,

Task Scheduler has completed a scheduled task.

Task: renew encryptcertificaat
Start time: Wed, 01 Mar 2017 14:31:43 GMT
Stop time: Wed, 01 Mar 2017 14:32:35 GMT
Current status: 0
Standard output/error:


Sincerely,
Synology DiskStation

Dus het zou gelukt moeten zijn? Onder certificaten is nog niks vernieuwd...

Log even in via SSH (admin account met root rechten) en voer die regel uit.
Check dan even of het gelukt is.

Check dan ook gelijk even:
/var/log/messages

Hier zouden eventuele meldingen in staan (success of failure).

[vandermark]

Marcel_EA schreef op woensdag 1 maart 2017 @ 14:40:
[...]


Log even in via SSH (admin account met root rechten) en voer die regel uit.
Check dan even of het gelukt is.

Check dan ook gelijk even:
/var/log/messages

Hier zouden eventuele meldingen in staan (success of failure).

In messages staat deze foutmelding een paar keer vandaag:

code:

2017-03-01T14:32:35+01:00 DS214PLAY syno-letsencrypt: syno-letsencrypt.cpp:288 Failed to renew /usr/syno/etc/certificate/_archive/yhqH11/. { "error": 200, "msg": "new-cert: Unexpect httpcode. (new-cert)", "file": "client.cpp:575"}

[WRT54G]

Hmmm daar kan ik je helaas niet verder mee helpen...
Wellicht iemand anders hier? Of even een thread openen op het LE forum zelf?

[vandermark]

Via putty de opdracht ook gedaan, krijg deze foutmelding:

code:

DEBUG: Curl Reply: [403][HTTP/1.1 100 Continue
Expires: Wed, 01 Mar 2017 13:59:07 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 403 Forbidden
Server: nginx
Content-Type: application/problem+json
Content-Length: 233
Boulder-Request-Id: _8U1AEtR849dCoXTz4Nk83f6JczRNReFVE14rMcjXzY
Boulder-Requester: 976486
Replay-Nonce: JO0qVjLdayMVMsiHxSV76_yNIFpvKIg9JkEqmL1p5iU
Expires: Wed, 01 Mar 2017 13:59:07 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 01 Mar 2017 13:59:07 GMT
Connection: close

{
  "type": "urn:acme:error:unauthorized",
  "detail": "Error creating new cert :: Authorizations for these names not found or expired: sab.bartserver.nl, sonarr.bartserver.nl, sub.bartserver.nl, www.bartserver.nl",
  "status": 403
}]
DEBUG: Failed to renew /usr/syno/etc/certificate/_archive/yhqH11/. { "error": 200, "msg": "new-cert: Unexpect httpcode. (new-cert)", "file": "client.cpp:575"}

[WRT54G]

code:

nslookup sub.bartserver.nl
** server can't find sub.bartserver.nl: NXDOMAIN

Loopt ie hier niet stuk op?
sub.bartserver.nl verwijst nergens naar.

[mithras]

vandermark schreef op woensdag 1 maart 2017 @ 14:33:
[...]


Ok, ik heb dus een taak gemaakt met enkel die regel. Nu kreeg ik deze email:

code:

Dear user,

Task Scheduler has completed a scheduled task.

Task: renew encryptcertificaat
Start time: Wed, 01 Mar 2017 14:31:43 GMT
Stop time: Wed, 01 Mar 2017 14:32:35 GMT
Current status: 0
Standard output/error:


Sincerely,
Synology DiskStation

Dus het zou gelukt moeten zijn? Onder certificaten is nog niks vernieuwd...

Je cert van https://sonarr.bartserver.nl/login?returnUrl=/ is nog tm 11 maart in ieder geval

Log inderdaad in met ssh en probeer het dan, zonder taken. Dat is vele malen makkelijker. Zoals boven me staat is het waarschijnlijk een dns entry die niet te valideren valt (sub.).

[vandermark]

Marcel_EA schreef op woensdag 1 maart 2017 @ 15:10:

code:

nslookup sub.bartserver.nl
** server can't find sub.bartserver.nl: NXDOMAIN

Loopt ie hier niet stuk op?
sub.bartserver.nl verwijst nergens naar.

Dat is zo! Omdat ik sub.* niet meer gebruik heb ik die dns record verwijderd. Maar in het certficaat staat die nog wel...

Heb sub weer als dns toegevoegd, even 30 minuten wachten en kijken of het dan wel werkt, tx!

[WRT54G]

Graag gedaan! Dit zou het moeten oplossen.
Laat maar weten!

[vandermark]

Marcel_EA schreef op woensdag 1 maart 2017 @ 16:24:
Graag gedaan! Dit zou het moeten oplossen.
Laat maar weten!

Hmmm ik zie nu ook weer andere rare foutmelding in Putty na renew commando, let vooral op 2e regel:

code:

DEBUG: DNS challenge failed, reason: { "error": 108, "msg": "Not synology DDNS.", "file": "challenge.cpp:79"}
DEBUG: Normal challenge failed, reason: { "error": 107, "msg": "www.bartserver.nl: Could not connect to www.bartserver.nl", "file": "client.cpp:315"}

Hoe kan dit? www.bartserver.nl is wel toegankelijk, dns klopt en url leidt naar webstation??

[WRT54G]

Hmmm hier heb ik eerlijk gezegd geen verklaring voor...

[vandermark]

Nou, raar hoor maar het is gelukt: ik heb enkel de firewall uitgezet en daarna ging het wel...

code:

DEBUG: generate csr & private key
DEBUG: get new-cert
DEBUG: Post JWS Request: https://acme-v01.api.letsencrypt.org/acme/new-cert
DEBUG: Post Request: https://acme-v01.api.letsencrypt.org/acme/new-cert
DEBUG: get issuer-cert
DEBUG: GET Request: https://acme-v01.api.letsencrypt.org/acme/issuer-cert
DEBUG: save to files
DEBUG: renew success. [/usr/syno/etc/certificate/_archive/yhqH11/].

Bedankt voor al jullie tips!

[WRT54G]

Top!
Ik neem aan dat je de FW van de Synology zelf bedoeld toch?

Fijn dat het iig opgelost is en natuurlijk geen dank.

[vandermark]

Marcel_EA schreef op woensdag 1 maart 2017 @ 16:51:
Top!
Ik neem aan dat je de FW van de Synology zelf bedoeld toch?

Fijn dat het iig opgelost is en natuurlijk geen dank.

Klopt, betreft FW van synology zelf.
Wil die eigenlijk wel standaard aan hebben, zal hier even naar kijken hoe hier mee om te gaan?

[WRT54G]

Zelf heb ik hem uit staan en eigenlijk ook weinig ervaring mee (Syno FW).
Heb voor mijn Synology namelijk een (pfSense) firewall staan dus nooit nodig gehad.
Maar technisch gezien,als port 80 open staat op de (Syno) firewall en port forwarding vanaf je router/modem werkt zou het geen probleem mogen zijn, lijkt me.

[WRT54G]

Nu breekt mijn klomp!

Eerst moet ik 4 schijven testen, extern aan een computer gekoppeld. Kon niet vanuit DSM.
Moest perse met WD Data Lifeguard. Geen probleem, 10 uur per schijf bezig.
Vervolgens krijg een mail, ik kan je Synology niet bereikendus we kunnen niks op het moment.
Nee duh, de schijven zijn eruit omdat ik ze moet testen!

Nu dagen later aangegeven dat de Syno weer online is en dat de schijven 100% ok zijn.
Krijg ik dit als antwoord:

Dear user

Please contact your dealer and repair it

thanks

BEN


Wat onbeschofte boer is dat zeg. Bah!

[ Voor 52% gewijzigd door WRT54G op 02-03-2017 09:01 ]

[Quakie]

Bizar..

Een zin... 7 woorden en dan nog niet duidelijk zijn...

[WRT54G]

Quakie schreef op donderdag 2 maart 2017 @ 09:12:
Bizar..

Een zin... 7 woorden en dan nog niet duidelijk zijn...

Ja echt ongelooflijk.
Heb gevraagd wat voor raar antwoord dit is voor een bedrijf als Synology.

Krijg ik het volgende weer terug:

Dear user

1.I cannot contact to your nas

2.There is something error about your flash

so please contact your dealer and repair it


thanks

ben

Ik krijg een beetje het idee dat Ben nieuw is in de wereld die "customer support" heet.
Zometeen Synology UK nog maar eens bellen en kijken of ik daar verder mee kom. Heb weinig hoop.

[EricEric752]

Marcel_EA schreef op woensdag 1 maart 2017 @ 16:56:
Zelf heb ik hem uit staan en eigenlijk ook weinig ervaring mee (Syno FW).
Heb voor mijn Synology namelijk een (pfSense) firewall staan dus nooit nodig gehad.
Maar technisch gezien,als port 80 open staat op de (Syno) firewall en port forwarding vanaf je router/modem werkt zou het geen probleem mogen zijn, lijkt me.

Ik gebruik ook Let's encrypt en heb port 80 dicht staan. Bij de installatie van het Let's Encrypt certificaat heb ik port 80 tijdelijk even open gezet en vervolgens bedacht dat ik bij het renewen van het certificaat port 80 tijdelijk weer even open zou moeten zetten. Op termijn wilde ik dat automatiseren, maar daar was ik nog niet aan toe gekomen. Om te voorkomen dat ik het certificaat zou vergeten heb ik een herinnering in mijn agenda gezet.

De eerste keer dat ik mijn certificaat zou moeten vernieuwen, bleek dat echter toch al automatisch gedaan, terwijl port 80 dicht stond. Daarna is het certificaat al verschillende keren automatisch vernieuwd. Ik begrijp hier niets van, want ik lees overal dat port 80 open moet staan en dat lijkt me ook logisch omdat Let's Encrypt immers moet kunnen controleren of ik wel eigenaar ben van mijn domein.

Ik weet zeker dat port 80 dicht staat. Mijn Synology staat achter 2 routers. De eerste (Ziggo) router geeft alle porten boven de 1024 door aan de twee router. Alles onder port 1024 wordt dus al geblokt door de eerste router. Mijn hele LAN hangt achter de tweede (Synology) router. Mijn DS414 dus ook, maar er is geen FW regel die port 80 door geeft aan de DS414 (dat zou ook zinloos zijn, gezien de eerste router). Ook port 443 staat trouwens dicht, want mijn Synology is via https op een hoge non-default port bereikbaar. Voor de zekerheid heb ik ook getest vanaf het het internet. Op mijn domain is zoals te verwachten was, niets te zien op port 80 of 443.

Toch wordt het certificaat steeds netjes vernieuwd. Een groot mysterie voor mij. Wel handig, maar ik zou graag snappen waarop het werkt. Wie het weet mag het zeggen...

[Quakie]

Marcel_EA schreef op donderdag 2 maart 2017 @ 09:16:
[...]


Ja echt ongelooflijk.
Heb gevraagd wat voor raar antwoord dit is voor een bedrijf als Synology.

Krijg ik het volgende weer terug:

Dear user

1.I cannot contact to your nas

2.There is something error about your flash

so please contact your dealer and repair it


thanks

ben

Ik krijg een beetje het idee dat Ben nieuw is in de wereld die "customer support" heet.
Zometeen Synology UK nog maar eens bellen en kijken of ik daar verder mee kom. Heb weinig hoop.

Ja, zeer onprofessioneel en mag wel wat uitgebreider. Grote kans dat er inderdaad een error op het flash systeem is waardoor hij niet kan connecten wat er ook gebeurd. Dit is ook de reden dat je standaard niet terug kan in DSM versie. Ergens staat hier genoteerd welke versie je het laatste hebt geïnstalleerd. Zolang je flash nog werkt komt synology er nog in, terwijl de user zelf er niet bij kan. Kortom support kan je niet echt verder helpen, maar dat kan wel wat netter en duidelijker verwordt worden.

[ Voor 0% gewijzigd door Quakie op 02-03-2017 09:39 . Reden: kleine aanpassing met grote gevolgen..:) ]

[wortelsoft]

Weet er iemand of port 5432 postgresql nodig is om te kunnen werken met de WEB interface van de Synology? O fzou ik die mogen sluiten?

[WRT54G]

Quakie schreef op donderdag 2 maart 2017 @ 09:30:
[...]


Ja, zeer onprofessioneel en mag wel wat uitgebreider. Grote kans dat er inderdaad een error op het flash systeem is waardoor hij niet kan connecten wat er ook gebeurd. Dit is ook de reden dat je standaard terug kan in DSM versie. Ergens staat hier genoteerd welke versie je het laatste hebt geinstalleerd. Zolang je flash nog werkt komt synology er nog in, terwijl de user zelf er niet bij kan. Kortom support kan je niet echt verder helpen, maar dat kan wel wat netter en duidelijker verwordt worden.

Precies dat!

[Quakie]

EricEric752 schreef op donderdag 2 maart 2017 @ 09:19:
[...]

Ik gebruik ook Let's encrypt en heb port 80 dicht staan. Bij de installatie van het Let's Encrypt certificaat heb ik port 80 tijdelijk even open gezet en vervolgens bedacht dat ik bij het renewen van het certificaat port 80 tijdelijk weer even open zou moeten zetten. Op termijn wilde ik dat automatiseren, maar daar was ik nog niet aan toe gekomen. Om te voorkomen dat ik het certificaat zou vergeten heb ik een herinnering in mijn agenda gezet.

De eerste keer dat ik mijn certificaat zou moeten vernieuwen, bleek dat echter toch al automatisch gedaan, terwijl port 80 dicht stond. Daarna is het certificaat al verschillende keren automatisch vernieuwd. Ik begrijp hier niets van, want ik lees overal dat port 80 open moet staan en dat lijkt me ook logisch omdat Let's Encrypt immers moet kunnen controleren of ik wel eigenaar ben van mijn domein.

Ik weet zeker dat port 80 dicht staat. Mijn Synology staat achter 2 routers. De eerste (Ziggo) router geeft alle porten boven de 1024 door aan de twee router. Alles onder port 1024 wordt dus al geblokt door de eerste router. Mijn hele LAN hangt achter de tweede (Synology) router. Mijn DS414 dus ook, maar er is geen FW regel die port 80 door geeft aan de DS414 (dat zou ook zinloos zijn, gezien de eerste router). Ook port 443 staat trouwens dicht, want mijn Synology is via https op een hoge non-default port bereikbaar. Voor de zekerheid heb ik ook getest vanaf het het internet. Op mijn domain is zoals te verwachten was, niets te zien op port 80 of 443.

Toch wordt het certificaat steeds netjes vernieuwd. Een groot mysterie voor mij. Wel handig, maar ik zou graag snappen waarop het werkt. Wie het weet mag het zeggen...

En wel eens een poort scan gedaan? om zeker te zijn dat port 80 dicht staat? Ik begrijp je 2 router config niet, maar dat is een andere topic.

[SmiGueL]

EricEric752 schreef op donderdag 2 maart 2017 @ 09:19:
De eerste keer dat ik mijn certificaat zou moeten vernieuwen, bleek dat echter toch al automatisch gedaan, terwijl port 80 dicht stond. Daarna is het certificaat al verschillende keren automatisch vernieuwd. Ik begrijp hier niets van, want ik lees overal dat port 80 open moet staan en dat lijkt me ook logisch omdat Let's Encrypt immers moet kunnen controleren of ik wel eigenaar ben van mijn domein.

Toch wordt het certificaat steeds netjes vernieuwd. Een groot mysterie voor mij. Wel handig, maar ik zou graag snappen waarop het werkt. Wie het weet mag het zeggen...

Dat van dat poort 80 open moet heb ik in het begin ook eens gelezen, maar is inmiddels echt dikke onzin.
(Waarschijnljik was het alleen de 1e paar weken/maanden nodig totdat het anders is opgelost, maar ik heb hem 5 minuten na het aanvragen weer dichtgegooid in m'n router)

Poort 80 hoeft dus niet open te staan. (alleen de 1e keer bij het aanvragen misschien, maar dat is voor mij al 1+ jaar geleden)
Heb hem op mijn DS916+ nog NOOIT open gehad, en het certificaat wordt al verlengd sinds juni.
Bij de eigenschappen van het certificaat staat achter de "For:" *2468, dus je domein en je poort zijn bekend.. lijkt me dat ze het op die manier wel kunnen controleren. (oude post hierover)
Of gewoon alleen een verlengrequest vanaf de NAS naar de LE server, dan hoeft er volens mij niet eens een poort open te staan?

[ Voor 9% gewijzigd door SmiGueL op 02-03-2017 10:26 ]

[pven]

Marcel_EA schreef op donderdag 2 maart 2017 @ 09:16:
[...]

Heb gevraagd wat voor raar antwoord dit is voor een bedrijf als Synology.

Schiet een nieuw ticket in?

Mijn ervaringen zijn juist prima met een Indiase naam.

[SpoekGTi]

Hier iemand ervaring met het OpenVPN pakketje van Synology, heb gisteren iets vaags bij iemand aan de hand.

OpenVPN server draait op een Synology DS412+ werkt prima.
DNS is ook de Synology.

Client:

Windows 10 bak met de OpenVPN software de laatste versie. Inloggen gaat prima, krijg een IP maar daarna is er geen internet verkeer mogelijk als het IPV4 verkeer is.....vaag jazeker.

En hoezo conludeer ik dat IPV6 verkeer wel werkt, hij heeft een ziggo verbinding met zowel ipv4 als ipv6 en ik kan wel op websites komen die ipv6 ondersteunen.

IPV6 op de laptop al uitgezet, maar dan heb ik helemaal niets via de VPN

Heb in de firewall van de syno ook al aangegeven dat de ip reeks van de VPN gewoon netjes de DNS mag gebruiken, wat in theorie niet zou hoeven omdat als ik met mijn 4G connectie een VPN opzet naar mijn NAS alles gewoon werkt zoals het hoort.

Iets zegt me dat het Ziggo modem 'iets' doet met de verbinding, maar weet niet wat, en gisteren na 2 uur zoeken was ik er om 23:15 wel een beetje klaar mee

[WRT54G]

pven schreef op donderdag 2 maart 2017 @ 10:15:
[...]

Schiet een nieuw ticket in?

Mijn ervaringen zijn juist prima met een Indiase naam.

Ik heb een ticket open staan.
De reply die ik kreeg was op mijn ticket.

Na het bellen van Synology support UK kwam eruit dat Ben een collega uit Taiwan is en wellicht de Engelse taal niet helemaal onder de knie heeft en daarom wellicht wat kort in zijn antwoorden is.

Lang verhaal kort ik kon hem opsturen naar de UK voor een replacement of ik kon mijn dealer vragen.
De laatste was een snellere oplossing maar het was ook geen probleem om hem naar de UK te sturen.
WifiMedia gebeld (waar ik hem gekocht heb) en zij gaan hem omruilen voor me.

Praktische vraag:
Schijven haal ik eruit, maak een config backup.
Als ik de nieuwe heb dan is het toch schijven terug erin en dan config restore en alles zou weer moeten werken?

[EricEric752]

SmiGueL schreef op donderdag 2 maart 2017 @ 10:05:
[...]


Dat van dat poort 80 open moet heb ik in het begin ook eens gelezen, maar is inmiddels echt dikke onzin.
(Waarschijnljik was het alleen de 1e paar weken/maanden nodig totdat het anders is opgelost, maar ik heb hem 5 minuten na het aanvragen weer dichtgegooid in m'n router)

Poort 80 hoeft dus niet open te staan. (alleen de 1e keer bij het aanvragen misschien, maar dat is voor mij al 1+ jaar geleden)
Heb hem op mijn DS916+ nog NOOIT open gehad, en het certificaat wordt al verlengd sinds juni.
Bij de eigenschappen van het certificaat staat achter de "For:" *2468, dus je domein en je poort zijn bekend.. lijkt me dat ze het op die manier wel kunnen controleren.
Of gewoon alleen een verlengrequest vanaf de NAS naar de LE server, dan hoeft er volens mij niet eens een poort open te staan?

Dank je. Ik vermoedde al dat het niet meer nodig zou zijn, maar ik lees overal nog steeds die port 80 eis. Goed te horen dat ik niet de enige ben bij het gewoon werkt.

Ik snap alleen nog niet precies hoe het werkt. Misschien controleren ze wel of het renewal verzoek afkomstig is van hetzelfde IP adres als waarnaar het domein verwijst. Die informatie heeft Let's Encrypt allebei.

In het certificaat zie ik niet voor welke port het is (wel het domein natuurlijk). Voor zover ik weet zit die informatie ook niet in een certificaat. Bedoelde jij dat de port er wel in zit? Waar moet ik dan precies kijken, want ik kan het niet vinden.

[SmiGueL]

EricEric752 schreef op donderdag 2 maart 2017 @ 10:34:

Ik snap alleen nog niet precies hoe het werkt. Misschien controleren ze wel of het renewal verzoek afkomstig is van hetzelfde IP adres als waarnaar het domein verwijst. Die informatie heeft Let's Encrypt allebei.

Ja zie ook mijn edit (link toegevoegd), er zit een verschil in de info van de oude en nieuwe certificaten (poortnummer staat er ineens bij)
Dus dat klinkt aannemelijk.

[ Voor 10% gewijzigd door SmiGueL op 02-03-2017 10:48 ]

[vandermark]

Super, dan ga ik mijn poort 80 ook dichtzetten en kijken hoe het gaat.

Ik zit nog wel met de vraag hoe ik alle http requests kan omzetten naar https. Via de optie in DSM gaat het niet namelijk...

http://www.mijndomein.nl dus direct naar https://www.mijndomein.nl

Edit: dat is dus ook vrij makkelijk: hsts aanzetten bij elke reverse proxy

[ Voor 12% gewijzigd door vandermark op 02-03-2017 11:20 ]

[pven]

Marcel_EA schreef op donderdag 2 maart 2017 @ 10:30:
[...]

Lang verhaal kort ik kon hem opsturen naar de UK voor een replacement of ik kon mijn dealer vragen.
De laatste was een snellere oplossing maar het was ook geen probleem om hem naar de UK te sturen.
WifiMedia gebeld (waar ik hem gekocht heb) en zij gaan hem omruilen voor me.

Ah, ok

Praktische vraag:
Schijven haal ik eruit, maak een config backup.
Als ik de nieuwe heb dan is het toch schijven terug erin en dan config restore en alles zou weer moeten werken?

Volgens mij is het schijven er terug in, en het werkt meteen weer zonder restore. Maar dit is vast beter op de Synology-site te vinden.

[EricEric752]

SpoekGTi schreef op donderdag 2 maart 2017 @ 10:22:
Hier iemand ervaring met het OpenVPN pakketje van Synology, heb gisteren iets vaags bij iemand aan de hand.

OpenVPN server draait op een Synology DS412+ werkt prima.
DNS is ook de Synology.

Client:

Windows 10 bak met de OpenVPN software de laatste versie. Inloggen gaat prima, krijg een IP maar daarna is er geen internet verkeer mogelijk als het IPV4 verkeer is.....vaag jazeker.

En hoezo conludeer ik dat IPV6 verkeer wel werkt, hij heeft een ziggo verbinding met zowel ipv4 als ipv6 en ik kan wel op websites komen die ipv6 ondersteunen.

IPV6 op de laptop al uitgezet, maar dan heb ik helemaal niets via de VPN

Heb in de firewall van de syno ook al aangegeven dat de ip reeks van de VPN gewoon netjes de DNS mag gebruiken, wat in theorie niet zou hoeven omdat als ik met mijn 4G connectie een VPN opzet naar mijn NAS alles gewoon werkt zoals het hoort.

Iets zegt me dat het Ziggo modem 'iets' doet met de verbinding, maar weet niet wat, en gisteren na 2 uur zoeken was ik er om 23:15 wel een beetje klaar mee

OpenVPN werkt prima op mijn Synology router. Veel gebruik ik het echter niet, want ik geef de voorkeur aan PiVPN op een raspberry pi, maar het werkt wel. OpenVPN op mijn Synology NAS heb ik nooit gebruikt, maar dat zal waarschijnlijk wel hetzelfde werken.

Ik denk dat je probleem zit in je FW van je Synology. Volgens mij moet je aangeven dat je OpenVPN IP range (10.8.0.0/24) toegang heeft tot alle IPs op alle poorten. Je hebt deze regel ook anders om nodig. Blijkbaar heb je dat al gedeeltelijk gedaan door je OpenVPN netwerk toegang te geven tot je DNS. Die stap zal dan waarschijnlijk ook wel werken. Als een OpenVPN client daarna echter ergens heen wil (bv Google.com op een device op je LAN) stuit die client op je FW en kan niet verder. Vandaar dat je die extra regels nodig hebt.

Je kan de regels natuurlijk inperken door niet alle IP/port combinaties toe te staan, als je vanuit je OpenVPN niet overal naar toe toe hoeft te kunnen.

[SpoekGTi]

EricEric752 schreef op donderdag 2 maart 2017 @ 10:44:
[...]

OpenVPN werkt prima op mijn Synology router. Veel gebruik ik het echter niet, want ik geef de voorkeur aan PiVPN op een raspberry pi, maar het werkt wel. OpenVPN op mijn Synology NAS heb ik nooit gebruikt, maar dat zal waarschijnlijk wel hetzelfde werken.

Ik denk dat je probleem zit in je FW van je Synology. Volgens mij moet je aangeven dat je OpenVPN IP range (10.8.0.0/24) toegang heeft tot alle IPs op alle poorten. Je hebt deze regel ook anders om nodig. Blijkbaar heb je dat al gedeeltelijk gedaan door je OpenVPN netwerk toegang te geven tot je DNS. Die stap zal dan waarschijnlijk ook wel werken. Als een OpenVPN client daarna echter ergens heen wil (bv Google.com op een device op je LAN) stuit die client op je FW en kan niet verder. Vandaar dat je die extra regels nodig hebt.

Je kan de regels natuurlijk inperken door niet alle IP/port combinaties toe te staan, als je vanuit je OpenVPN niet overal naar toe toe hoeft te kunnen.

Snap ik maar dan zou ook mijn 4G connectie toch niet werken als ik die regels niet heb? En die werkt dus wel gewoon, krijg gewoon netjes een DNS van mijn syno etc.

[EricEric752]

SmiGueL schreef op donderdag 2 maart 2017 @ 10:40:
[...]


Ja zie ook mijn edit (link toegevoegd), er zit een verschil in de info van de oude en nieuwe certificaten (poortnummer staat er ineens bij)
Dus dat klinkt aannemelijk.

Ik heb ook een X3 certificaat, maar ik zie nog steeds niet waar jij je poorten (en protocols) in je certificaat ziet. Ik kijk met "View Certificate" in Firefox, maar zie nergens porten. Wat zie ik over het hoofd?

[SmiGueL]

SpoekGTi schreef op donderdag 2 maart 2017 @ 10:22:
Hier iemand ervaring met het OpenVPN pakketje van Synology, heb gisteren iets vaags bij iemand aan de hand.
DNS is ook de Synology.
Windows 10 bak met de OpenVPN software de laatste versie. Inloggen gaat prima, krijg een IP maar daarna is er geen internet verkeer mogelijk als het IPV4 verkeer is.....vaag jazeker.

Hier ook de VPN Server met OpenVPN draaien als package, (custom) port geforward in m'n router. Heb tevens een Ziggo modem (wel een eigen router) En gebruik de Synology tevens ook als DNS server.

Enige wat ik kan bedenken: Zet 'Enable IPv6 server mode' uit in je VPN server settings.

EricEric752 schreef op donderdag 2 maart 2017 @ 10:54:
[...]

Ik heb ook een X3 certificaat, maar ik zie nog steeds niet waar jij je poorten (en protocols) in je certificaat ziet. Ik kijk met "View Certificate" in Firefox, maar zie nergens porten. Wat zie ik over het hoofd?

Ik zie het staan in DSM, bij Control Panel --> Security --> Certificate --> Klikken op certificaat.

[ Voor 25% gewijzigd door SmiGueL op 02-03-2017 11:09 ]

[EricEric752]

SmiGueL schreef op donderdag 2 maart 2017 @ 11:00:
Ik zie het in DSM, bij de certificaatinformatie.

Aha, daar :-)

Daar staat idd de port die ik voor HTTPS gebruik bij. Die info is volgens mij echter om aan te geven welk certificaat gebruikt wordt in welke situatie (bij welke Synology virtual host of proxy server entry). Ik gebruik dat zelf om op mijn LAN een ander certificaat te gebruiken dan op het Let's Encrypt certificaat. Op mijn lan ga ik naar https://nas.lan en ik heb een self-signed certificaat dat werkt op nas.lan. Van buitenaf gebruik ik het Let's Encrypt certificaat. (ja ssl op mijn lan is een beetje overkill, maar "het kan" dus.... )

Het zou natuurlijk kunnen dat Synology die poort info uitleest als het renewal verzoek bij Let's Encrypt wordt gedaan. Maar dan zou Let's Encrypt de optie moeten hebben om de controle uit te voeren op een andere poort dan poort 80 en volgens mij hebben ze die optie niet. Daarom denk ik dat het zo werkt:
- Voor de uitgifte van het eerste certificaat moet de check worden uitgevoerd op poort 80.
- Bij een renewal komt er een verzoek bij Let's Encrypt binnen vanaf IP adres xyz.
- Let's Encrypt ziet dat het een renewal is en geen nieuw request. Ze weten dus dat ze de port 80 test in het verleden hebben uitgevoerd.
- Het domein abc waarvoor het certificaat is, hoort bij IP adres xyz (dat is natuurlijk publieke informatie). Ze concluderen daarom dat het renewal verzoek valide is, want alleen de eigenaar van abc kan een renewal verzoek vanaf IP adres xyz sturen.

[SpoekGTi]

SmiGueL schreef op donderdag 2 maart 2017 @ 11:00:
[...]


Hier ook de VPN Server met OpenVPN draaien als package, (custom) port geforward in m'n router. Heb tevens een Ziggo modem (wel een eigen router) En gebruik de Synology tevens ook als DNS server.

Enige wat ik kan bedenken: Zet 'Enable IPv6 server mode' uit in je VPN server settings.


[...]

Staat niet aan.....gebruik nog helemaal geen IPV6 aan de kant van de Syno. Heb zelf een KPN Glasverbinding liggen en die doet alleen nog maar IPV4

[EricEric752]

SpoekGTi schreef op donderdag 2 maart 2017 @ 10:53:
Snap ik maar dan zou ook mijn 4G connectie toch niet werken als ik die regels niet heb? En die werkt dus wel gewoon, krijg gewoon netjes een DNS van mijn syno etc.

Weet je zeker dat je 4G inderdaad via je vpn werkt? Standaard gaan openvpn requests volgens mij niet de tunnel in. Je kan dat testen door via je 4G/openvpn een DNS request te doen naar een device op je LAN, als je tenminste in je DNS server namen voor je devices op je lan hebt gedefinieerd. Als ik bijvoorbeeld via mijn 4G/openvpn connectie vanaf mijn telefoon connect naar nas.lan weet ik zeker dat ik via de tunnel ga, omdat nas.lan buiten mijn LAN niet bekend is.

Even je FW op je Synology helemaal uitzetten is denk ik ook een goede test om te kijken of die de boel blokkeert.

[ Voor 1% gewijzigd door EricEric752 op 02-03-2017 11:38 . Reden: typo ]

[SpoekGTi]

EricEric752 schreef op donderdag 2 maart 2017 @ 11:35:
[...]

Weet je zeker dat je 4G inderdaad via je vpn werkt? Standaard gaan openvpn requests volgens mij niet de tunnel in. Je kan dat testen door via je 4G/openvpn een DNS request te doen naar een device op je LAN, als je tenminste in je DNS server namen voor je devices op je lan hebt gedefinieerd. Als ik bijvoorbeeld via mijn 4G/openvpn connectie vanaf mijn telefoon connect naar nas.lan weet ik zeker dat ik via de tunnel ga, omdat nas.lan buiten mijn LAN niet bekend is.

Even je FW op je Synology helemaal uitzetten is denk ik ook een goede test om te kijken of die de boel blokkeert.

Ok, punt 1 is nu duidelijk, check, DNS werkt dus niet via de tunnel, waarom ik dan in hemelsnaam een DNS kan pushen in de config file is beyond me maar goed, wat ik was vergeten te melden is dat ik ook die DNS bijvoorbeeld al een keer op de 8.8.8.8 heb gezet. dus dan zou ik een volgende situatie krijgen.

IP VPN: 10.8.0.x
DNS: 8.8.8.8
En redirect gateway staat aan in de config file dus hij moet het verkeer via de VPN leiden alvorens het internet op te gaan. <-- dit zou een punt kunnen zijn wat faalt, maar dan zit het wel aan de client side en niet aan de server side

FW uitzetten op de synology zou geen ander effect mogen opleveren immers via 4G werkt het wel

[afterburn]

SpoekGTi schreef op donderdag 2 maart 2017 @ 10:22:
Hier iemand ervaring met het OpenVPN pakketje van Synology, heb gisteren iets vaags bij iemand aan de hand.

OpenVPN server draait op een Synology DS412+ werkt prima.
DNS is ook de Synology.

Client:

Windows 10 bak met de OpenVPN software de laatste versie. Inloggen gaat prima, krijg een IP maar daarna is er geen internet verkeer mogelijk als het IPV4 verkeer is.....vaag jazeker.

En hoezo conludeer ik dat IPV6 verkeer wel werkt, hij heeft een ziggo verbinding met zowel ipv4 als ipv6 en ik kan wel op websites komen die ipv6 ondersteunen.

IPV6 op de laptop al uitgezet, maar dan heb ik helemaal niets via de VPN

Heb in de firewall van de syno ook al aangegeven dat de ip reeks van de VPN gewoon netjes de DNS mag gebruiken, wat in theorie niet zou hoeven omdat als ik met mijn 4G connectie een VPN opzet naar mijn NAS alles gewoon werkt zoals het hoort.

Iets zegt me dat het Ziggo modem 'iets' doet met de verbinding, maar weet niet wat, en gisteren na 2 uur zoeken was ik er om 23:15 wel een beetje klaar mee

Vergelijkbaar probleem had ik ook, en bij mij was het probleem dat in de DNS op de Synology onder "Resolution" "limit source ip servers" aangevinkt stond. Ik heb daar toen de IP range van de VPN server toegevoegd, en daarna werkte alles zoals verwacht.

[pven]

Ik ben even in de war: in mijn logging zie ik dat ik iedere nacht een nieuwe retrieve van spotweb draai. Maar in mijn scheduled tasks staat ie niet. Waar kan ik hem dan wel terug vinden?

In /etc/crontab zie ik hem overigens wel staan:

code:

DiskStation> cat /etc/crontab
#minute hour    mday    month   wday    who     command
28      1       *       *       0,1,2,3,5       root    /usr/syno/bin/synopkg chkupgradepkg
0       3       *       *       *       root    D=`date +\%Y\%m\%d\%H\%M` ; cd /volume1/web/spotweb; /usr/bin/php retrieve.php > /volume1/log/spotweb_retrieve_${D}.log

[ Voor 52% gewijzigd door pven op 02-03-2017 11:56 ]

[SpoekGTi]

afterburn schreef op donderdag 2 maart 2017 @ 11:47:
[...]

Vergelijkbaar probleem had ik ook, en bij mij was het probleem dat in de DNS op de Synology onder "Resolution" "limit source ip servers" aangevinkt stond. Ik heb daar toen de IP range van de VPN server toegevoegd, en daarna werkte alles zoals verwacht.

En die staat uit , wel even geprobeerd net om hem aan te zetten en dan te testen maar helaas geen effect

[EricEric752]

SpoekGTi schreef op donderdag 2 maart 2017 @ 11:44:
[...]
FW uitzetten op de synology zou geen ander effect mogen opleveren immers via 4G werkt het wel

Tenzij je via 4G op de een of andere manier toch niet via je tunnel gaat. Kan je via 4G een host op je lan pingen? Gewoon op IP adres zodat even niet te maken hebt met DNS issues?

[SpoekGTi]

EricEric752 schreef op donderdag 2 maart 2017 @ 11:57:
[...]

Tenzij je via 4G op de een of andere manier toch niet via je tunnel gaat. Kan je via 4G een host op je lan pingen? Gewoon op IP adres zodat even niet te maken hebt met DNS issues?

Yes, kan via de 4G connectie gewoon op mijn syno komen op IP basis.

[EricEric752]

SpoekGTi schreef op donderdag 2 maart 2017 @ 11:59:
Yes, kan via de 4G connectie gewoon op mijn syno komen op IP basis.

En vanaf je Windows 10 via openvpn? Kan je dan pingen op basis van IP? Ik heb net even zelf geëxperimenteerd op met Windows 10 via Synology openvpn. Zonder allow FW regel voor 10.8.0.0/24 naar Synology kan ik Synology DNS server niet gebruiken. Ping op IP werkt dan wel. Kan je voor de overzichtelijkheid laten weten wat de resultaten zijn van de volgende tests?

Windows via openVPN
- ping naar Synology op IP
- ping naar andere LAN host op IP
- nslookup LAN host
- ping naar Synology op DNS name
- ping naar andere LAN host op DNS name

4G via openVPN
- ping naar Synology op IP
- ping naar andere LAN host op IP
- nslookup LAN host
- ping naar Synology op DNS name
- ping naar andere LAN host op DNS name

Wat toont ipconfig /all voor je openvpn?

[SpoekGTi]

EricEric752 schreef op donderdag 2 maart 2017 @ 13:04:
[...]

En vanaf je Windows 10 via openvpn? Kan je dan pingen op basis van IP? Ik heb net even zelf geëxperimenteerd op met Windows 10 via Synology openvpn. Zonder allow FW regel voor 10.8.0.0/24 naar Synology kan ik Synology DNS server niet gebruiken. Ping op IP werkt dan wel. Kan je voor de overzichtelijkheid laten weten wat de resultaten zijn van de volgende tests?

Windows via openVPN
- ping naar Synology op IP
- ping naar andere LAN host op IP
- nslookup LAN host
- ping naar Synology op DNS name
- ping naar andere LAN host op DNS name

4G via openVPN
- ping naar Synology op IP
- ping naar andere LAN host op IP
- nslookup LAN host
- ping naar Synology op DNS name
- ping naar andere LAN host op DNS name

Wat toont ipconfig /all voor je openvpn?

Poeh ga ik vanavond even op duiken, machine staat elders kom er op terug.

[Havelock]

SmiGueL schreef op dinsdag 16 december 2014 @ 17:27:
[...]


Klopt, net voor de zekerheid even getest.
Indien deze op 'Toegang toestaan' staat dan zijn alle IP's die niet binnen de gedefinieerde regels staan automatisch toegestaan..

Om maar gelijk te reageren op onderstaande vraag van gisteren:


[...]


Om mijn NAS wat beter te beveiligen tegen de buitenwereld heb ik het volgende gedaan:

- Een random externe poort (bijv: 8850) in m'n router geforward naar m'n NAS (5000 of 5001) Zo staat (de standaard) poort 5000 iig dicht voor de buitenwereld.
- Daarnaast zijn in de firewall van de NAS alleen de landen NL BE en DE toegestaan, en is er een regel voor het toestaan van de lokale IP range 192.168.x.0 t/m 192.168.x.255.
Tevens aangevinkt dat 'indien niet aan de regels wordt voldaan' de toegang geblokkeerd wordt.
- Het Admin en Gast account heb ik disabled, zodat niet alleen een wachtwoord maar ook de gebruikersnaam geraden moet worden.
- Na 3x een foute inlogpoging (binnen x minuten) wordt het IP adres waarmee gepoogd wordt in te loggen geblokkeerd.
- SSH zet ik standaard uit, en indien sporadisch nodig (lokaal) vink ik hem even tijdelijk aan. Als je SSH perse nodig bent verander dan iig de poort 22 naar buiten toe.


[*afkloppen] Ik heb iig nog nooit een onbekende inlogpoging gehad.

Hele goeie van je om dit te doen hier heb ik nog niet eens naar gekeken dat dit allemaal kon heb gelijk wat dingen aan gepast beetje vergelijkbaar als wat jij nu heb ingesteld!

Hoe kan je trouwens met dms 6.1 root inloggen met macOS terminal ik weet dat het anders gaat dan de vorige dsm versies.
Ik moet namelijk mijn paswoord resetten van me phpmyadmin en dat kan alleen via root inloggen via terminal om bij dit bestand te komen(config.inc.php en aan te passen deze regel - $cfg['Servers'][$i]['AllowNoPassword'] = false; - false om te zetten in true)
of kan het nu ook op andere manier bij dsm 6.1(lijkt mij van niet dat er een andere manier is hier voor) ?
Ik had ook ergens gelezen dat als je "root" als gebruiker intikt zonder een wachtwoord dat kom je er ook in
Ik weet alleen niet of dit de goede manier is om de password te resetten ik heb uiteraard geprobeerd en lijkt er op dat dit werkt.
Ik weet dat ik niet enige bent die hier waarschijnlijk om vraag ik kon het niet zo gouw vinden 123 of ik zal er wel overheen gekeken hebben.

[ Voor 8% gewijzigd door Havelock op 03-03-2017 06:06 ]

[Havelock]

of is dit nu wat ik zoek ?
https://www.synology.com/...permission_via_SSH_Telnet

Hier gaan ze van uit dat met windows werkt....

[ Voor 14% gewijzigd door Havelock op 03-03-2017 06:30 ]

[Verwijderd]

Hier zie je hoe je dit doet zowel met Win als Mac.

[gertjuhh]

Als je niet weet wat je doet blijf dan van uit de buurt van /etc/sudoers
Gebruik "sudo -i" zoals Havelock aangeeft of "sudo <het commando dat je uit wil voeren als root>"
Dat is voor de doorsnee gebruiker meer dan voldoende.

[EricEric752]

Havelock schreef op vrijdag 3 maart 2017 @ 05:15:
Daarnaast zijn in de firewall van de NAS alleen de landen NL BE en DE toegestaan, en is er een regel voor het toestaan van de lokale IP range 192.168.x.0 t/m 192.168.x.255

Voor zover ik weet werkt dit niet. Volgens mij werkt het zo: De FW past de eerste regel toe die werkt. Als je dus alleen maar een allow regel hebt, die NL en BE toestaat en verder helemaal geen regels (behalve een deny for all) dan werkt het inderdaad.

Als je echter nog meer regels hebt, bijvoorbeeld een allow op een bepaalde port xx, dan gebeurt er dit bij een een toegangspoging vanuit bijvoorbeeld Rusland op port XX:
- Regel "allow NL/BE" -> Geen hit, want niet uit NL/BE
- Regel "allow op port xx" -> Wel hit, want port xx. Het feit dat er dan vanuit Rusland wordt ingelogd telt dan niet meer, want dat was van toepassing op een vorige regel.

Als je dus daadwerkelijk landen wilt blokken dan moet je ze actief blokken. Helaas kun je maar 15 landen per FW regel kwijt. Dan werkt het als volgt bij toegang uit Rusland:
- "Regel "deny Rusland" -> Wel hit, dus toegang wordt geblokt.

[SpoekGTi]

EricEric752 schreef op donderdag 2 maart 2017 @ 13:04:
[...]

En vanaf je Windows 10 via openvpn? Kan je dan pingen op basis van IP? Ik heb net even zelf geëxperimenteerd op met Windows 10 via Synology openvpn. Zonder allow FW regel voor 10.8.0.0/24 naar Synology kan ik Synology DNS server niet gebruiken. Ping op IP werkt dan wel. Kan je voor de overzichtelijkheid laten weten wat de resultaten zijn van de volgende tests?

Windows via openVPN
- ping naar Synology op IP
- ping naar andere LAN host op IP
- nslookup LAN host
- ping naar Synology op DNS name
- ping naar andere LAN host op DNS name

4G via openVPN
- ping naar Synology op IP
- ping naar andere LAN host op IP
- nslookup LAN host
- ping naar Synology op DNS name
- ping naar andere LAN host op DNS name

Wat toont ipconfig /all voor je openvpn?

Bent ik weer,

Gisteren een 2de machine die het ook niet deed altijd leuk, wat me opviel is dat de vpn connectie geen Gateway kreeg.

Heb wat zitten spelen en nee nog steeds niet gefixxed, maar heb een workaround.

Heb mijn Synology Router nu ingesteld als VPN en presto het werkt. Voor nu is het fixxed, ik ga wel een test omgeving opzetten, Probleem deed zich voor met een Windows 10 met een TAP adapter van Openvpn.

Heb overigens ook de Firewall op mijn NAS nog uitgehad maar ook dit geen effect.

[kraats]

EricEric752 schreef op vrijdag 3 maart 2017 @ 10:20:
[...]

Voor zover ik weet werkt dit niet. Volgens mij werkt het zo: De FW past de eerste regel toe die werkt. Als je dus alleen maar een allow regel hebt, die NL en BE toestaat en verder helemaal geen regels (behalve een deny for all) dan werkt het inderdaad.

Als je echter nog meer regels hebt, bijvoorbeeld een allow op een bepaalde port xx, dan gebeurt er dit bij een een toegangspoging vanuit bijvoorbeeld Rusland op port XX:
- Regel "allow NL/BE" -> Geen hit, want niet uit NL/BE
- Regel "allow op port xx" -> Wel hit, want port xx. Het feit dat er dan vanuit Rusland wordt ingelogd telt dan niet meer, want dat was van toepassing op een vorige regel.

Als je dus daadwerkelijk landen wilt blokken dan moet je ze actief blokken. Helaas kun je maar 15 landen per FW regel kwijt. Dan werkt het als volgt bij toegang uit Rusland:
- "Regel "deny Rusland" -> Wel hit, dus toegang wordt geblokt.

onderaan staat wat er moet gebeuren als er aan geen regels wordt voldaan. Standaard wordt hier een deny op gedaan. Dus als je in de regels aangeeft wat wel moet worden toegelaten en daar wordt niet aan voldaan, volgt vanzelf een deny op de verbinding. Zo hoef je niet allerlei deny regels aan te gaan maken.

[m00n]

Probeer mijn Sickrage package op mijn DS412+ van een Let's Encrypt SSL te voorzien.
Iemand dit al eens geprobeerd?

Heb er 1 aangemaakt via Beveiliging -> Certificaten. Vervolgens de certificaat gedownload.

Package bevat:
Cert.pem
Chain.pem
Privkey.pem

Sickrage vraagt om:
.key --> is dus privkey.pem
.crt --> is dus cert.pem

Ik kan een path opgeven en niet bestanden uploaden.

Iemand een idee wat de path is waar Synology zijn Let's Enecrypt certificaten opslaat?


Daarnaast nog het volgende, ik probeer mijn DS412+ via nas.mijndomein.nl te bereiken waarbij hij automatisch naar https://nas.mijndomein.nl door gestuurd wordt.

Als ik naar https://nas.mijndomein.nl werkt alles perfect, echter http:// stuurt hij niet automatisch door.
Wat is de juiste instelling bij Reverse Proxy hiervoor?

[ Voor 25% gewijzigd door m00n op 03-03-2017 11:29 ]

[EricEric752]

kraats schreef op vrijdag 3 maart 2017 @ 11:19:
[...]
onderaan staat wat er moet gebeuren als er aan geen regels wordt voldaan. Standaard wordt hier een deny op gedaan. Dus als je in de regels aangeeft wat wel moet worden toegelaten en daar wordt niet aan voldaan, volgt vanzelf een deny op de verbinding. Zo hoef je niet allerlei deny regels aan te gaan maken.

Ja, dat klopt. Vandaar dat ik aangeef dat als je alleen maar een regel hebt die NL/BE toe laat en verder niets, dan hou je idd access vanuit buiten NL/BE tegen. Vanuit Rusland werkt het dan bijvoorbeeld zo:

FW regel 1: allow NL/BE -> Geen hit, dus door naar volgende regel
Algemene deny all regel -> Hit dus geen toegang

Als er echter nog andere "allow" regels zijn, waaraan de toegangspoging wel voldoet, dan treden die in werking. Elke regel wordt namelijk op zichzelf bekeken en zodra er een "hit" is, wordt die toegepast en verdere regels worden genegeerd. Voor zover ik weet is dat hoe het werkt. Zo dus vanuit Rusland op port xx:

FW regel 1: allow NL/BE/DE -> Geen hit, dus door naar volgende regel
FW regel 2: allow port xx -> Hit, dus toegang. Verdere regels worden overgeslagen
Algemene deny all regel -> regel wordt overgeslagen omdat er al een allow is gegeven

Om Rusland dus echt te blokken moet het dus zo worden:

FW regel 1: deny Rusland -> Hit, dus geen toegang. Verdere regels worden overgeslagen
FW regel 2: allow port xx -> regel wordt overgeslagen omdat er al een deny is gegeven
Algemene deny all regel -> regel wordt overgeslagen omdat er al een deny is gegeven

[kraats]

@EricEric752 ik snap wat je zegt, maar bij een allow regel geef je herkomst én poort aan. Geef je alleen een poort op en geef je die voor de wijde wereld vrij, dan is dat een expliciete keuze. Een deny-regel ervoor omdat je je overige regels niet strikt genoeg instelt is een mogelijkheid, maar wat mij betreft niet de beste

[EricEric752]

kraats schreef op vrijdag 3 maart 2017 @ 11:45:
@EricEric752 ik snap wat je zegt, maar bij een allow regel geef je herkomst én poort aan. Geef je alleen een poort op en geef je die voor de wijde wereld vrij, dan is dat een expliciete keuze. Een deny-regel ervoor omdat je je overige regels niet strikt genoeg instelt is een mogelijkheid, maar wat mij betreft niet de beste

Klopt helemaal en mijn post is bedoeld om daarop te wijzen. Ik denk namelijk dat er best veel mensen zijn die zullen denken dat een allow regel voor NL/BE de rest van de wereld uitsluit en daarna in de verdere FW regels geen rekening meer houden met herkomst "omdat dat al in de eerste FW regel is geregeld". Dat is dus niet het geval. Een expliciete deny op landen is trouwens ook leuk, om te zien hoeveel inlogpogingen er zijn. Met de "catch-em-all" deny onderaan de lijst zie je de hits niet. Ik heb zelf een rijtje landen FW regels gegegroepeerd per werelddeel met daarin de "usual suspects" in mijn Synology router en daaraan is te zien hoeveel connectiepogingen er geblockt worden. Het verbaast me altijd weer hoeveel dat er zijn, ook al omdat mijn Synology router achter mijn Ziggo router, waarbij ik mijn Ziggo router heb geconfigureerd om alleen de poorten van 0-1024 door te geven naar mijn Synology. Dan nog zijn er enorm veel connectiepogingen.

[Quakie]

Zo, even een 'feel good' verhaal tussendoor:

Mijn DS415+ bleef hangen en na 3/4 weken dagelijks contact gehad te hebben met synology support heb ik hem vorige week vrijdag als RMA terug gestuurd. Unit was maandag binnen en gisteren had ik een nieuwe DS415+ thuis staan.Unit komt uit de UK. Ik had inmiddels mijn backup nas (DS213+) als hoofd nas ingericht, want ik had niet verwacht dat ik binnen een week een nieuwe unit zou hebben.
Gisteren dus aangesloten, 3 schijven terug. Schoon begonnen want 1) RC versie stond erop 2) en had zoveel dingen ermee gedaan via support dat ik liever clean begin.
Nu had ik expres op de DS213+ alles op nieuwe volume hersteld. Deze schijf had ik dus als losse volume in mijn DS415+ aangesloten. Daarna de shared folders verplaatst. Dit kost toch nog wel aardig wat tijd, maar sneller dan via netwerk alles restoren.

Nu 4de schijf toevoegen aan SHR volume en ik ben klaar. Helaas ziet het er naar uit dat dit wel een lang gaat duren, en alle packages zijn afgesloten, maar goed is niet anders.

In mijn ogen super goede service (ik had min of meer begin feb al goedkeuring voor een vervanger, voor CPU bug) maar vooral super snel!

[ Voor 5% gewijzigd door Quakie op 03-03-2017 16:20 ]

[WRT54G]

Quakie schreef op vrijdag 3 maart 2017 @ 16:18:
Zo, even een 'feel good' verhaal tussendoor:

Mijn DS415+ bleef hangen en na 3/4 weken dagelijks contact gehad te hebben met synology support heb ik hem vorige week vrijdag als RMA terug gestuurd. Unit was maandag binnen en gisteren had ik een nieuwe DS415+ thuis staan.Unit komt uit de UK. Ik had inmiddels mijn backup nas (DS213+) als hoofd nas ingericht, want ik had niet verwacht dat ik binnen een week een nieuwe unit zou hebben.
Gisteren dus aangesloten, 3 schijven terug. Schoon begonnen want 1) RC versie stond erop 2) en had zoveel dingen ermee gedaan via support dat ik liever clean begin.
Nu had ik expres op de DS213+ alles op nieuwe volume hersteld. Deze schijf had ik dus als losse volume in mijn DS415+ aangesloten. Daarna de shared folders verplaatst. Dit kost toch nog wel aardig wat tijd, maar sneller dan via netwerk alles restoren.

Nu 4de schijf toevoegen aan SHR volume en ik ben klaar. Helaas ziet het er naar uit dat dit wel een lang gaat duren, en alle packages zijn afgesloten, maar goed is niet anders.

In mijn ogen super goede service (ik had min of meer begin feb al goedkeuring voor een vervanger, voor CPU bug) maar vooral super snel!

Goed om te horen Quakie!
Fijn dat ie weer terug is.

Ik heb mijn DS415+ vandaag ingeleverd bij Wifi Media tesamen met mijn (mail) conversaties met Synology.
Ze gaan hem zsm naar Synology sturen en ik zou binnen 5 - 10 werkdagen hier iets op terug moeten krijgen.
Zodra ik wat meer weet zal ik zeker weer terug koppelen hier.

[Quakie]

Marcel_EA schreef op vrijdag 3 maart 2017 @ 16:24:
[...]


Goed om te horen Quakie!
Fijn dat ie weer terug is.

Ik heb mijn DS415+ vandaag ingeleverd bij Wifi Media tesamen met mijn (mail) conversaties met Synology.
Ze gaan hem zsm naar Synology sturen en ik zou binnen 5 - 10 werkdagen hier iets op terug moeten krijgen.
Zodra ik wat meer weet zal ik zeker weer terug koppelen hier.

Thanks! hopelijk heb je dadelijk even goede ervaringen als ik...

[WRT54G]

Fingers crossed!

[Daniel.]

Hebben ze in DSM 6.1 de Edge bug gefixt. In edge liep DSM 6.0 altijd vast dat is wel prettig.

[technorabilia]

Ik zag dat er een DSM 6.1 update 1 beschikbaar was. De update was binnen 10 sec gedaan maar ik krijg nu de melding hieronder. Ik wist wel dat DSM 6.1 meer modulair opgezet zou zijn maar dit heb ik met DSM 6.0 en eerder niet gezien dat je zelf moet herstarten. Op zich wel goed natuurlijk...

Dear user,

A new version of Critical Update has been updated successfully. A system restart is required to complete the update.

Sincerely,
Synology DiskStation

[JacobsT]

@kraades ik heb de update uitgevoerd op men 716II+ en nu wil deze niet meer booten.

Flikkert blauw powerledje hele tijd en geraak niet meer in DSM.
Systeem boot als ik beide schijven eruit haal maar verder geen leven in te krijgen.
Ga morgen als ik tijd heb eens contact opnemen met Synology. Tot op heden wat rondgezocht en nog niet echt mensen met gelijkaardige problemen gevonden op 1 iemand na hier ook bij Tweakers.

[Virtua]

Afgelopen weekend precies het zelfde gehad met de 716+ is de 2de keer nu met deze nas dat die door een update het niet meer doet, eerst was het in eens dat de update terug getrokken werd, gevolg was dat die teruggestuurd werd na synology, nu echter starte geen enkele schijf meer op en heb dus de complete nas opnieuw moeten instaleren, hoop data kwijt dus ga nu me nas maar spiegelen met een externe harde schijf, los van al de tijd die je erin steekt om dat ding naar wens te laten draaien is dat wel het ergste, iedergeval begin ik het vertrouwen van synology wel kwijt te raken.
Als het werkt is het een wereld apparaat maar bij een update de complete nas opnieuw in te richten voor de 2de keer in een half jaar is niet te doen als dit zo blijft, heb de updates dan ook uitgeschakeld en ga eerst is kijken op forums of het goed draait, wat wel vreemd was dat de update goed verliep echter een paar dagen later toen ik de nas herstarte was er geen leven meer in.
Echt balen

[technorabilia]

@JacobsT @virtua69 dus dit is na de installatie van de laatste update 1 en daarna een reboot? Ik heb namelijk ook een DS716+ dus ik ben dan een beetje huiverig om te rebooten...

[kraats]

Ik heb een 716+II en heb (gelukkig) geen problemen ervaren

[Cartman!]

Hier ook n 716+II die t gewoon nog doet. Enige probleem was dat VPN package niet meer wilde starten maar na een reboot was dat ook verholpen. Zover ik her en der lees heb je daar last van als je OpenVPN op een niet standaard poort draait. Ik draai mijne op poort 443 omdat dit vrijwel nergens geblokkeerd wordt en ik zo altijd kan inloggen.

Schrok me nog rot vanmorgen, ik inloggen en al m'n data was pleite en zag geen packages meer Bleek dat ik ingelogd was als vpn user die nergens rechten op heeft behalve verbinden met VPN. Wat was ik blij dat alles er nog stond nadat ik ingelogd was als admin

[ Voor 19% gewijzigd door Cartman! op 04-03-2017 19:01 ]

[technorabilia]

Ok, toch maar gereboot en het ging allemaal goed.

[Virtua]

kraades schreef op zaterdag 4 maart 2017 @ 18:37:
@JacobsT @virtua69 dus dit is na de installatie van de laatste update 1 en daarna een reboot? Ik heb namelijk ook een DS716+ dus ik ben dan een beetje huiverig om te rebooten...

klopt, ik had een update gedaan van sonarr via het packache center en daarna herstart.
dacht dat het daar aan lag maar naar wat ik daarvoor las zou het zo maar weer een bug kunnen zijn voor intel.
dit was de eerste keer ook en werd tijdelijk de ondersteuning gestaakt.
ik zou hem niet opstarten als ik jou was en wachten tot een volgende update.
was echt veel werk om me nas weer terug te krijgen(ben nog aan afstellen)

[Virtua]

virtua69 schreef op zaterdag 4 maart 2017 @ 21:46:
[...]

klopt, ik had een update gedaan van sonarr via het packache center en daarna herstart.
dacht dat het daar aan lag maar naar wat ik daarvoor las zou het zo maar weer een bug kunnen zijn voor intel.
dit was de eerste keer ook en werd tijdelijk de ondersteuning gestaakt.
ik zou hem niet opstarten als ik jou was en wachten tot een volgende update.
was echt veel werk om me nas weer terug te krijgen(ben nog aan afstellen)

zie net dat bij jou alles goed ging...beter man

[vandermark]

Ik heb momenteel alleen port 443 open staan op mijn router omdat ik ideaal via reverse proxy en let's encrypt alles over SSL naar mijn synology doe, ideaal en blij mee

Ik zit nu alleen nog met SFTP over poort 22.
Ik dacht ik, maak een reverse proxy van https://sftp.server.nl --> local:22

Maar dat lukt niet? Is er een mogelijkheid om poort 22 ook dicht te zetten en de sftp server op de synology te laten luisteren naar de reverse proxy?

[chielmi]

Zojuist mijn 216+II ge-upgrade van 6.1 naar 6.1-15047 Update 1. Na handmatig opnieuw starten kreeg ik geen connectie met mijn NAS via de gui en ssh. Knipperende blauwe led, lan en disk leds. Las vervolgens op het Synology forum dat ik niet de enige ben

Na een half uur wachten toch maar besloten het NAS uit te zetten door x seconden de power in te drukken. Vervolgens start het NAS probleemloos op . Ik hou wel m'n hart vast voor een volgende reboot...

[b]Edit[/b]: holy fuck, alle data in "homes" is weg
Edit2: loos alarm. Ik heb encryptie voor de homes folder ingeschakeld, moest nog de decrypt code invoeren. Het vreemde is dat er in de tussentijd wel een homes_0 map wordt aangemaakt in de root van het volume. Verwarrend...

[ Voor 24% gewijzigd door chielmi op 05-03-2017 16:48 ]

[job]

m00n schreef op vrijdag 3 maart 2017 @ 11:23:
Probeer mijn Sickrage package op mijn DS412+ van een Let's Encrypt SSL te voorzien.
Iemand dit al eens geprobeerd?

De makkelijkste optie is de synology zelf een let's encrypt certificaat aan te laten vragen. Dit certificaat stel je dan meteen in voor het gehele domein domein, en alle subdomeinen die je wilt gebruiken.
Als je gebruik maakt van de reverse proxy in dsm maak je gebruik van het certificaat van de syno.. voor sickrage hoe je dan geen eigen certificaat in te stellen.

Control panel > security > certificacte > add ( en daar voor let's encrypt kiezen)


Voor sickrage zou ik combinatie met de let's encrypt certificate in dsm de volgende instellingen kiezen.
configuratie scherm, application portal > reverse proxy
description: sickrage
source
protocol https
hostname sickrage.domein.nl
port 443
Destination
protocol http
hostname 127.0.0.1
port 8083

Daarnaast nog het volgende, ik probeer mijn DS412+ via nas.mijndomein.nl te bereiken waarbij hij automatisch naar https://nas.mijndomein.nl door gestuurd wordt.

Als ik naar https://nas.mijndomein.nl werkt alles perfect, echter http:// stuurt hij niet automatisch door.
Wat is de juiste instelling bij Reverse Proxy hiervoor?

description: dsm http
Source
protocol http
hostname nas.domein.nl
port 80
Destination
protocol https
hostname 127.0.0.1
port 5001

Werkt niet?

[ Voor 46% gewijzigd door job op 06-03-2017 00:22 ]

[Lunaticc]

vandermark schreef op zondag 5 maart 2017 @ 16:12:
Ik heb momenteel alleen port 443 open staan op mijn router omdat ik ideaal via reverse proxy en let's encrypt alles over SSL naar mijn synology doe, ideaal en blij mee

Ik zit nu alleen nog met SFTP over poort 22.
Ik dacht ik, maak een reverse proxy van https://sftp.server.nl --> local:22

Maar dat lukt niet? Is er een mogelijkheid om poort 22 ook dicht te zetten en de sftp server op de synology te laten luisteren naar de reverse proxy?

Werkt dat ook als een applicatie meerdere poorten nodig heeft? Encrypted rsync heeft bijvoorbeeld 873(?) en 22 nodig. Lijkt me ook wel handig namelijk

[vandermark]

Ideedeequeuedee schreef op zondag 5 maart 2017 @ 17:54:
[...]


Werkt dat ook als een applicatie meerdere poorten nodig heeft? Encrypted rsync heeft bijvoorbeeld 873(?) en 22 nodig. Lijkt me ook wel handig namelijk

Dat weet ik niet, je kan maar één poort instellen met reverse proxy volgens mij.

[Verwijderd]

Heb net bij Synology een verzoek ingediend of ze bij Hyper Backup kunnen inbouwen dat grote uploads naar Amazon Drive alleen gebeuren tijdens uren die ik zelf aangeef zodat netwerk niet belast wordt tijdens uren dat ik het zelf gebruik. Ben nu meer 500 GB aan het uploaden en dat duurt 5 dagen, mag van mij best in 10 en dan tijdens nachtelijke uren. Ben benieuwd of dit kan en wordt opgepakt.