Synology-Forum.nl
Synology Router => Synology Router => Topic gestart door: Babylonia op 24 augustus 2022, 08:54:16
-
24-08-2022 "Release candidate" SRM 1.3.1-9346 - Update 1
Release Notes:
RT6600ax: https://www.synology.com/nl-nl/releaseNote/SRM?model=RT6600ax#ver_9346-1
RT2600ac: https://www.synology.com/nl-nl/releaseNote/SRM?model=RT2600ac#ver_9346-1
MR2200ac: https://www.synology.com/nl-nl/releaseNote/SRM?model=MR2200ac#ver_9346-1
Advies IMO, kijk nog steeds de kat uit de boom voor degene die helemaal nog niet naar SRM 1.3.1 x zijn gegaan.
Gebruikers die al wel de stap hebben genomen, kunnen dat uiteraard al wel doen.
Het betreft alleen een updatepatch van pakweg 10 ~ 11 MB
Dus de eerdere SRM versie 1.3.1-9346 moet dan wel eerst zijn geïnstalleerd.
28-08-2022: Inmiddels is er ook een versie inclusief update 1 in de volledige versie SRM 1.3.1-9346 verwerkt.
(De eerdere versie 1.3.1-9346 zonder update 1 was mogelijk niet meer te downloaden, voor latere "instappers").
Zie status van de download mogelijkheden:
https://archive.synology.com/download/Os/SRM
Zelf heb ik update 1 inmiddels ook geïnstalleerd, zie later bericht (https://www.synology-forum.nl/synology-router/release-candidate-srm-versie-1-3-1-9346-update-1/msg315044/#msg315044) in dit onderwerp m.b.t. ervaringen tot nu toe.
-
-
-
Handmatige update ?
-
Inderdaad handmatige update.
Inmiddels wel geïnstalleerd, maar merk verder geen verschil met de typische Support tickets waar ik mee bezig ben.
En dat is met name het gebruik van de KPN IPTV-box in samenwerking met meerdere routers in mesh mode.
Dat functioneert gewoonweg NIET. Waarbij de TV-ontvanger gewoon achter een LAN-poortje van de hoofdrouter aangesloten.
Ik moet de extra mesh Points werkelijk volledig uit de setup halen (verwijderen en resetten), dus géén mesh points.
Dan hersteld TV zich binnen circa 3 seconden, nadat het laatste mesh point uit de set-up is gehaald.
Maar achterliggend zitten er nog meer zaken die grondig doorgenomen moeten worden aangaande IPTV.
Als ik een "gesloten" netwerk (IoT) heb ingesteld, voor alleen toegang binnen het LAN netwerk.
Internet is dan niet te bereiken via een webbrowser, of anderszins via bijv. FTP via dat netwerk.
Blijft op dit netwerk WEL gewoon de TV-stream binnenlopen / bereikbaar.
Men kan het verder ook niet blokkeren via firewall, of op andere wijze.
(Op alle extra netwerken is IPTV te bereiken).
Synology heeft helemaal geen rekening gehouden met dit scenario binnen de opzet van SRM.
Terwijl toch allerlei menu's m.b.t. IPTV & VoIP zijn opgenomen en bijv. IGMP proxy wat typisch wordt ingezet voor IPTV.
Het lijkt wel of men dit onderdeel in de verdere uitwerking op netwerken volledig "vergeten" is?
-
Ik reageerde op Reactie #1 van @aliazzz over het feit dat hij update 1 niet geïnstalleerd kreeg, maar ik zie dat die reactie is verwijderd.
Kennelijk probleem opgelost, weten nu niet wat de oplossing was.......jammer ::)
-
Hm de oplossing was dat de handmatige update in mijn geval een drietal files van 10 MB zijn en niet een drietal files van 200+ MB.. :thumbup:
Deze staan in een andere subdirectory
-
Als je de versie 1.3.1-9346 RC geinstalleerd heb kan de update alleen worden geinstalleerd met de update die staat in de download directory. SRM versie 1.3.19346 - update 1 (https://archive.synology.com/download/Os/SRM/1.3.1-9346-1-NanoPacked)
Installatie van de versie inclusief update 1 is dan niet mogelijk.
-
Nu geef je verkeerde informatie af- of mogelijk een vergissing van een verkeerde download directory?
Te zien aan de "te grote" bestanden voor alleen de patch. Je verwijst naar een versie 1.3.1-9346 RC inclusief de update 1
- Als je eerder SRM 1.3.1-9346 RC hebt geïnstalleerd - die staat nu namelijk niet meer online.
- Daar achteraan kun je dan de aparte update 1 patch nog installeren van pakweg 10 ~ 11 MB.
Ben je later ingestapt met SRM 1.3.1 en zou je nu alsnog de eerdere versie SRM 1.3.1-9346 RC willen installeren, kan dan niet.
Want die is niet meer te downloaden.
- Vandaar nog een nieuwere versie SRM 1.3.1-9346 RC inclusief de update 1
Of die versie inclusief update 1 als geheel ook te installeren is, terwijl je de eerdere SRM 1.3.1-9346 RC versie reeds had geïnstalleerd,
kan ik niet bevestigen, want eenmaal een update gedaan kun je dat zonder moeilijke omwegen niet nog eens proberen.
-
Sorry voor het gebruik van de verkeerde koppeling.
De koppeling voor de aparte update die ik vanochtend heb gebruikt voor mijn RT2600AC is: update 1 voor RT2600AC (https://global.download.synology.com/download/SRM/criticalupdate/update_pack/9346-1/synology_ipq806x_rt2600ac.pat)
Ik dacht eerst de versie inclusief update 1 te gebruiken, maar kwam er toen achter dat het niet werkt.
De afzonderlijke update staat niet in het downloadcentrum (https://www.synology.com/nl-nl/support/download)
-
AC2600 is: update 1 voor AC2600 (https://global.download.synology.com/download/SRM/criticalupdate/update_pack/9346-1/synology_ipq806x_rt2600ac.pat)
Wat is een AC2600 ? ;)
De afzonderlijke update staat niet in het downloadcentrum (https://www.synology.com/nl-nl/support/download)
Jawel hoor: https://archive.synology.com/download/Os/SRM/1.3.1-9346-1 (11.34MB)
-
Gewijzigd in RT2600ac (sorry, niet 2 dingen tegelijk doen. Ik zit al naar de Formule 1 voorbeschouwing te kijken).
Downloadcentrum: Niet via de website volgens de hyperlink die ik aangeef!
Wel via archive...... enz. Deze heb ik gebruikt om te downloaden en installeren
-
Niet via de website volgens de hyperlink die ik aangeef!
Dat is ook nog nooit zo geweest met patches, ook niet met DSM. ;)
-
Op dit punt moet ik je toch corrigeren @Birdy.
Ik gebruik de download via de website meestal!
zie bijgaand een voorbeeld
-
Oh.... Gelijk heb je, sorry.
-
Net een ontstellend vervelende aanpassing ontdekt.
Weet niet of het bij deze update is geïntroduceerd of eerder?
Maar bij gebruik van Synology SSL VPN (m.b.v. een VPN Plus Client op PC of smartphone),
werkt dat nu niet meer goed onder Windows. Althans met beperkingen.
Men heeft de login directory aangepast, waardoor je nu gedwongen wordt een *wildcard* certificaat in te zetten.
Terwijl je eerst met een "gewoon" certificaat kon inloggen - en nog steeds als zodanig onder SRM 1.2.5.
Met gebruik van een eigen NL domein wordt een wildcard certificaat voor een hobbyist een te kostbare aangelegenheid.
ZONDER wildcard certificaat kom je er niet meer in / kun je niet inloggen. Uitzonderingen erop in een browser zijn ook niet te maken.
De inlogpagina via VPN Plus onder Windows:
SRM 1.2.5 https://[ NL domein ]:[ poort ]//webportal.cgi#/
SRM 1.3.1 https://login.[ NL domein ]:[ poort ]//webportal.cgi#/
Daar ben ik dus niet mee in mijn nopjes.
Je kunt exclusief via de DDNS service van Synology zelf wel gebruik maken van een "wildcard" Let's Encrypt certificaat.
Maar daar zit ik ook niet echt op te wachten.
-
Ik vind het heel vreemd dat ze er ongevraagd een subdomein voor zetten. Dan ben je plots ook niet meer bereikbaar op het internet, tenzij je dit subdomein ook bij je DNS provider toevoegt.
Het zal vast een instelling zijn die uit/aan te zetten is en waar je het subdomein kan kiezen.
ps: zo'n subdomein heeft toch niets met windows te maken? Dat moet dan ook zo zijn bij Android, iOS, MacOS, Linux etc.
-
Via Android kan het zijn dat men een andere methode volgt?? Want die heeft nog een oudere versie VPN Plus Client.
Binnen Windows, met dezelfde VPN Client software versie 1.4.5-0684_X64 in een webbrowser, onder dezelfde web-pagina,
maar dan alleen het gebruik van een andere poort (heb twee routers achter elkaar, en zou dan van beide SSL VPN kunnen benaderen.
Heeft alleen SRM 1.3.1 dat vervelende extra subdomein. Vind inderdaad nergens info daarover terug.
Terugklikken naar de andere ingang voor SRM 1.2.5 werkt het weer direct.
Ben net bezig een support ticket aan te maken.
Maar met het hier schrijven van deze reactie en software versienummers VPN Client, krijg ik wel een extra idee.
Zal de vorige VPN Plus Client er eens op zetten. Geeft meteen inzicht of het misschien daar aan ligt?
EDIT: Oudere VPN Client versie 1.4.4-0635_X64 geprobeerd - heeft dezelfde foutmelding voor SRM 1.3.1
https://archive.synology.com/download/Utility/VPNPlusClient
-
M.b.t. SSL VPN Ik ben eruit - opgelost !!
Hoewel het wel nodig is een support ticket in te sturen, want toch niet alles draait zoals het is bedoeld.
Enkele dagen terug heb ik wat zaken doorgenomen / getest m.b.t. VPN Plus server (voor verdere aanvulling handleiding (https://www.synology-forum.nl/synology-router/rt6600ax-router-setup-en-zijn-mogelijkheden/) RT6600ax).
Heb (voor mogelijk een schermafdruk?) daarbij WebVPN ingeschakeld.
Voor gebruik van dat WebVPN is wel een *wildcard* certificaat benodigd. Dat is overigens al jaren zo !!
Maar heb erna dat WebVPN niet meer uitgeschakeld (en was dus nog actief).
Ondanks voor WebVPN expliciet een andere poort is ingesteld dan voor SSL VPN.
En ik voor benadering naar het VPN portaal de voor SSL VPN geldende poort invul,
wordt toch de login pagina methode voor WebVPN gebruikt.
Dat is inclusief die login prefix voor het domein: https://login.[ NL domein ]:[ poort ]//webportal.cgi#/
Met uitschakelen van de WebVPN methode is de inlog via SSL VPN hersteld = zonder prefix.
Maar ja, er mag natuurlijk geen wisseling van een portaal login methode zijn bij verschillend gebruikte services en poorten.
Dus weer werk aan de winkel voor Synology.
De situatie van de twee VPN methoden (die alle twee een browser web-pagina portaal gebruiken):
[attach=1] [attach=2]
-
Bedankt maar weer voor het uitzoeken en testen :thumbup:.....zet ze maar weer aan het werk...... :lol:
-
Kennelijk al een erg oude bug. :o
Geprobeerd met WebVPN inschakelen onder SRM 1.2.5 en ook daar komt hetzelfde probleem naar voren.
Terwijl de poort van WebVPN naar de 2e router waar ik nu gebruik van maak helemaal geen port forwarding heeft voor dat WebVPN.
Alleen SSL VPN (en andere VPN methoden).
Blijkbaar probeert niemand die twee VPN methoden naast elkaar uit door ze beide in te schakelen.
Anders was het beslist wel een keer door iemand te berde gebracht.
Maar ja, het is altijd de "gek" die het wel uitprobeert, om zo compleet mogelijk alle opties te doorgronden. :P :lol:
-
Alleen zie ik de noodzaak van een wildcard certificaat nog steeds niet. Het subdomein is bekend en zelf in te stellen. Dan kun je toch ook gewoon een certificaat met dat subdomein gebruiken.
Ik heb stapels subdomeinen in gebruik (b.v. mail.domein.nl, smtp.domein.nl, dsm.domein.nl. etc) maar heb nog nooit een wildcard certificaat gebruikt.
NB: kun je dat prefix veld ook leeg laten?
-
Ik ben nooit zo van dat 'wildcard" gedoe. Dat is vragen om een security issue omdat je dan plots elk subdomein geldig maakt.
Ik heb al voorbeelden van phishing mails gezien die daar misbruik van maken. b.v. *.legitiemesite.nl met een mooi spf protocol die specificeert wie mail mag versturen.
De phishers gebruikten vervolgens de gespoofde afzender "info@nep.legitiemesite.nl". Dat is dan ook een legitiem adres en het opvragen van de spf geeft geen fout, alleen is er dan geen spf record. Deze gespoofde mail wordt door het ontbreken van een spf record op dit subdomein als authentiek aangemerkt.
Hier is wel tegen op te treden met een beter spf record op het hoofddomein, maar als je rondkijkt wordt dit meestal vergeten.
-
Alleen zie ik de noodzaak van een wildcard certificaat nog steeds niet.
Ik ben nooit zo van dat 'wildcard" gedoe. Dat is vragen om een security issue omdat je dan plots elk subdomein geldig maakt.
Daar ben ik het helemaal mee eens. Maar zo werkt de Synology WebVPN methode nu eenmaal.
Het gaat daarbij niet zozeer om een sub-domein met de benaming "login" als prefix. Want die naam kun je veranderen.
(Het veld leeg laten wordt overigens niet geaccepteerd).
In een grijs verleden heb ik daar wel eens mee getest.
Door via een trucje even www als prefix in te vullen, in het menu van WebVPN (https://www.synology-forum.nl/synology-router/release-candidate-srm-versie-1-3-1-9346-update-1/?action=dlattach;ts=1661782993;attach=57523;image) waarmee ik dat stukje kon omzeilen,
omdat ik toen ook geen wildcard certificaat had. www is een uitzondering. Daarmee kon ik in ieder geval wel dat WebVPN activeren.
Van daaruit kon ik verder testen (en toen nog wel telkens uitzonderingen maken in de webbrowser bij elke stap verder).
Via die WebVPN methode worden er hele reeksen "random" code vóór een domeinnaam gezet,
als onderdeel van wellicht een beveiligingssleutel? (Zonder de juiste combinatie geen verbinding. Dus zo onveilig lijkt het niet te zijn).
Die wisselende codering als prefix, werkt alleen met een wildcard certificaat.
Vond dat WebVPN toen al geen interessante VPN methode.
(Men moest "per geopend tabblad" in een webbrowser controleren of de connectie via VPN of een normale internetverbinding liep).
Maar mag uiteraard niet verward worden met SSL VPN, een andere VPN methode. Wat het nu wel doet als beide zijn geactiveerd.