Synology-Forum.nl
Packages => Officiële Packages => VPN Server => Topic gestart door: Pippin op 18 juni 2015, 00:06:12
-
Tot op heden heb ik altijd nog via UDP, op poort 1194, kunnen verbinden met de VPN server.
Voor het geval het eens gebeurt dat dit niet lukt, doordat er poorten geblokkeerd worden, wou ik graag iets achter de hand hebben.
Ik heb aan verschillende dingen gedacht tot ik gisteren op het idee kwam om twee server configuratie bestanden te maken.
Eén zoals ik nu heb via poort 1194 en extra een tweede voor TCP poort 443.
Het volgende was hoe ik de VPN server kon stoppen om de TCP poort 443 configuratie te starten. Men verliest immers de verbinding op het moment dat men de VPN server stopt.......om hem daarna weer met de nieuwe configuratie te kunnen starten, wat dan dus niet gaat.
Daar waren twee scripts voor nodig die dat allemaal doen, één om te switchen naar TCP en een tweede om later weer terug te kunnen switchen naar UDP.
Samen met de hulp van een gebruiker bij de buren is dat gelukt met de volgende twee scripts,
Van UDP naar TCP (tcp.sh):
#!/bin/sh
mv /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf.udp
mv /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf.tcp /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf
/volume1/@appstore/VPNCenter/scripts/openvpn.sh restart
Van TCP naar UDP (udp.sh):
#!/bin/sh
mv /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf.tcp
mv /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf.udp /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf
/volume1/@appstore/VPNCenter/scripts/openvpn.sh restart
Elk script hernoemt eenvoudigweg de actieve configuratie daarna hernoemt het de gewenste configuratie.
Als dat gedaan is herstart de VPN server waarna in de client de config (profiel) gewisseld kan worden.
Je hebt dus twee configuraties in /usr/syno/etc/packages/VPNCenter/openvpn staan.
1 openvpn.conf (UDP) en 1 openvpn.conf.tcp (TCP)
Om te schakelen gebruik ik JuiceSSH op Android en PuTTY op Windows.
De twee scripts heb ik staan in /volume1 met permissie 0755
De één heet tcp.sh om te switchen naar TCP en de ander heet udp.sh om te switchen naar UDP.
Om te switchen naar TCP geef je op de prompt:
sh /volume1/tcp.sh
Om te switchen naar UDP geef je op de prompt:
sh /volume1/udp.sh
-
Leuke oplossing :!:
Als ik mag aanvullen, je moet dus de standaard openvpn.conf copieeren naar openvpn.conf.tcp en daarin toevoegen, neem ik aan:
port 443
proto tcp
-
Ja, het kopieren klopt.
Op de VPN server staat de poort achter het adres (IP/DDNS)
B.v.:
111.222.111.222 443
proto tcp-server
-
Welke redenen zou je kunnen aangeven om (ad-hoc) te willen switchen van UDP naar TCP voor VPN traffic?
Dat immers UDP standaard gebruikt wordt hiervoor heeft immers een legitieme rede.
Ik ben benieuwd.
-
Het antwoord staat in de openingspost :)
"Voor het geval het eens gebeurt dat dit niet lukt, doordat er poorten geblokkeerd worden, wou ik graag iets achter de hand hebben."
-
Het enige wat niet klopt is dat het "Live" gebeurd. Dan zou het ook een onzinnige actie zijn om via VPN ingelogd, naar een ander protocol te switchen. Bij een echte "Live" switch zou ik verwachten dat je die SSH verbinding via een VPN inlog uitvoert. :D
Ik denk ook dat anderen die via VPN ingelogd zijn, eruit gegooid worden. Bij een echte "live" switch zou ik verwachten dat ze ingelogd blijven.
-
Eerlijk gezegd zat ik te wachten tot iemand zou vragen:
"Maar hoe kun je switchen als je geen verbinding krijgt via UDP?"
Dan kan dat via 2/3/4G of een ander hotspot.
Titel is aangepast.
Het switchen gebeurt trouwens wel tijdens de live VPN verbinding.
-
Tot op heden heb ik altijd nog via UDP, op een hogere poort dan 1194, kunnen verbinden met de VPN server.
Voor het geval het eens gebeurt dat dit niet lukt, doordat er poorten geblokkeerd worden, wou ik graag iets achter de hand hebben.
Leuk verhaal en mooi uitgedokterd, maar is zie de reden niet(anders dan dat het gewoon kan ;D)
UDP wordt gebruikt binnen de VPN tunnel, dus tussen de twee VPN endpoints.
Als je dus een VPN tunnel kunt opzetten kan geen enkele router die UDP stream blokeren via een port block, want die router ziet alleen die VPN.
Dit zou hooguit nuttig kunnen zijn als je daarna weer verder moet routeren en dat niet met UDP kan/wil.
Het lijkt me dat dit in een thuissituatie nooit voor zal komen..
-
Wat ik bedoel is dat als alleen poort 80 en 443 openstaat, zoals b.v. recent hier iemand op het forum die op een camping zat, ik een optie heb om te switchen van b.v. UDP 1194 naar TCP 443.
-
Aha nu snap ik het.
Je tekst is een beetje verwarrend. Je bedoelt de VPN port en niet de UDP port.
Het gaat om de VPN port en UDP of TCP maakt dan helemaal niets uit.
Je kunt je VPN net zo goed over port 433 (of 80) sturen en UDP gebruiken.
UDP heeft de voorkeur bij VPN, omdat het minder overhead heeft en omdat het ingekapselt is in het VPN protocol heb je de voordelen die TCP bied niet nodig (UDP is stateless en TCP is statefull).
-
UDP heeft de voorkeur, dat weet ik.
Ik zie nu op iana.org dat inderdaad zowel protocol UDP, TCP (en SCTP) gebruikt word voor HTTPS.
-
Je haalt een paar dingen door elkaar.
VPN is geen HTTPS, het lijkt er wel veel op maar is wat anders.
En over een VPN tunnel kun je elk willekeurig protocol gebruiken wat je wilt als je maar aan beide zijden van de tunnel iets hebt dat dat protocol begrijpt.
Voor mijn part stuur je er ipx/spx overheen als je nog een novell server zou hebben.
Onderstaand plaatje is heel verhelderend al is het van een bepaalt merk.
[attachimg=1]
-
Dat is mij allemaal duidelijk @Ben(V) :)
Het gaat mij om b.v. de camping die evt. ook protocollen blokt.
-
Camping? Dat betekend toch vakantie. Hoe is vakantie nu te rijmen met VPN? Die twee zaken zijn volgens mij incompatibel. ;D
Probeert een campingeigenaar eens echte vakantie bij zijn gasten af te dwingen en is het weer niet goed.
Voor niet-vakantie toepassing is het verhaal overigens wel zeer informatief.
-
Niet iedereen gebruikt VPN voor zakelijke doeleinden :P
Het is wat mij betreft een leuke oplossing tenzij middels DPI VPN geblokt wordt natuurlijk.
Maar ook daar zijn mogelijke oplossingen voor, zoekterm "stunnel".
-
Dat is mij allemaal duidelijk @Ben(V) :)
Het gaat mij om b.v. de camping die evt. ook protocollen blokt.
Tja het is ook mogelijk om het VPN protocol te blokkeren en alleen http en https door te laten.
Zoals ik al zei VPN is geen HTTPS.
Het is met openVpn volgens mij ook mogelijk om VPN over HTTPS op te zetten, dan zal het niet meer te blokkeren zijn (tenzij ze ook https blokkeren).
-
:lol: tegelijk. Zie mijn vorige bericht. ;)
-
Het is wat mij betreft een leuke oplossing tenzij middels DPI VPN geblokt wordt natuurlijk.
Over DPI gesproken: de aangekondigde Synology router zal ook DPI opties geven volgens hun Duitse promo filmpje. Dat maakt de techniek wel toegankelijk voor een grotere groep. :'(
-
Om het normale VPN protocol te blokken heb je helemaal geen DPI nodig.
Dat zou alleen nodig zijn als je VPN over https zou gebruiken.
Ben wel benieuwd naar die router, want je hebt nogal wat cpu power nodig wil je op volle snelheid DPI uitvoeren zonder afbreuk te doen aan de throughput performance.
De Cisco dozen die dat kunnen zijn onbetaalbaar duur.
-
@Ben(V) Interessant :)
OpenVPN gebruikt toch SSL/TLS en "pakt het in" waardoor het er net anders uit ziet?
Is het niet zo dat men packet inspection uitgevonden heeft om o.a. "ongewenst" verkeer te ontdekken/blokken?
Met een SSL/TLS tunnel, zoals stunnel (https://www.stunnel.org/index.html), wordt OpenVPN weer ingepakt waardoor het door packet inspection als normaal HTTPS verkeer gezien wordt.
Interessant is ook: xor.patch (https://github.com/clayface), obfsproxy (https://www.torproject.org/projects/obfsproxy.html.en) (een Tor project) of met een DNS tunnel (https://github.com/yarrick/iodine) waarbij die laatste wel heel erg traag is.
-
Achtergrond info over detecting van OpenVpn.
https://www.anonyproz.com/supportsuite/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=174
Met wireshark kun je OpenVpn er zo uit pikken. zie:
https://wiki.wireshark.org/OpenVPN
-
Die link stond inderdaad al onder mijn favorieten :)
-
Over DPI gesproken: de aangekondigde Synology router zal ook DPI opties geven volgens hun Duitse promo filmpje. Dat maakt de techniek wel toegankelijk voor een grotere groep. :'(
Ik neem aan dat je daarmee bedoelt dat als men dat zou instellen de mogelijkheden om een beetje "anoniem" te surfen afnemen.
Vooralsnog ben ik blij dat ik hier woon, dat is niet Nederland overigens.
-
Nee zo'n optie zou natuurlijk alleen beschikbaar zijn voor de eigenaar van die Synology router.
Het zal bedoelt zijn om te kijken of wat er binnenkomt wel bonafide is en geen hacker.
-
Ja, daar zal het inderdaad voor bedoelt zijn.
Vind het wel interessant allemaal.
Zag dat je een link naar Wireshark had toegevoegd.
Het filter OpenVPN in Wireshark zal, volgens mij, out of the box, alleen een standaard installatie van OpenVPN kunnen ontdekken, echter niet live als ik het goed lees. Maar zeker leuk om eens mee te expirimenteren.
Het kan eruit gefilterd worden, als ik het goed begrijp, door de afwijkende handshake t.o.v. normaal SSL/TLS.
Je data blijft evengoed beschermt.
Als je b.v. volgens deze handleiding (http://www.synology-forum.nl/vpn-server/beter-beveiligde-openvpn/) OpenVPN ingericht hebt, wordt het, denk ik, al een pak lastiger om het te vinden met Wireshark.
"size of the HMAC header in bytes: The default HMAC algorithm is SHA-1 which generates a 160 bit HMAC, therefore 20 bytes should be ok.
packet-id for replay protection includes optional time_t timestamp?: If the parameter --tls-auth is used, an additional packet-id for replay protection is inserted after the HMAC signature. This field can either be 4 bytes or 8 bytes including an optional time_t timestamp long. The default value is True"
De handleiding (http://www.synology-forum.nl/vpn-server/beter-beveiligde-openvpn/) gebruikt SHA2 en er zal dan een handmatig filter ingesteld moeten worden om OpenVPN te ontdekken.
Je weet echter niet wat er gebruikt wordt en ben je dus wel even bezig met het instellen van verschillende filters voordat je het kunt ontdekken.
-
Ja je kunt het vrij lastig maken om een vpn tunnel te herkennen, maar professionele aparatuur en software heeft niet zo veel moeite om het verschil tussen een ssl verbinding en een vpn tunnel te detecteren.
Grote bedrijven willen namelijk absoluut niet dat hun werknemenrs (of wie dan ook) VPN tunnels op gaan zetten en zo hun bedrijfsnetwerk aan een ander netwerk (of het open internet) koppelen.