Synology-Forum.nl
Packages => Officiële Packages => Docker / Container Manager => Topic gestart door: Nelissuh op 30 augustus 2017, 00:22:47
-
Hallo,
Gezien het gebruik van torrents in Nederland gevaarlijker wordt (Dutch Filmworks gaat in oktober illegale downloaders opsporen en laten betalen (https://tweakers.net/nieuws/128783/dutch-filmworks-gaat-in-oktober-illegale-downloaders-opsporen-en-laten-betalen.html)) is het gebruik van een VPN server voor anoniem surfen een optie.
Nu heb ik wat gelezen over VPN, en nu begrijp ik dat op de nas VPN aan of uit staat, daar is geen keuze in. Dus als ik Transmission via een VPN server torrents wil laten downloaden, dat gaat de hele NAS via deze VPN lopen, ook bijvoorbeeld de off-site backup. Klopt dat?
Zo ja, is er een mogelijkheid om Transmission in Docker te draaien, met een eigen netwerkpoort, die via een VPN het internet op gaat, gescheiden van het overige verkeer? Of stel ik nu iets onmogelijks voor? Is er een andere/betere oplossing?
-
dat gaat de hele NAS via deze VPN lopen, ook bijvoorbeeld de off-site backup. Klopt dat?
Dat klopt.
die via een VPN het internet op gaat, gescheiden van het overige verkeer?
Nee, dat kan niet, in DDSM heb je geen VPN Cliënt.
Alleen de Virtuele LAN poort heeft een eigen IP-Adres (uiteraard).
[attachimg=1]
-
in DDSM heb je geen VPN Cliënt.
TS heeft het echter over Docker. Bij Docker kan je wel een netwerk interface voor selecteren per container. Wellicht kan dit dus via de VPN lopen.
Dit heb ik alleen nog nooit geprobeerd dus zou niet weten of dat werkt. Wellicht is het te testen door een gratis, of tijdelijk, VPN account aan te maken bij een VPN-service?
-
DDSM = Docker DSM dus, ook Docker ;)
Dus, dan wordt de vraag, hoe wil je in EEN Docker Container VPN gaan opzetten, kan je b.v. voor Transmission zoiets regelen, in die Container ?
-
Dat is natuurlijk waar, mijn fout.
Gemakshalve ging ik er vanuit dat TS een Transmission Docker wil draaien en geen aparte DSM hiervoor wil opzetten.
-
TS wil ook Transmission in Docker maar, omdat ik denk, dat er dan geen mogelijkheid is om een VPN connectie op te zetten in die Container, ben ik er, gemakshalve ;), er vanuit gegaan om DSM in Docker (DDSM) te draaien, daarin Transmission te installeren en dan een VPN connectie te maken via DDSM maar, dat gaat dus niet.
-
Bedankt voor alle reacties.
Als ik transmission apart via een VPN wil laten draaien moet ik 'm met de huidige mogelijkheden van DSM dus op een ander fysiek apparaat laten draaien, bijv. een Pi (o nee, 100mbit poort belemmerd maximale snelheid) of een exta NAS.
-
Of gewoon geen docker gebruiken.
Is in mijn ogen toch een zinloze applicatie die precies hetzelfde wil bereiken wat Synology met zijn packages wil bereiken.
-
vpn moet wel werken in docker zie deze http://universalexports.tk/docker.mp4 (http://universalexports.tk/docker.mp4)
je kan het instellen en laten verbinden met externe vpn host
net getest werkt goed.
-
Docker is voor mij geen doel, en ik wil het zeker ook niet gebruiken als het niet nodig is. Ik heb nu 1 docker draaien, met headless kodi om mijn kodi database up to date te houden. Ik weet niet hoe ik dit (met de NAS) zonder docker zou moeten doen.
Mijn wens is om alleen het verkeer van Transmission via een VPN te laten lopen, en al het andere dataverkeer van de NAS niet. Ik had een (kleine) hoop dat dit via Docker/DDSM zou kunnen.
-
Ik had een foutje gemaakt in deze reactie (https://www.synology-forum.nl/docker/docker-icm-vpn-t-b-v-transmission-torrents/msg230452/#msg230452), je kunt wel degelijk een VPN Client opzetten in DDSM !
Maar , je moet denk ik wel, je 2e LAN aansluiten en die kiezen voor je DDSM, misschien dat het dan wel gaat werken.
-
Dus, 1 netwerkabel uit mijn bond van 4 gooien (ook 3 is overkill).
Dan DDSM installeren, met een virtuele NAS
Dan VPN installeren
Dan daar transmission draaien?
Ik ge er eens mee spelen!
-
Oeps: DDSM vereist een volume in btrfs-formaat voor de opslag van gegevens. Maak een nieuw btrfs-volume. Een DXx13 aanschaffen met een extra schijf stond niet in de planning :o
Edit: Ik ga mijn SSDtje maar omzetten naar BTRFS, en die gebruiken voor de DDSM.
-
Status:
- SSD opnieuw ingericht met BTRFS :thumbup:
- Bond van 4 LAN verbindingen verwijderd, nieuwe van 3 gemaakt :thumbup:
- DDSM geïnstalleerd met LAN4 als netwerkverbinding :thumbup:
- http://packages.synocommunity.com/ geprobeerd toe te voegen -> melding: ongeldige locatie :thumbdown:
- Gezocht naar mogelijkheid om Transmission te downloaden en handmatig te installeren -> niet gelukt :thumbdown:
- Download station maar geïnstalleerd. Instelmogelijkheden vallen tegen :thumbdown:
.
-
- http://packages.synocommunity.com/ geprobeerd toe te voegen -> melding: ongeldige locatie :thumbdown:
- Gezocht naar mogelijkheid om Transmission te downloaden en handmatig te installeren -> niet gelukt :thumbdown:
Nu ik dit lees, herinnerde ik mij ineens dat dit klopt, had een Ticket ingelegd vorig jaar hiervoor, was wel voor Virtual DSM maar uiteindelijk geldt dit ook voor Docker DSM.
Heb die Ticket opgezocht en zie hier: Can't see the SynoCommunity Packages in Virtual DSM. (https://github.com/SynoCommunity/spksrc/issues/2539)
Deze Ticket is wel gesloten maar, gaat volgens mij verder hier: Invalid package source location on VirtualDSM (https://github.com/SynoCommunity/spksrc/issues/2219#issuecomment-204292868) (ook gesloten) en gaat hier verder (https://github.com/SynoCommunity/spksrc/issues/2216#issuecomment-271852804).
Ik ben niet echt thuis in github en hoe dit verder te werk gaat maar, het is nog niet opgelost want, ik zie (nog) geen enkele package van de SynoCommunity in DDSM.
Maar, @DrBean kan daar wel meer over zeggen, verwacht ik. ;D
[attachimg=1]
-
Dit Topic ging verder over het zelf compileren van Transmission dus, heb ik dat deel gesplitst en verplaatst naar hier (https://www.synology-forum.nl/3rd-party-apps-integratie-in-dsm/compileren-met-spksrc/?topicseen).
-
HELP.
Status:
- NAS: 192.168.0.12
- DDSM: 192.168.0.11
- DDSM Heeft VPN verbinding via 3 Dagen versie van NordVPN
- Transmission in gecompileerde versie gedownload vanaf deze pagina: https://github.com/SynoCommunity/spksrc/issues/2866, en geïnstalleerd.
- Transmission heeft "incomplete" map in DDSM.
- Sonarr en Radarr draaien op NAS, en sturen Transmission (Torrents) aan op DDSM, en NZBGet (NewsGroups) op NAS.
- NZBGet loopt probleemloos
Wat er nu gebeurt met Transmission:
- Sonarr / Radarr geeft juiste download submap door, van waaruit deze pakketten de bestanden verder willen verplaatsen.
[attachimg=1]
- In Transmission op DDSM is de goede hoofdmap ingesteld op de NAS
[attachimg=2]
- Transmission geeft aan dat naar de goede map wordt gedownloadt
[attachimg=3]
- In File Station van DDSM zie ik dat de download na het downloaden nog in de map incomplete staat.
- In File Station van NAS zie ik dat de download na het downloaden niet in de map //192.168.0.12/downloads/complete/Radarr staat.
- Sonarr / Radarr zeurt dat hij het gedownloade bestand niet kan vinden (en dat klopt), want hij staat daar niet.
[attachimg=4]
Ik neem aan dat het een rechtenprobleem is dat Transmission op DDSM geen schrijfrechten heeft op de share op de NAS. Hoe kan ik dit voor elkaar krijgen?
Ik heb in DDSM een CIFS koppeling naar de map //192.168.0.12/downloads gemaakt, maar als ik Transmission op DDSM hier laat downloaden geeft hij de lokale mapstructuur door aan Sonarr / Radarr op de NAS, en deze klaagt dan weer dat hij deze lokale map niet kent.
Als ik in de NAS dan een CIFS koppeling naar dezelfde map wil maken kan dit niet omdat ik geen externe koppeling kan maken naar een lokale drive :o [/list]
P.S. Dat de synocommunity packages nog niet beschikbaar zijn voor DDSM vind ik wel erg lastig. Anders zou ik Radarr en Sonarr ook op de DDSM draaien, en kon er gewoon via de CIFS koppeling op de NAS gesaved worden.
-
Lukt het wel om in DDSM bestanden te plaatsen en verwijderen in de CIFS-map?
Als dat wel zo is dan licht het aan de rechten van de user waarin Transmission draait. Als dat niet zo is zou het aan de algemene rechten van CIFS kunnen liggen.
-
Ja.
Als ik een CIFS koppeling maak:
[attachimg=1]
En hier in Transmission de standaard map van maak:
[attachimg=2]
Dan downloadt Transmission naar deze map:
[attachimg=3]
En dan worden ze in tegenstelling tot downloaden naar de netwerkshare \\192.168.0.12\downloads\complete wel naar deze map verplaatst.
Maarrrrr: Dan kan Sonarr / Radarr de bestanden niet vinden, omdat dit programma van Transmission de CIFS koppeling door krijgt, die op de NAS niet bestaat.
[attachimg=4]
De truc is dus om een map te hebben waar Transmission op weg schrijft die in Sonarr / Radarr exact dezelfde naam heeft. \\192.168.0.12\downloads\complete zou een goede naam zijn, omdat deze op elk netwerkapparaat hetzelfde is. Het probleem is echter dat Transmission hier niet op weg schrijft, en ik in Transmission geen gebruiker / wachtwoord kan ingeven.
Dus ik zoek een methode waarbij:
- Of: Transmission op DDSM schrijfrechten krijgt op een netwerkshare van de NAS
- Of: Een map zowel toegankelijk is op DDSM als op de NAS, beide dezelfde naam
Is het mogelijk om van een submap uit een gedeelde map weer een gedeelde map te maken? Als dat zo is kan ik hier een CIFS map van maken op de DDSM met dezelfde naam op de NAS.
-
Waarschijnlijk zijn de rechten op de bestanden dusdanig dat sonar/radar op de NAS de bestanden niet kan lezen.
Via DSM (op de NAS) kun je een machtigingscontrole uit voeren in File Station, als je dat voor de user doet waarin sonar/radar draait kun je controleren of dat het probleem is.
-
Ik geloof niet dat dit het probleem is.
Als ik via CIFS bewaar kan Radarr / Sonarr op de NAS er niet aan omdat Transmission op de virtuele NAS draait en als locatie het lokale pad rapporteert. Die lokale map op de virtuele NAS is fysiek wel een map op dezelfde NAS, maar met een ander pad. Hierdoor zijn de bestanden onvindbaar. Het punt dat de rechten onvoldoende zijn wordt niet eens bereikt.
Als je het zou willen simuleren, dan moet je Radarr op je ene NAS installeren, en Transmission op de andere NAS. Als je dat aan het werken krijgt heb je de oplossing.
-
Daar gaat het denk ik niet mis.
Als dit zo is dan kun je in FileStation op de nas (of elders op het netwerk) de bestanden ook niet zien. Dan licht het probleem in de CIFS-koppeling en niet in Sonar, Radar of Transmission.
Zijn de bestanden in FileStation (of elders op het netwerk) wel te zien? Zo ja, dan is het denk ik toch echt een rechten-probleem.
-
De truc is dus om een map te hebben waar Transmission op weg schrijft die in Sonarr / Radarr exact dezelfde naam heeft. \\192.168.0.12\downloads\complete zou een goede naam zijn, omdat deze op elk netwerkapparaat hetzelfde is. Het probleem is echter dat Transmission hier niet op weg schrijft, en ik in Transmission geen gebruiker / wachtwoord kan ingeven.
Dus ik zoek een methode waarbij:
- Of: Transmission op DDSM schrijfrechten krijgt op een netwerkshare van de NAS
- Of: Een map zowel toegankelijk is op DDSM als op de NAS, beide dezelfde naam
Is het mogelijk om van een submap uit een gedeelde map weer een gedeelde map te maken? Als dat zo is kan ik hier een CIFS map van maken op de DDSM met dezelfde naam op de NAS.
Het werkt! Symbolic links was de oplossing!
Dus, op de NAS van de lokale map /volume1/downloads de symbolic link /volume1/torrent geven:
login as: root
root@192.168.0.12's password:
root@NAS:~# ln -s /volume1/downloads /volume1/torrent
En dan, op de DDSM de CIFS gelinkte map op de NAS /volume1/Download/CIFS dezelfde symbolic link /volume1/torrent geven:
login as: root
root@192.168.0.11's password:
root@Virtual_DS1515:~# ln -s /volume1/Download/CIFS /volume1/torrent
Dan het de CIFS map op de DDSM hetzelfde als de map op de NAS, en vinden Sonarr en Radarr de download na downloaden in de map waarin ze de download verwachten, en verplaatsen ze de download naar de definitieve map.
Ik kan nu dus Torrents downloaden via een VPN, en alle andere verbindingen naar mijn NAS zonder VPN laten lopen.
Iedereen die geholpen heeft: bedankt.
Als er mensen geïnteresseerd zijn in een samenvatting / tutorial, laat het me even weten.
-
mooi topic,
Ik heb het echter iets anders draaien, maar zelfde doel.
Ik draai ook DDSM voor torrent verkeerd, deze gekoppeld aan Bond1 (NIC 1 en NIC2), en binnen DDSM verbinding gemaakt naar mijn VPN Unlimited account.
Deze is verbonden via openVPN binnen de DDSM omgeving.
Ik vraag me echter af hoe veilig dit is, en of dit voldoende bescherming bied.. ?
In dit topic word gesproken over het koppelen van 1 fysieke netwerkkabel voor de DDSM, dus dat betekend dat ik mijn BOND uit elkaar moet halen.. ?
In de huidige situatie werkt het overigens prima, en de Quickconnect externe IP adres, geeft ook een ander WAN IP aan, deze van mijn VPN provider..
Wat vinden jullie van deze opzet.. ?
-
Ik heb zelf hier 1 van de 4 aansluitingen van mijn DS1515+ voor gebruikt, maar ik vermoed dat jouw oplossing net zo veilig is. Het torrent verkeer gaat immers over de VPN, en is daardoor afgeschermd.
Vanaf mijn switch gaat het internetverkeer immers ook over dezelfde kabel naar mijn modem/router, en van daar het internet op. Daar loopt het niet-VPN verkeer en het VPN verkeer door elkaar heen.
Ik vermoed dat mijn oplossing geen toegevoegde waar de heeft, het resulteert alleen in minder bandbreedte op mijn bond, deze is immers maar 3x 1Gbit i.p.v. 4x 1Gbit (nu is 3x 1Gbit toch al overkill voor mijn thuissituatie, maar dat terzijde).
Ik ben benieuwd naar de reacties van de netwerk experts.