Synology-Forum.nl
Overige software => DDNS / Quick Connect / EZ-Internet / Portforwarding => Topic gestart door: Rubensky op 09 oktober 2021, 16:00:50
-
Beste,
Ik heb problemen na het toevoegen van een certificaat. Ik heb voor mijn eigen domein een certificaat voor mijn NAS aangevraagd.
nas.mijndomein.nl Daar heb ik in mijn DNS tabel op aangepast. (extern IP adres daarachter). Nu probeer ik mijn NAS door te leiden zodat ik hem via mijn domeinnaam kan benaderen.
In de router heb ik poort 80 en 443 opengezet. Alleen wordt ik nog steeds doorgeleid naar poort 5001. Als ik in mijn NAS de poorten probeer aan te passen springt hij steeds terug.
Hoe los ik dit op?
-
Ik heb het zover voor elkaar dat wanneer ik naar het domein ga dat ik dan bij de NAS uitkom. Alleen geeft hij op de een of andere manier nog altijd de verbinding als onbeveiligd weer. (dus zonder het certificaat).
Iemand enig idee hoe dit te regelen?
-
Het werkt nu, als ik naar mijn domein ga kom ik op een beveiligde verbinding met mijn NAS uit.
Wat wil ik nu nog. wat nu ook nog werkt is extern ip: poortnummer. Ik wil ervoor zorgen dat dat niet meer mogelijk is. Hoe regel ik dat?
En wat nu vervelend is dat ik veel poorten open moet hebben staan. 80,443 5000 en 5001. Eigenlijk wil ik alleen de noodzakelijke poorten open hebben staan.
-
Als ik het goed begrepen heb heb je via domein provider een subdomein aangemaakt en een DNS record toegevoegd die naar je server IP wijst? En poorten 80/443 zijn geforwarded?
Je kan het beste gebruik maken van een reverse proxy.
Op je NAS vind je die onder “Control Panel > Application Portal > Reverse Proxy”
Vul de vakjes in en wijs de externe poort van jou domeinnaam waarmee je wil verbinden (https-443) door naar de interne http poort 5000 (of wat jou nas poort is)
Vink HSTS en http/2 aan.
Je hoeft poort 5000 niet te forwarden in je router.
Onder “Control Panel > Security > Certificates” wijs je dan jou certificaat toe aan jou subdomein.
(https://uploads.tapatalk-cdn.com/20211009/545c4da48fab59f1826e62a169750edc.jpg)
-
Dat werkt. Als ik 2 regels aanmaak.
1 voor poort 80 naar 5000
2 voor poort 443 naar 5001.
-
Je hoeft maar 1 regel toe te voegen.
Bedoeling van reverse Proxy is dat je het subdomein (nas.mijndomein.nl) beveiligd via https (443) laat doorverwijzen naar een onbeveiligde interne http verbinding (xxx.xxx.xxx.xxx:5000)
Bij destination kan je bij hostname het interne IP-adres vervangen door “localhost”
-
Inmiddels werkt dat inderdaad. Vanmorgen niet. Nu probeerde ik het vanmorgen weer en werkt het wel...
Overigens heb ik wel poort 5000 veranderd in 5001. Blijkbaar duurt de doorvoer van de wijziging wat langer.
-
Je moet er alleen aan denken dat bij de Synology apps, poort 5001 de default poort is. Als je poort 443 gebruikt, moet je die expliciet toevoegen aan de url.
-
Niet als hij via het Reverse Proxy menu poort 443 doorverwijst naar 5000.
Zo is dat bij mij ingesteld.
Als ik dan naar bv nas.mijndomein.nl surf, kom ik in DSM terecht. (bij mijn domeinprovider heb ik nas.mijndomein.nl doorverwezen naar m’n public IP/DDNS )
EDIT: Heb je reply verkeerd gelezen. Ging over de apps :) Je hebt helemaal gelijk :)
-
Dat zou dan niet hoeven als ik ook poort 80 doorverwijs toch?
-
Als je in de apps enkel het IP adres of subdomein ingeeft, gaat de app er vanuit dat je wil verbinden met mijn.subdomein.nl:5000 ipv mijn.subdomein.nl:443.
Daarom moet je poort 443 dus steeds toevoegen.
(https://uploads.tapatalk-cdn.com/20211011/b89287412fd35daf2eeda0b664b64411.jpg)
Poort 80 heb je niet nodig en hoeft ook niet geforwarded worden in de router
EDIT:
Wat de reverse proxy eigenlijk "achter de schermen" doet is https://mijn.subdomein.nl omzetten naar http://xxx.xxx.xxx.xxx:5000
-
En er aan denken dat het certificaat aan een reverse proxy gekoppeld wordt en niet aan dsm. Bij 1 certificaat maakt dit niet uit. omdat die dan overal gebruikt wordt.
Ook niet als je het nieuwe certificaat als default bestempelt zal die automatisch door de r-proxy gebruikt worden, maar bij als je meerdere certificaten gebruikt, moet je hier aan denken.
Een interne r-proxy naar poort 5001 doorverwijzen is overkill. Geeft alleen onnodige belasting van de cpu omdat hij een keer extra moet coderen/decoderen. En er zal vast niemand op de cpu zelf het verkeer onderscheppen. :D
-
Het vreemde is, als ik een reverse proxy maak naar poort 5000 kan ik intern via mijn domeinnaam de NAS niet benaderen. Die ik een reverse naar poort 5001 wel.
-
Geraak je via je interne ip adres en poort 5000 in DSM?
-
Bedoeling van reverse Proxy is dat je het subdomein (nas.mijndomein.nl) beveiligd via https (443) laat doorverwijzen naar een onbeveiligde interne http verbinding (xxx.xxx.xxx.xxx:5000)
Dat lijkt me juist een onlogische doorverwijzing. Om een beveiligde connectie om te laten leiden naar een onbeveiligde.
Waarom houd je je niet aan de standaard poorten die ervoor staan in de scheiding tussen beveiligd en onbeveiligd?
80 en 5000 zijn onbeveiligde connecties.
443 en 5001 zijn beveiligde connecties.
Vandaar ook die vreemde tegenstrijdige aanvulling in je DS File app (https://www.synology-forum.nl/ddns-extern-benaderen/problemen-na-toevoegen-certificaat/msg305508/#msg305508).
-
Je kan inderdaad alles over beveiligde connecties laten lopen (als je jouw huisgenoten niet vertrouwd :) )
Maar binnen je thuisnetwerk vind ik het wat overkill…
Niet alle webservices zijn bereikbaar over https en dat lost de reverse proxy dus voor je op door https naar http om te leiden.
-
Bij een reverse proxy (RP) die naar localhost verwijst is dat niet alleen binnen je lan, maar zelfs binnen je nas. Als je bang bent dat iemand binnen je nas een onbeveiligde verbinding aftapt, dan ben je paranoïde. Want dan kunnen ze ook een printbaan verder aftappen omdat het verkeer uiteindelijk ergens in de nas onbeveiligd aanwezig is. Al was het maar om te kunnen verwerken.
Bij een RP komt het verkeer binnen met de versleuteling via het certificaat van deze RP. Vervolgens wordt het ontsleutelt. Vervolgens stuurt hij het door naar de DSM pagina. Als dat een versleutelde verbinding is, moet het weer gecodeerd worden met het certificaat dat aan DSM toegewezen is. Vervolgens moet DSM dat weer ontsleutelen.
Maar omdat het hele doorsturen naar localhost (Of het IP van de nas zelf) binnen de nas gebeurd is het paranoia om dit beveiligd te doen.
-
Het gaat er mij niet om dat je binnen je LAN een wel of niet beveiligde verbinding zou willen hebben, maar de onlogische keus van omzettingen. Precies de reden waarom in het onderhavige geval (https://www.synology-forum.nl/ddns-extern-benaderen/problemen-na-toevoegen-certificaat/msg305508/#msg305508) bij gebruik van de DS File app een "beveiligde" poort 443 toegevoegd zou moeten worden, om vervolgens een "onbeveiligde" verbinding te willen opzetten?
Dat is net zo'n gebaar als bij een autorit "buiten" de veiligheidsgordels in een auto loskoppelen om daarmee "geen veiligheidsrisico's" te lopen.
En bij parkeren van de oprit om de auto vervolgens nog net even onder de carport te zetten, wel de veiligheidsgordel vast te koppelen.
Lijkt me logischer om bij gebruik binnen het interne LAN de keus voor "HTTPS" in de DS File app uit te vinken.
En bij externe benadering wel een vinkje / activatie voor HTTPS.
-
@Babylonia , leg me toch nog eens uit waarom je dataverkeer dat je nas niet verlaat, moet encrypten en weer decrypten. Alleen omdat je het van de ene naar de andere poort doorstuurt. Ik zie daar echt geen meerwaarde in, alleen extra werk voor de CPU.
Volgens mij moet je je eerst eens verdiepen in de werking van een reverse proxy.
-
Best een leuk topic als je alleen je reverse proxy niet ingesteld krijgt, maar die na 24 uur ineens wel blijkt te werken...
Het klopt dat het overkill is om intern alles via een beveiligde verbinding te laten lopen.
-
@Babylonia , leg me toch nog eens uit waarom je dataverkeer dat je nas niet verlaat, moet encrypten en weer decrypten.
Dat is de discussie helemaal niet waar het om gaat. Dat schreef ik nu net in die voorafgaande reactie. (https://www.synology-forum.nl/ddns-extern-benaderen/problemen-na-toevoegen-certificaat/msg305532/#msg305532)
-
Daar gaat het juist wel om, maar jij verdraait de dingen in jouw reactie. Jij reageert op het opzetten van een reverse proxy. De laatste stap daarin kan speelt geheel intern in de nas af en kan dus een onbeveiligde poort zijn. Maar dat betekent niet dat je een onbeveiligde verbinding opzet.
Voor de gebruiker wordt er gewoon een beveiligde verbinding opgezet tot in de nas. Hij ziet ook alleen de https verbinding in de browser met het certificaat van de reverse proxy.. Het onbeveiligde stuk gebeurd achter de reverse proxy.
-
Kunnen we even terug naar mijn vraag? Want, daar ik wil nog iets vragen.
Op mijn PC heb ik de Drive Client draaien. Die is lokaal verbonden via mijn lokale IP adres met de NAS. Als ik in het certificaat menu mijn certificaat koppel aan de Synology Drive Service krijg ik op mijn PC steeds de melding status niet normaal. Er wordt dan ook niet gesynchroniseerd.
Zet ik de Synology Drive Server op het certificaat van Synology dan werkt een en ander wel.
Hoe kan dit?
-
Daar gaat het juist wel om, maar jij verdraait de dingen in jouw reactie.
Nee, ik verdraai niks. Maar kennelijk begrijp je helemaal niet waar ik op doel?
Er worden verwarrende poortnummers gebruikt in het toelaten van wel of geen beveiligde verbindingen.
Niets meer, niets minder !
Poortnummer 443 wordt internationaal gebruikt voor een beveiligde verbinding.
Die zou je om die reden dan ook niet moeten gebruiken voor verwijzingen naar "niet" beveiligde connecties.
Koud stromend water, wordt bij een kraan aangeduid met een "blauw" dopje / merkteken op de kraan.
Bij warm water, met een "rood" dopje / merkteken op de kraan.
Gewoon internationaal een normaal begrip voor koud en warm water. Wat ieder als zodanig gewend is te gebruiken.
Kun je voor eigen gebruik die gekleurde dopjes wel omwisselen.
Een blauw dopje voor warm water of andersom een rood dopje voor koud water.
Dat zal toch voor verwarring gaan zorgen. En in die verwarring vroeg of laat onbedoelde situaties opleveren,
omdat anderen die ermee worden geconfronteerd, niet gewend zijn aan die "verkeerde" aanduiding waar het voor staat.
Bij gebruik van connecties en poortnummers idem.
Houd je simpel aan de doorgaans gebruikte standaard afspraken waar die poortnummers voor staan.
Niets meer, niets minder.
Wil je iets doorsturen naar een onbeveiligde verbinding in die conversie met gebruik van poortnummers,
gebruik dan bijv. poort 8080 ----> naar poort 5000
Beveiligde verbinding 443 ----> naar poort 5001 (of bijv. 4443 ----> naar poort 5001 )
Dan is voor iedereen duidelijk wat er wordt bedoeld. Datgene wat @Rubensky eerder heeft opgezet < HIER > (https://www.synology-forum.nl/ddns-extern-benaderen/problemen-na-toevoegen-certificaat/msg305456/#msg305456)
Dat lijkt me de juiste aanpak.
Met wat ik begrijp op te maken in een eerdere reactie (https://www.synology-forum.nl/ddns-extern-benaderen/problemen-na-toevoegen-certificaat/msg305457/#msg305457) van @J-J wordt gesuggereerd poort 443 te gebruiken voor poort 5000 ??
-
Kunnen we even terug naar mijn vraag? Want, daar ik wil nog iets vragen.
Op mijn PC heb ik de Drive Client draaien. Die is lokaal verbonden via mijn lokale IP adres met de NAS. Als ik in het certificaat menu mijn certificaat koppel aan de Synology Drive Service krijg ik op mijn PC steeds de melding status niet normaal. Er wordt dan ook niet gesynchroniseerd.
Zet ik de Synology Drive Server op het certificaat van Synology dan werkt een en ander wel.
Hoe kan dit?
Op je PC/Mac hoef je normaal niets aan te passen in Synology Drive station.
Deze werkt via Quickconnect. Tenzij je dit niet ingesteld hebt…
-
Ik gebruik geen Quickconnect maar een eigen certificaat. Na het instellen daarvan moest ik opnieuw verbinden. En krijg ik de melding zoals ik hierboven schreef.
-
Heb je een nieuw certificaat aangemaakt voor een nieuw Synology drive subdomein? (bv drive.mijndomein.nl) Een certificaat voor het ene subdomein werkt niet voor een andere subdomein (tenzij je een ”wildcard” certificaat aanmaakt)
Kan je via de browser bij Synology Drive geraken? (via subdomein)
Als server om mee te verbinden heb je dus op je PC het subdomein voor Synology Drive station ingeven, gevolgd door poort 443
(drive.mijndomein.nl:443) veronderstel ik?
-
Niet helemaal zoals je veronderstelt. Wat ik heb gedaan is via de opties bij het certificaat (instellingen --> configureren. Daar heb ik het Synology.com certificaat vervangen voor mijn eigen certificaat.
Dat had ik dus ook gedaan voor de Synology Drive Server.
De Drive Client op mijn PC is verbonden met mijn NAS via mijn lokale 192.168.x.x IP adres. (De bewuste PC hangt in hetzelfde netwerk).
En dan krijg ik dus de melding Status niet normaal. En wordt er niet gesynchroniseerd.