Synology-Forum.nl
Packages => Officiële Packages => VPN Server => Topic gestart door: pa3hio op 22 november 2017, 08:47:31
-
Ik heb een openVPN server in de NAS opgestart, en ingesteld, dit werkt. Ik gebruik hiervoor de standaard client versie van openVPN, om met mijn windows PC een verbinding te maken.
Tijdens de verbindings-opbouw, zie ik in het venster van de openVPN client wat rode meldingen, die betrekking hebben op de beveiliging.
Mijn vragen zijn:
- standaard gebruikt de server het UDP protocol, is TCP niet beter ?
- de codering staat default op BF-CBC, kan ik niet beter iets van AES-192 of zelfs AES-256 kiezen, en welke verificatie (nu SHA1) moet ik dan kiezen ?
Voorde duidelijkheid: de verbinding werkt, maar ik vroeg me af hoe ik de rode waarschuwingsteksten "aan moet pakken" :)
Alvast bedankt voor het mee denken.
-
TCP niet beter
TCP is niet beter maar, langzamer dan UDP.
e codering staat default op BF-CBC, kan ik niet beter iets van AES-192 of zelfs AES-256 kiezen
Ik gebruik AES-256-CBC.
welke verificatie (nu SHA1) moet ik dan kiezen ?
Ik gebruik SHA512
zie ik in het venster van de openVPN client wat rode meldingen
En wat voor een rode meldingen dan?
-
Birdy, hier kan ik wel wat mee :) De meldingen hebben betrekking op de (nu) te lage beveiligings-instellingen. Ik ga dit bekijken, en kom er op terug.
-
Even ter uitleg.
UDP is een handshake less protocol, wat inhoud dat het aan de ene kant verzonden worden en er niet gekeken wordt of het aankomt.
Dat is voor normaal verkeer alleen werkbaar op zeer betrouwbare verbindingen of voor broadcast achtig verkeer.
Echter als je een VPN gebruikt dan zorgt het VPN protocol voor een gegarandeerde aflevering en kun je binnen die VPN tunnel dus gerust UDP gebruiken.
En zoals te verwachten was, heeft UDP minder overhead dan TCP dus heeft het de voorkeur boven TCP binnen een VPN.
-
Dank je Ben, duidelijke uitleg. Waarom kies je er in het ene geval wel, en in het andere geval niet voor, om alle data via de tunnel te laten lopen? Alles door de VPN tunnel vertraagt, maar is dat dan wel veel veiliger?
-
Eigenlijk is er geen keuze, alle andere methoden dan VPN zijn een security risico.
VPN heeft enkele voordelen.
1. Het is veel veiliger en sterk encrypted.
2. Je hoeft maar een poort te forwarden en daarna is het gewoon alsof je op het lan zit.
3. Die ene poort staat onder controle van de VPN server en is dus niet(voor zover bekent) te hacken.
-
Alles door de VPN tunnel vertraagt
Dat is wat kort door de bocht, normaal gesproken mag/kan dit niet traag zijn, behalve als er slechte verbindingen ontstaan (op afstand) maar, dat heb je ook als je met andere oplossing dan VPN.
Vaak zit het tussen de up/down stream bij 1 of beide Providers.
Hoe denk je dat mensen thuis kunnen werken, met VPN natuurlijk, er is geen betere oplossing voor thuiswerkers.
Zelf werk ik ook thuis, en heb altijd een prima VPN connectie met het bedrijf.
-
Birdy, met jouw settings werkt het ook weer direct, blij mee ! Wanneer ik het thuis test, en ik verbreek de verbinding, kan ik deze niet weer direct verbinden, ik moet enkele minuten wachten, met de laptop buitenshuis heb ik dit niet, geen probleem, maar het viel me op. Dit treedt zowel op de mac, als op Windows op, maar alleens binnenshuis.
Wat is een aan te raden IP-range om te gebruiken? Ik heb maar weer de standaard van 10.8.0.1 aangehouden.
Een van de doelen is om tijdens vakantie met de Ipad, de ziggo-app te gebruiken, om TV te kijken, is voor deze toepassing het IP adres nog van belang?
-
Welke IP-range wordt gebruikt is zeker belangrijk.
Omdat men feitelijk met 3 sub-nets te maken heeft, mogen die niet met elkaar in conflict komen.
https://www.synology-forum.nl/vpn-server/beter-beveiligde-openvpn/msg135813/#msg135813
-
Ik heb mij nog nooit bezig gehouden over IP-Ranges, neem gewoon wat er standaard gegeven wordt, het is maar virtueel.
-
Toevoeging: Als je b.v. je NAS wilt aanspreken, dan gebruik je immers niet een virtueel (b.v. 10.8.0.1) maar het IP-adres van de NAS zelf of NAS-naam.
-
Maar als je daarbij op locatie onder een WiFi netwerk daar in eenzelfde standaard "normaal" LAN sub-net bereik zit, als wat je thuis ook gebruikt, heb je een conflict. Dat is het achterliggende idee van andere IP bereiken gebruiken. Omdat je er hooguit alleen thuis rekening mee zou kunnen houden (op locatie kun je niets veranderen), thuis juist "een niet standaard" IP-bereik instellen.
-
64bit block ciphers moeten vermeden worden i.v.m. SWEET32, b.v. BF-CBC.
De huidige aanbeveling vanuit OpenVPN is minimaal AES-128-CBC en SHA256.
Oplopende volgorde is:
AES-128-CBC - AES-192-CBC - AES-256-CBC
SHA1 - SHA224 - SHA256 - SHA384 - SHA512
SHA224 t/m SHA512 vallen onder SHA2.
De RSA-SHAxxx keuzes zijn hetzelfde als de bovenstaande, het is slechts een andere benaming.
TCP of UDP, reeds hierboven geschreven m.b.t. het verschil, aanbevolen is UDP.
TCP kan ook goed werken. Wanneer TCP door de tunnel gaat kan dat eventueel tot problemen leiden die hier beschreven staan: http://sites.inka.de/bigred/devel/tcp-tcp.html
Uit eigen ervaring kan ik schrijven dat SSH en SCP door een TCP tunnel niet altijd even goed werkt, zeker als de lijn/WiFi wat trager is en ping hoog.
-
Dus, ik zit nog steeds op het goede spoor (https://www.synology-forum.nl/vpn-server/openvpn-vraagjes/msg236662/#msg236662) ;)
-
Dank allen voor de leerzame antwoorden. @MMD, default stond deze op BF-CBC, maar is dus reeds aangepast.
-
Nog een vraagje waar ik niet echt antwoord op heb gehad: in de config file kun je kiezen om het hekje, Remove # before "redirect-gateway def1" to route all client traffic (including web-traffic) through this VPN Server. weg te halen, is dit aan te raden, of is het niet nodig. Wanneer ik het niet weg haal, welke data gaat er dan wel, en welke niet via de tunnel.
Waar ik aan denk: stel je wilt in het buitenland bankieren, en met wachtwoorden aan de gang gaan, zou het dan beter zijn om alles via de vpn tunnel te laten gaan?
-
# If redirect-gateway is enabled, the client will redirect it's
# default network gateway through the VPN.
# It means the VPN connection will firstly connect to the VPN Server
# and then to the internet.
# (Please refer to the manual of OpenVPN for more information.)
#redirect-gateway def1
Ik heb dit ook zo ingesteld, dus # weggehaald.
Het werkt dan net zoals je vanuit thuis zit te browsen/bankieren, het zou wat trager kunnen werken echter, ik heb er geen last van.
-
Je kunt ook twee VPN profielen instellen, eentje waarbij je alles via de VPN tunnel laat lopen, een ander alleen voor data die je van een server betrekt. Afhankelijk wat je intentie is, gebruik je het ene of het andere profiel.
-
Of het weghalen van dat # werkt, hangt ook van je OpenVPN cliënt af. b.v. Tunnelblick op de mac heeft zijn eigen settings hiervoor in het programma zelf en overruled de setting in de config file.
Ik heb dit ook zo ingesteld, dus # weggehaald.
Het werkt dan net zoals je vanuit thuis zit te browsen/bankieren, het zou wat trager kunnen werken echter, ik heb er geen last van.
Als alles via de nas loopt, kun je maximaal internetten met de uploadsnelheid van de thuissitiatie van de nas, i.p.v. de snelheid van de connectie die je huidige locatie heeft. Dat verschil kan groot zijn.
-
Ik gebruik OpenVPN op m'n Router.
-
Helemaal duidelijk mensen😊 ik gebruik idd. ook tunnelblick, dus dat moet ik even goed in de gaten houden. Bedankt weer👍
-
De instelling in Tunnelblick is om al het IPv4 verkeer door de tunnel e sturen. Eigenlijk kon ik me niet herinneren dat dit alleen voor IPv4 verkeer gold. De help geeft aan:
Route all IPv4 traffic through the VPN. When checked, a '--redirect-gateway def1' option is sent to OpenVPN, causing routing to be set up to route all IPv4 traffic through the VPN. If this is not checked, all IPv4 traffic may still be sent through the VPN because the OpenVPN configuration file may contain the option, or the option may be "pushed" from the VPN server.
Daarmee geeft hij aan dat als je dit niet instelt, hij wel de config volgt. Ik dacht dit indertijd getest te hebben voor beide situaties, maar blijkbaar wordt meer 1 kant op overuled. Maar het blijft simpeler dit in Tunnelblick zelf in te stellen omdat je daar sneller kan switchen.