Synology-Forum.nl
OS Specifieke ondersteuning => Mac OS X => Topic gestart door: Erwin1 op 18 november 2014, 19:34:51
-
Beste mensen,
Normaal gebruik ik AFP om m'n NAS te benaderen intern maar ook extern. Vanwege het feit dat dit vaak wordt geblokkeerd in andere netwerken was ik opzoek naar een alternatief. Webdav zou dan een uitkomst moeten bieden, echter loopt de finder telkens vast wanneer ik via HTTPS inlog..
Iemand met ervaringen? En eventuele oplossingen?
-
Webdav werkt prima maar helaas werkt Webdav+HTTPS niet al te best. Je zult dus (tot het Apple behaagt dit te verbeteren) je met HTTP moeten behelpen. Kan prima als je voor een goede combinatie van UserID en Wachtwoord zorgt.
-
In hoeverre gaat data dan onbeschermd over internet?
-
Niet. Als je via een hotspot inlogt, weet de hotspotbeheerder je wachtwoord (als hij wil).
-
Dat is niet zo prettig, is AFP wel afgeschermd?
-
Voor AFP, SMB, Webdav, FTP (en wat ze nog meer bedenken) gelden allemaal dezelfde regels.
Een spreekwoord zegt "Als je bang bent voor morgen dan kun je beter vandaag gaan hangen". Naar de moderne tijd vertaald: "Wil je 100% zekerheid dan 230v uit de NAS trekken en sowieso niet aan Internet hangen".
Van belang is de vraag "Is er iemand echt geïnteresseerd in jouw specifieke data?" Zo ja, zorg dan voor een goede bescherming maar bedenk als iemand perse wil dan komt hij er echt wel achter. Zo nee, dan voldoen de normale middelen.
En hotspots gebruiken is sowieso net iets als een gangbang zonder condoom en dan verbaast kijken als je er iets aan over houdt.
-
Je kunt natuurlijk wel opzoek gaan naar het veiligste ;)
Wat als je bijvoorbeeld veel gebruik maakt van hotspots :)
-
Benader je synology via vpn en gebruik dan webdav over http. Dan heb je én een beveiligde verbinding én het 'gemak' van http:-)
-
Probleem is alleen dat vpn niet wordt toegestaan op het netwerk, ik krijg daar geen vpn opgesteld :lol:
-
Probleem is alleen dat vpn niet wordt toegestaan op het netwerk, ik krijg daar geen vpn opgesteld :lol:
Tja, daar zijn goede redenen voor aan te voeren. Als ik nu nog een bedrijf runde zou ik alle niet strict zakelijk benodigde vormen ook afsluiten. Bekijk't eens vanuit de positie van het bedrijf.
-
Ik heb nog even gecheckt of het WW echt als platte tekst verstuurd wordt. In theorie zou het protocol nog iets als een MS-Chapv2 challenge kunnen gebruiken om toch het WW bij een http verbinding te coderen. Maar nee, als ik in de inlog specs (http://www.webdav.org/specs/rfc2617.html) bekijk, gaat het WW inderdaad als platte tekst door de lucht.
-
Met openvpn is het vaak mogelijk deze VPN blokering te omzeilen.
Zie:
https://www.bestvpn.com/blog/5919/how-to-hide-openvpn-traffic-an-introduction/
-
Is kennelijk een hele tour om dit om je mac book in te stellen :'(
-
Wat is een hele tour? Open vpn instellen op een MacBook is net zo makkelijk als de 2 native ondersteunde vpn opties.
Je moet gewoon de instellingen in de nas doen en daar de download button gebruiken. Dan krijg je de essentiele files op je MacBook plus een helpfile met links waar de de andere benodigde files kunt downloaden per OS.
-
Aha synology biedt download software, ik was op internet al wat dingen tegen gekomen dat je allemaal programma's hiervoor moest hebben.
Ik ga het morgen maar eens proberen.
Moet de openvpn op poort 443 ingesteld worden om succesvol op andere domeinen benadert te worden? Zoals in de link staat?
-
Neen openvpn draait standaard op poort 1194 UDP.
-
Ik was indertijd ook al druk bezig geweest met alles uit te zoeken wat er allemaal nodig was en zag die download optie ook te laat. Je krijgt dan direct al de goede cliënt certificaten en voor de Mac laten ze je, via de readme file, de Tunnelblick software installeren.
-
Neen openvpn draait standaard op poort 1194 UDP.
De vraag was niet wat standaard is, maar of je het ook op TCP poort 443 moet/kunt zetten, zoals eerder geadviseerd wordt. En op de nas kun je dat als instelling gebruiken. Nodig is het alleen als de standaard poort dichtgetimmerd is.
-
Nog een opmerking bij OpenVPN op de mac:
Normaal moet je in de config file instellen of al het verkeer via de nas moet gaan, of alleen verkeer naar je eigen netwerk.
In de helpfile staat ook:
*Remove # before "redirect-gateway" to route all client traffic (including web-traffic) through this VPN Server.
Dit klopt echter niet als je TunnelBlick als VPN cliënt gebruikt. TunnelBlick heeft een eigen instelling hiervoor die de config file overruled. De instelling zit een beetje verstop onder 'geavanceerde settings' --> "Tijdens een verbinding"
Het enige wat je zelf in de config file moet aanpassen is het invullen van je eigen URL of publieke IP.
Als je ervoor kiest om al het verkeer via de nas te laten lopen (de traagste oplossing en niet nodig om alleen nas toegang te hebben) dan kun je andere problemen krijgen. Op mijn Ziggo Ubee router stond standaard ingesteld om "fragmented packages" te blokkeren. Als je het internet verkeer via de nas laat lopen, komen er een paar bytes bij elk package bij, zodat ze boven de MTU waarde komen en ze dus in tweeën gehakt worden. Internet werkt dan niet meer. Frangmented packages in de router toelaten lost dat probleem op.
-
Ja dan zal de router ze "ompakken" in geval van IPv4.
De MTU waarde kan dacht ik evt. in de config files van server en client gewijzigd worden.
Of dat met TunnelBlick werkt weet ik echter niet.
Dan moet dat wel handmatig zoals met de URL of publieke IP.
Op de server ook of met het package Config File Editor.
-
Ja dan zal de router ze "ompakken" in geval van IPv4.
De MTU waarde kan dacht ik evt. in de config files van server en client gewijzigd worden.
Of dat met TunnelBlick werkt weet ik echter niet.
Dan moet dat wel handmatig zoals met de URL of publieke IP.
Op de server ook of met het package Config File Editor.
MTU waarde van de NAS kun je gewoon in Configuratie --> Netwerk instellen. Geen spec. package nodig.
-
Zeg ook niet dat er een package nodig is maar misschien knullig geformuleerd ;)
Kun jij in Netwerk een MTU van 1492 instellen? Ik niet n.l.
Komt bij dat de VPN Server standaard MTU=1500 ingesteld is en die kun je dan niet wijziggen in DSM.
Dat heeft betrekking op wat Briolet zegt.
Mijn provider gebruikt 1492 en ik heb dat ook zo ingesteld. (Met Config File Editor)
Ja, dat heb ik in heel mijn LAN zo ingesteld behalve de Androids, die zouden dan geroot moeten worden en dat wil ik niet.
-
Welke provider verplicht het gebruik van een specifieke MTU? Vzw is 1500 de normale/standaard waarde en 9000 als je Jumbo frames wilt hebben.
Ik had vroeger enkele apparaten op MTU=9000 staan en de rest op MTU=1500 (cq default) en dat werkt prima door elkaar.
-
Adsl/Vdsl gebruikt 1492 hier bij de Deutsche Telekom (T-Home) en dat is ook (redelijk) standaard.
9000 werkt ook wel binnen het LAN wel te verstaan.
Maar dan wel alle aangesloten apparaten anders moet het nog omgepakt worden naar 1500 en is de router er lekker druk mee en is het voordeel voor een groot deel weer weg. Tenzij het aan een switch hangt die Jumbo Frames ondersteund.
Dit is tenminste wat ik er zo`n beetje van begrepen heb.
-
MTU=9000 en MTU=1500 door elkaar werkt ook prima. Als MTU op MTU=9000 staat en je stuurt iets via internet, dan kijkt de nas wat de MTU van die verbinding is en past het daar op aan.
Dat aanpassen gebeurt nu ook omdat VPN internet content binnenkrijgt en weer doorstuurt naar de cliënt. Omdat VPN er een paar bitjes bij moet plakken weet hij dat hij boven de MTU uit komt en hakt ze in tweeën om binnen de MTU te blijven. Het creëren van gefragmenteerde pakketten is een heel legitieme optie op het internet.
Het probleem is een veiligheidsinstelling in de router om dergelijke gefragmenteerde pakketten te blokkeren omdat je met zulke gefragmenteerde pakketten ook [url=http://en.wikipedia.org/wiki/IP_fragmentation_attacks]een netwerk kunt aanvallen (http://en.wikipedia.org/wiki/IP_fragmentation) door wel het eerste pakket te sturen en daarna geheel andere pakketten. Gelukkig kun je die beveiliging uit zetten, maar die beveiliging zit er niet voor niets op, denk ik dan maar.
-
9000 werkt ook wel binnen het LAN wel te verstaan.
Maar dan wel alle aangesloten apparaten anders moet het nog omgepakt worden naar 1500 en is de router er lekker druk mee …
Nee hoor. Elke verzender overlegt met de andere partij wat de MTU moet zijn en gaat er niet overheen. Als de NAS op 9000 staat en de smartphone of router kent alleen 1500 dan wordt de MTU 1500, daar komt geen fragmentatie bij kijken. Kijk maar via Wireshark naar het verkeer, dan zie je dat duidelijk.
Dus 9000 en 1500 kun je rustig door elkaar gebruiken, als de tussenliggende switches etc maar 9000 ondersteunen. Dat is omdat alleen de eindpunten en routers een MTU afspreken en ervan uit gaan dat alles ertussen wel meegaat.
-
Haal ik nu iets door elkaar?
Ben ook geen netwerk mannetje... :)
Bij IPv6 is dat zo maar niet bij IPv4, toch?
Bij IPv6 zegt de server bij een te groot packet stuur maar een andere, want ik ga niet ompakken (hakken).
-
Vond nog een Topic van Briolet over dit onderwerp inclusief tests en bevindingen (http://www.synology-forum.nl/file-ftp-nfs-and-samba-server/jumbo-frames/). ;)