Synology-Forum.nl
Hardware ondersteuning => Netwerk algemeen => Topic gestart door: Dyslexia op 24 november 2018, 21:43:12
-
Hallo,
Ik heb een simpele vraag, zie Onderwerp regel.
Mijn opzet is denk ik simpel van aard, zoals misschien bij vele net als ik niet zo technisch onderlegde gebruikers.
Simpele router van Ziggo (Cisco EPC3925). Bejaard?, misschien best wel, maar werkt op zich voor mij prima.
NAS heeft geen extern internet adres, dus geconfigureerd voor externe toegang (via Quickconnect) met port forwarding op de Ziggo router van de standaard poorten 5000 en 5001 voor DSM naar het interne adres 192.168.x.y van de NAS.
(Ik weet het, de aanbeveling is daarvoor andere poorten in te stellen op de router, maar dat maakt even voor dit verhaal niet uit.)
Recentelijk ondervind ik 'last' van het feit dat op de een of andere manier het externe adres van mijn router (84.24.x.y, Ziggo Consumer range) in (weet ik veel) lijstjes terecht is gekomen en dat onverlaten uit Rusland, Honkong, Brazilie enzovoort proberen een connectie met de NAS te maken met gebruikernamen als System, Admin, etc.
De bijbehorende IP adressen worden dan wel geblokkeerd doordat de instelling 3 failed logons in 4 minuten dit afvangt, maar het zint me toch niet.
Maar met andere poorten die voor port-forwarding zijn ingesteld zou hetzelfde (kunnen) gebeuren als er ook van port-scanning gebruik gemaakt wordt, want dan worden die ook wel gevonden. Of, als simpelweg alle poorten 'geprobeerd' worden.
Nou dacht ik die connectie pogingen m.b.v. de firewall op de NAS, dus a.h.w. in een 'eerder' stadium te kunnen ondervangen, waardoor er ook geen zichtbare terugmelding is van het bestaan van een apparaat op dat adres.
Heb al enkele topics hierover gelezen in dit forum en ben intussen aardig voorzien van groene appels uit Spanje en rode aardbeien uit (ben ik vergeten :)) en groente uit Rusland, maar ik krijg mijn, dacht ik, simpele firewall rules niet echt werkend.
Wat heb ik?
Custom Profile active - All Interfaces
Rule 1. All ports, All Protocols, Source IP (185.150.x.y), Allow
Rule 2. All Ports, All Protocols, Source Range 192.168.2.x/255.255.255.0, Allow
Rule 3. All Ports, All Protocols, Souce IP All, Deny
In de Help topics op de NAS lees ik:
"DSM Firewall will match rules according to priority. Once a rule is matched, it will be enforced and DSM Firewall will not continue matching remaining rules. If there are no rules matched, DSM Firewall will perform the default action specified in each interface."
In mijn beleving betekent deze uitspraak dat als ik vanaf 185.150.x.y met quickconnect.to/<quickconnectID> naar mijn NAS ga, dat ik volgens rule no. 1 toegang zou moeten krijgen en dat rules 2. en 3. er niet meer toe doen.
Het lijkt er echter op dat dit niet zo werkt, want ik krijg het logon scherm met de meldingen:
Cannot connect to <quickconnectID)
Please check the following settings.
-You have entered the correct QuickConnect ID.
-<quickconnectID> is powered on and connected to the Internet.
-QuickConnect relay service is enabled for <quickconnectID> (at Control Panel > QuickConnect > Advanced > Options).
Kennelijk stopt het evaluatieprocess van de firewall rules dus niet bij een match (want die is er al bij rule 1.) en geeft rule 3. dan toch de doorslag.
Kom ik vanaf een ander extern adres, dan is het resultaat hetzelfde.
Dus met rule 3. (deny all) enabled In deze situatie krijg ik vanaf een ander extern adres dat NIET expliciet genoemd staat als allowed in de rules, exact hetzelfde resultaat, wat mij doet concluderen dat die dus tegen rule 3. aanloopt.
Laat ik rule 3. weg (disabled) en kom ik vanaf dat andere extern adres (niet genoemd als allowed adres (!)) kom ik gewoon binnen.
Overigens ook van het adres genoemd in rule 1.
En als ik vanuit mijn eigen lan (192.168.2.x) de connectie maak, dan krijg ik gewoon toegang, maar misschien 'kijkt' de firewall 'kijkt' zeker niet naar de lan interfaces?
Klopt de helptekst niet, en stopt de evaluatie NIET bij de eerste match?
Is dit een gevalletje van: alles wordt ge-evalueerd en Deny gaat vóór Allow?
Snap ik het niet en doe ik iets onzinnigs? (en dat zeker een mogelijkheid!)
Ik wil eenvoudig een aantal externe adressen via Quickconnect toegang kunnen verschaffen en de rest het bos in sturen.
Er zijn zeker mensen hier die mij uit de droom kunnen helpen en weten hoe ik dit moet aanpakken.
Alvast bedankt voor jullie reacties.
Dyslexia
-
Firewall regels worden in volgorde van boven naar beneden afgewerkt. Alle regels worden doorgenomen.
Of navolgende regels verder nog effect hebben is afhankelijk van de inhoud van de voorgaande regels.
Als je met QuickConnect werkt, en je hebt slechts een beperkt aantal IP adressen die je toegang zou willen geven,
vanuit het IP bereik 185.150.x.y en je krijgt erna een foutmelding, kan ik me dat inderdaad wel voorstellen.
QuickConnect loopt namelijk via de servers van Synology. En die heb je in de Firewall regels niet opgenomen.
Dat kunnen zowel server adressen zijn in Taiwan of in bijv. USA.
Misschien tegenwoordig binnen Europa zelf (i.v.m. AVG / privacy wetgeving)?
In hoeverre QuickConnect wel of niet rekening houdt met Synology adressen zelf m.b.t. de firewall is mij eigenlijk niet bekend?
Het is in ieder geval genoeg reden tot verwarring.
Het lijkt me overzichtelijker gewoon voor die paar poorten die je wilt gebruiken de poorten door te sturen in de Ziggo router.
En enkel voor die poorten (5000 en 5001) en voor die paar externe IP-adressen toegang te geven.
Beslist niet "voor alle poorten" en protocollen (TCP en UDP), met wat je in regel 1. nu hebt ingesteld.
(En altijd een http poort 5000 verbinding automatisch laten omleiden naar https poort 5001).
Mocht het ontoereikend zijn om die externe IP adressen in een beperkte reeks vast te leggen (185.150.x.y ).
omdat er meerdere verschillende IP-nummers worden gebruikt over andere IP-bereiken.
Kun je overwegen "regio-filtering" in te stellen. Bijv. alleen IP-nummers uit Nederland toegang.
Vind je dat niet veilig genoeg kun je nog een extra twee-factor autorisatie instellen op de NAS.
Zou men een appje op een smartphone moeten installeren, wat een extra toegangscode genereert op basis van tijd.
Andere veilige methode is om extern via VPN te verbinden.
Is aan te bevelen als men bijv. vanuit een openbaar WiFi netwerk (hotel, restaurant) met thuis contact wilt leggen.
En ook voor je overige internetverkeer (dat loopt dan versleuteld via de VPN-tunnel, en pas vanuit "huis" het internet op).
Verder is blokkeren >3 keer binnen 4 minuten een slechte instelling.
Het betekent namelijk dat als je 3 keer "verkeerd inlogt", maar op dat moment niet verder gaat,
je na 4 minuten weer opnieuw 3 pogingen kunt doen. Enz.
Beter is bijv. 3 keer in te stellen voor een tijdsperiode van 24 uur (of nog langer).
Verder zou ik met deze op zichzelf krap aantal keren, voor jezelf bij benadering via het LAN,
of een vast IP adres vanaf familie of zo, een uitzondering maken (in de whitelist),
zodat jezelf niet geteisterd wordt met jezelf buiten te sluiten, als het onverhoopt verkeerd gaat.
-
Hallo Babylonia,
Wat een Super heldere toelichting.!
Toch blijf ik met een paar vragen zitten over het gedrag van de firewall, maar daar is ongetwijfeld ook een verklaring voor, die ik ff niet zie.
Dat de Quickconnect via Synology servers loopt had ik ff over het hoofd gezien ( :'(), en dat blijkt in mijn geval 'quickconnect.fr1.synology.com' te zijn.
Rule1: (enabled) Select built-in applications voor ports 5000, 5001, 80, 443, Protocol TCP, Source IP: Geolocation France, Allow
Rule2: (enabled) All ports, All protocols, All Source IP, Deny
Mijn router: externe poorten 5000, 5001, 80, 443 doorgeven naar dezelfde poorten op intern ip adres NAS, both protocols
De Quickconnect (dus via de Synology server 'quickconnect.fr1.synology.com') werkt nu vanaf extern 185.150.56.179 (Cool)
Rule2 heeft hier blijkbaar geen invloed meer op, gezien de inhoud van de voorgaande rule1.?
Maar toch wel wat 'breed bereik' naar mijn smaak.
Dan ligt de redenatie toch voor de hand dat dit ook zou moeten werken als je Rule1 verandert in:
Rule1: (enabled) All ports, All protocols, Source IP 185.150.56.179, Allow (ff voor de test all ports, all protocols)
Rule2: (enabled) Select built-in applications voor ports 5000, 5001, 80, 443, Protocol TCP, Source IP: Geolocation France, Allow
Rule3: (enabled) Select built-in applications voor ports 5000, 5001, 80, 443, Protocol TCP, Source IP subnet:192.168.178.0/24, Allow
Rule4: (enabled) All ports, All protocols, All Source IP, Deny
Quickconnect werkt nog steeds.
Vreemd genoeg krijg ik dan in de browser vanaf extern adres 185.150.56.179 wanneer ik connect op het WAN IP adres van m'n router de melding:
"This site can't be reached"
<Mijn extern IP adres> took too long to respond
Terwijl ik dan denk, Rule1 zou toch moeten opgaan, want het request komt toch af van het toegestane sender IP 185.150.56.179?
Rule 2 gaat in ieder geval niet meer op en Rule3 ook niet.
Worden er nog andere poorten gebruikt dan de poorten 5000, 5001, 80, en 443 die worden doorgegeven?
Werkend vanaf een eigen intern IP adres, als ik Rule3 disable (of hij is er niet), dan krijg ik de melding [Melding1].
Met Rules1-4 zoals hiervoor aangegeven krijg ik [Melding2]
Klik ik dan op OK, dan maakt DSM 'automagically' en volledig eigenmachtig een nieuwe Rule0 (voor het gemak) voor het interne subnet, die dan als eerste rule wordt weggezet in de lijst. (Erg behulpzaam ::)
Zie [Melding3]
Hiermeer worden effectief alle andere Rules overbodig lijkt het wel, want laat ik Rules1-4 weg/disable, dan werkt quickconnect nog steeds, interne connecties ook, maar externe connecties op basis van het externe ip adres van m'n router nog steeds niet.
Het blijft toch wat ondoorzichtig voor me, dus goede verklaringen zijn uitserst welkom.
Dank,
Dyslexia
-
Quickconnect werkt nog steeds.
Vreemd genoeg krijg ik dan in de browser vanaf extern adres 185.150.56.179 wanneer ik connect op het WAN IP adres van m'n router de melding:
"This site can't be reached"
Met wat ik begrijp in dat geval dus zonder gebruik van QuickConnect, rechtstreeks op je WAN IP-adres?
Als je bij de gebruikersinterface van de NAS wilt uitkomen (DSM), tik je in:
http://[ je eigen WAN IP adres]:5000
Als de instellingen in de NAS goed staan ingesteld, gaat de connectie vanzelf over naar een https verbinding.
Met adresregel: https://[ je eigen WAN IP adres]:5001....
Een web-server heb je waarschijnlijk niet ingesteld. Zonder intikken van een poortnummer, zou je anders daar op uitkomen.
Met die https verbinding komt er in je browser waarschijnlijk een melding dat de verbinding niet veilig zou zijn, of iets van dien aard.
Afhankelijk van de browser kun je dan een uitzondering maken.
Vond nog een oude uitleg met afbeeldingen uit een oude versie Firefox browser. Principe "nu" is hetzelfde, zie < HIER > (https://www.synology-forum.nl/ddns-extern-benaderen/graag-hulp-bij-inschakelen-https/msg201305/#msg201305)
Voor meer informatie "Help" Synology, zie < HIER > (https://www.synology.com/nl-nl/knowledgebase/DSM/tutorial/General/How_to_enable_HTTPS_and_create_a_certificate_signing_request_on_your_Synology_NAS)
-
Correct, ik wil rechtstreeks op IP adres kunnen 'filteren' in de firewall dus behoorlijk strak instellen wie wel/niet rechtstreeks op extern IP adres van de router naar de NAS kan.
En ik gebruikte al http://<router adres naar de NAS>:5000
en dat werd ook al netjes doorgezet naar 5001.
En het blijkt uit jouw post (https://www.synology-forum.nl/index.php?topic=29212.msg201305#msg201305) dat het venijn dus toch weer in de staart zat, want ik gebruikte de browser die op de externe testmachine stond, nl. Chrome.
Door de laatste opmerking daarin ben ik een andere browser gaan gebruiken.
Nadat ik in de browser settings bij Security -> Trusted Sites de gewenste uitzondering had opgeven voor mijn extern IP adres, gaf zelfs de oude Internet Explorer 11 nu de certificate warning en kon ik connecten met de NAS.
(Port forwarding van 80 en 443 zoals ik in de router had staan, bleken ook niet eens meer nodig te zijn, dus die heb ik weer fijn opgeruimd.)
Dank voor het geduld en de biezonder goede hulp.
-
In hoeverre QuickConnect wel of niet rekening houdt met Synology adressen zelf m.b.t. de firewall is mij eigenlijk niet bekend?
Het is in ieder geval genoeg reden tot verwarring.
Bij quickconnect is het de nas die een verbinding opzet met de servers van Synology. Dit is dus een uitgaande verbinding en daar kijkt de firewall niet naar.
Als je via quickconnect met de nas verbind, dan verbind je alleen met de quickconnect server. Vanaf daar ga je, via een reeds openstaande verbinding, naar de nas. Het IP van de QuickConnect server hoeft daarom niet in de firewall te staan.
-
QC kan ook samen gaan met port forwarding, dan wel eventueel regels toepassen in de FF.
-
Maar dan is het duidelijk. Als je een poort forward, ga je die natuurlijk ook in de firewall open zetten. Anders is het forwarden zinloos.
Wat ik me wel altijd afgevraagd heb, is of QC ook gebruik maakt van de forwards als je die zelf in de router instelt. (De nas heeft er dan geen weet van) Of dat het alleen gebeurd als je dit via UPnP instelt. (De nas weet dan welke poorten geforward zijn en kan dat aan de server doorgeven)
Maar QC wordt op zich overbodig als je forwards gebruikt.
-
QC ook gebruik maakt van de forwards als je die zelf in de router instelt.
Dat was voorheen wel beschreven in het Synology Blog echter, na de algemene vernieuwingen (Forum en Blog), is dat verhaal verdwenen.
Als ik de QC White Paper lees, dan komt die port forwarding (zonder UPnP) niet (meer) aan de orde echter, ik weet zeker dat op het (oude) Blog beschreven was, dat port forwarding (UPnP werd niet genoemd) i.s.m. QC sneller zou werken, maar ja, ze halen dan wel het QC model, m.b.t. het juist niet forwarden, wel onderuit.
En UPnP aan op de router willen we nu juist helemaal niet.
-
Het stond in de oude whitepaper wat explicieter, maar als je goed leest staat het er nog steeds zie dit stukje uit de whitepaper over quickconnect.
LAN/WAN Detection
When a client attempts to reach a Synology NAS using the server’s QuickConnect ID, a request is sent to Synology QuickConnect Server for the registered information of the NAS. This allows the client to obtain network information about the server to identify possible ways to connect it. The information includes the public IP, LAN IP, and NAT type among others, all of which are necessary for the link and do not compromise the security of the NAS. With the given information, the client can identify whether a direct connection with the IP or domain address can be established in LAN or WAN.
Die direct connection is dus een poort die geforward staat anders kun je geen direct connection opzetten.
Pas als dat niet lukt gaat hij proberen via de "punch hole'" methode of tenslotte de minst wenselijke via de "relay servers".
Of het echt zo is zou je moeten testen met bijvoorbeeld wireshark, maar persoonlijk denk ik dat als je quickconnect gebruikt en de "punch hole" techniek werkt je die verre boven een port forwarding moet verkiezen.
Voor wie wil lezen hier kun je de whitepaper downloaden.
https://global.download.synology.com/download/Document/WhitePaper/Synology_QuickConnect_White_Paper.pdf
-
Allen bedankt voor jullie bijdragen.
Erg verhelderend.
Ik resumeer hieronder (wellicht voor anderen op zoek naar 'Hoe') hetgeen ik (uiteindelijk) geconfigureerd en werkend heb.
Doe er je voordeel mee.
Instellingen voor connectie met NAS vanaf extern IP adres
Gewenste connectiemogelijkheid:
- alleen via http://<extern IP adres van de NAS>:5000 of
- via QuickConnect.to/<QuickConnect ID>
In de NAS:
-QuickConnect configureren, ook Relay Service etc.
-Als de router het ondersteunt kan QuickConnect zelf in de router Port Forwarding regels aanmaken voor de benodigde poorten.
(volgens de beschrijving). Voor deze techniek wordt ook wel de term "hole punching" gebruikt en daarbij worden random externe
poorten gebruikt. (vlgs. de QuickConnect Whitepaper eerder genoemd.)
Ondersteunt de router dit niet, dan zul je zelf Port Forwarding regels moeten aanbrengen voor poorten 5000 en 5001.
-External Access, DDNS configureren. (weet niet of dat echt nodig was, maar het zat me niet in de weg)
-Network, DSM Settings, Check automatische redirect 5000 naar 5001.
-Security, Firewall, Enable Firewall, nieuw profiel gemaakt met de volgende Rules:
Ik wilde expliciet op extern IP adres van je router/NAS kunnen connecten:
Rule1: Ports-All, Protocol-All, Source IP <extern IP adres externe gebruiker>, Action-Allow
Rule2: Ports-All, Protocol-All, Source IP <hele intern IP subnet>, Action-Allow
Rule3: Ports-All, Protocol-All, Source IP-All, Action-Deny
Als je alleen via QuickConnect wilt werken vervang je Rule1 door:
Rule1: Ports-(Select from List)-5000, 5001, 80, 443, Protocol-TCP, Source IP-Geolocations Germany, France, Action-Allow
NB. Zo maakt DSM zelf in voorkomend geval ook de benodigde regels, nl. Select(ed) from List
(Mijn)QuickConnect loopt via Synology servers in Frankrijk. Heb in het verleden ook wel eens connectie via Duitsland gehad,
vandaar Germany, France.
Welke Synology server gebruikt wordt, kun je 'teruglezen' in de adresregel, bijv. "<QuickConnect ID>,fr1,quickconnect.to"
Rule2 'ondervangt' notifications bij het configureren van de firewall.!
Met deze instellingen heb ik mijn gewenste resultaten kunnen bereiken.
(Hoop dat ik niks vergeten ben :o)
-
Is het advies om DDNS i.p.v. QC te gebruiken verdwenen?
-
@MMD
Ik was niet op de hoogte dat DDNS 'de aanbeveling' was, maar ik kreeg dat met mijn beschreven 'oplossing' niet werkend zónder dat ik expliciet de poorten 5000/5001 forward in m'n router.
Dan vind ik de "hole punching" methodiek van QuickConnect naar random poorten (die mijn Ziggo routertje kennelijk ondersteunt!) toch wat onvoorspelbaarder dan vaste poortnummers forwarden.
Daarnaast bevalt me de firewall-route omdat ik dan precies kan afbakenen wie wel/niet toegang heeft.
But hey, that's just me 8)
-
Wat ik me wel altijd afgevraagd heb, is of QC ook gebruik maakt van de forwards als je die zelf in de router instelt.
In het begin van mijn NAS-tijd heb ik daar wel eens mee geëxperimenteerd.
Zonder ingestelde port forwaders duurde het langer voordat je connectie had via CQ, dan met port forwarders.
-
Dan vind ik de "hole punching" methodiek van QuickConnect naar random poorten (die mijn Ziggo routertje kennelijk ondersteunt!) toch wat onvoorspelbaarder dan vaste poortnummers forwarden.
Daarnaast bevalt me de firewall-route omdat ik dan precies kan afbakenen wie wel/niet toegang heeft.
De "hole punch" methode werkt natuurlijk helemaal niet met poorten.
Een poort is alleen nodig als je van buiten naar de Nas wilt connecten.
Die "punch hole" techniek maakt gebruik van de connectie die je Nas onderhoudt met de quickconnect server en die als het ware wordt overgedragen naar de applicatie op het internet (bijvoorbeeld een browser).
Dan zijn er dus helemaal geen poorten in gebruik en dat is ook de reden waarom de firewall settings hier niet actief zijn voor inkomend verkeer.
DDNS heeft helemaal niets met dit alles te maken, dat is gewoon een methode om vanaf het internet het ipadres van je Nas altijd te kunnen vinden zelfs al krijg je een ander ipadres van je provider.
-
Is het advies om DDNS i.p.v. QC te gebruiken verdwenen?
Dat advies is erg persoonlijk.
- Vanuit veiligheid oogpunt is QC het beste omdat je geen poorten open zet. Een aanvaller moet dan alles via je QC naam doen, die hij dus moet kennen. Een simpele poortscan naar open poorten zal niet lukken.
- Qua snelheid heeft QC nadelen. Verder heeft de praktijk bewezen dat er periodiek storingen met hun servers zijn, waardoor hele regio's tijdelijk geen toegang tot hun account hebben. Bij DDNS heb ik nog nooit storingen gezien. (Wel gebruikersfouten)
- Een poort open zetten met goede firewall regels en wachtwoorden is ook gewoon veilig.
Ik heb QC zelf nog nooit geactiveerd, dus ervaring heb ik niet. Ik zie vooral zijn nadelen. Bij Synology is QC tegenwoordig de eerste keus in hun uitleg omdat dit werkt, onafhankelijk van het merk router dat gebruikt wordt. Voor hen is dit gewoon makkelijk uit te leggen aan een groot publiek dat verdere geen kennis heeft en geen handleidingen van routers wil doorspitten.
-
De "hole punch" methode werkt natuurlijk helemaal niet met poorten.
Een poort is alleen nodig als je van buiten naar de Nas wilt connecten.
With all due respect, hier ben ik het niet helemaal mee eens, Ben en wel omdat ik in de QC Whitepaper, page 4 lees:
"Hole punching works by initiating a virtual tunnel from the client to the NAS with the aid of the QuickConnect Server.
1. The NAS sends out a request to the QuickConnect Server, and keeps the hole - a random external port punched by the request on the NAT in front of the NAS - open to receive a hole punching request.
2. Similarly, the client sends out a request to the QuickConnect Server to create another hole on the NAT in front of the client."
Ik snap wel dat er een virtueel kanaal gecreëerd wordt, maar ook daarvoor heb je nog steeds een poort nodig, ...want voor zover ik mij herinner uit m'n cursus "Networking Principles" eind jaren 90, bestaat netwerk communicatie over TCP en/of UDP, adres-technisch uit een IP-adres+poortnummer, waarbij de te gebruiken poortnummers (zeker de nummers <1024, de system-poortnummers!) zijn 'gestandaardiseerd' -d.w.z. daar zijn afspraken over gemaakt!- voor specifieke services/applicaties/protocollen, zoals 80 voor HTTP, of 995 voor POP3 over TLS/SSL, of 23 voor Telnet, etc.
Deze 'afspraken' worden geregistreerd door IANA.org en in Service Name and Transport Protocol Port Number Registry (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=1) gedocumenteerd.
Maar dit gaat wellicht in het kader van het onderwerp te ver. :)
Aan de andere kant -vind ik persoonlijk- is het wel fijn als dingen duidelijk zijn.
Vriendelijke groet
-
Ik denk dat je de tekst van Synology te letterlijk neemt, maar zeker weten doe ik het ook niet.
Als er random poorten gebruikt zouden worden, dan moet er een mechanisme zijn dat die poorten in de router forward.
Als dat zou is, zou het "hole punching" mechanisme alleen werken als UPnP in de router aan zou staan.
Persoonlijk denk ik dat de sessie die opgezet wordt vanuit de Nas naar de Synology servers gewoon wordt overgedragen en gebruikt wordt.
Die sessie is opgezet vanuit de Nas zelf, dus daar is geen poort voor nodig.
-
Zonder poorten geen communicatie.
Een uitgaande verbinding kiest een random poort, in de regel boven de 1024 maar zeker niet altijd.
Beknopt gezegd, beide zijden doen een uitgaande verbinding naar de server, de server "plakt" de beide poorten als het ware aan elkaar waardoor er dan een rechtstreekse verbinding ontstaat.
Dat alles heeft inderdaad niets met UPNP van doen maar UPNP is wel één van de methoden die gebruikt wordt door QC maar dat willen we niet toch?
-
QC werkt toch ook zonder UPnP?
Hier heb ik één NAS die incidenteel QC gebruikt van maakt maar UPnP staat wel degelijk uit in mijn router.
-
QC werkt toch ook zonder UPnP?
Klopt en ook al zou het wel zo zijn, dan zou ik een melding verwachten, zoiets van: Zet UPnP aan op uw Router.
QC is immers juist om het voor de gebruiker makkelijk te maken, door juist niet in de Router te prutsen.
-
Ik heb het even nagezocht, maar het functioneert zoals @MMD uitlegde, dus zonder UPnP.
Quickconnect zet een sessie op vanuit je Nas met een random poort en omdat die vanuit de Lan kant komt zet de NAT router die poort dan open enkel voor retour verkeer vanuit de Quickconnect server van Synology en wordt er is een sessie opgezet.
Als je nu vanuit het internet bij je Nas wilt komen met behulp van QC dan komt je uit bij de QC servers van Synology, die geven jouw die sessie (met die random poort) daarna kun je dus rechtstreeks met je Nas communiceren.
Synology noemt dit in zijn whitepaper de "hole punch" methode.
-
Ik heb dit niet nagezocht maar, je noemt expliciet "NAT router", dus moet NAT dan aanstaan ?
Waarom vraag ik dat, omdat dit niet altijd het geval is en omdat niet alle Routers die optie hebben, volgens mij.
Als die optie wel aanwezig is in de Router en NAT staat uit, dan kan het toch niet zo zijn dat DSM dat voor je doet ?
Of, zou je daar een een melding over krijgen dat je toch effe zelf NAT aan moet zetten in je Router.
-
Elke router in een thuissituatie doet NAT, anders heb je geen lokaal Lan.
NAT = Network Adres Translation ofwel de vertaling van het WAN ipadres dat je van je providers krijgt naar je lokale subnet.
Alleen als je de router in Bridge mode zet doet hij geen NAT, maar dan moet je ofwel genoegen nemen met het ene ipadres dat je van je provider krijgt (plus het security risc dat daarbij hoort) ofwel je moet er een andere router achter zetten die wel NAT doet.
-
Elke router in een thuissituatie doet NAT, anders heb je geen lokaal Lan.
Althans, voor zover we het over IPv4 hebben ...
-
Wist dat ik er al eerder naar gekeken had:
https://www.synology-forum.nl/ddns-extern-benaderen/toegang-naar-nas-vanuit-internet-afhankelijk-van-provider/msg162760/#msg162760
-
Althans, voor zover we het over IPv4 hebben ...
Is er dan iemand die thuis IPv6 gebruikt en geen IPv4?
Als je dat doet ben je de bescherming die Nat brengt ook kwijt en zul je dus ofwel op al je devices een goede firewall moeten hebben ofwel een router met een goede firewall of een centrale firewall achter je router.
Volgens mij ondersteunen heel veel apparaten geen IPv6