PDA

Bekijk Volledige Versie : VPS opzetten voor eigen gebruik



timmy
10/12/09, 15:31
Ik heb een server in LA en 1 in Amsterdam.
Als ik op een van deze servers een VPS opzet
zal de verbinden dan sneller zijn (vanuit azie)?

Ik hoorde namelijk van een andere NLer hier
dat hij 5x snellere verbingen heeft met een VPN in de UK

(en kick daarmee gelijk het chinese propaganda cordon) :)

Beide machines draaien Centos laatste versie.

Welk pakket raden jullie mij aan?

schone gruBe

Geert-Jan
10/12/09, 15:32
Timmy,

Wat wil je nu opzetten, VPS (zoals in de titel) of VPN (zoals in je vraag)?
Voor beide blijft de verbinding toch van belang lijkt me....

timmy
10/12/09, 15:34
ik heb alleen VPN nodig...
dacht ff dat ik VPS daar voor nodig moest hebben
maar uit jou vraag lijkt het daar niet op :)

Geert-Jan
10/12/09, 16:07
Ja, maar je vraag was me niet duidelijk. Met een VPN maak je een 'verbinding' naar een server en/of VPS.
Of het dan sneller is? Hoe doe je het nu, blijven de verbindingen gelijk? Allemaal factoren die wel mee spelen....

Bamieater
10/12/09, 16:13
...
(en kick daarmee gelijk het chinese propaganda cordon) :)
...


Een klant van ons maakte ook gebruik van zijn dedicated server in China om de firewall te omzeilen en uiteindelijk was bijna zijn hele IP range geblokkeerd.

timmy
10/12/09, 16:45
Een klant van ons maakte ook gebruik van zijn dedicated server in China om de firewall te omzeilen en uiteindelijk was bijna zijn hele IP range geblokkeerd.

in china een server neer zetten is ook het laatste wat ik zal proberen.
ik vertrouw die gasten hier voor geen meter.

Heb zelf een proxy draaien... maar ook alleen voor eigen gebruik
https en wachtwoord beveiligd, directory gewijzigd in sport (het enige waarop hier geen taboe op berust). Daarmee lukt het wel.

de VPN zal ik idem zo doen

timmy
10/12/09, 16:52
Ja, maar je vraag was me niet duidelijk. Met een VPN maak je een 'verbinding' naar een server en/of VPS.
Of het dan sneller is? Hoe doe je het nu, blijven de verbindingen gelijk? Allemaal factoren die wel mee spelen....

nu gebruik ik gewoon een standaard lijn maar de lijn wordt hier dramatisch gesquezed...
wat een standaard 2mb lijn heet is hetzelfde als een 14k4 modem.
Na 10 seconden downloaden knijpen ze hem af naar 10-15kb.
Behalve met multiple downloads zoals torrents kan je snelheid redelijk benutten.
(tja.. wat moet je anders met 500milioen mede gebruikers :))
Dat betreft is Nederland walhalla.

anywayz. met de VPN verwacht ik een boel snelheid terug te pakken.

timmy
22/12/09, 10:25
heb inmiddels pptpd draaien. En de snelheid is zeker verbeterd.

Echter kan ik sommige websites nog niet benaderen. Bijvoorbeeld youtube.com
(die door de chinese overheid word geblokeerd) Maar ook een aantal site die ik zonder
de VPN wel kan benaderen.

Graag wat hulp aub.

Piwi-Web
22/12/09, 11:00
heb inmiddels pptpd draaien. En de snelheid is zeker verbeterd.

Echter kan ik sommige websites nog niet benaderen. Bijvoorbeeld youtube.com
(die door de chinese overheid word geblokeerd) Maar ook een aantal site die ik zonder
de VPN wel kan benaderen.

Graag wat hulp aub.

Zul je toch met wat meer informatie moeten komen. Wat heb je nu al geprobeerd?

timmy
22/12/09, 11:35
Zul je toch met wat meer informatie moeten komen. Wat heb je nu al geprobeerd?

de installatie procedure en wat configuratie:

rpm -ivh pptpd-1.3.4-1.rhel5.1.i386.rpm

/etc/ppp/options.pptpd

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
proxyarp
lock
nobsdcomp
novj
novjccomp
nologfd

/etc/pptpd.conf

option /etc/ppp/options.pptpd
logwtmp
localip 192.168.2.1
remoteip 192.168.2.11-15

chkconfig --level 35 pptpd on

service pptpd start

/etc/sysctl.conf

net.ipv4.ip_forward = 1

sysctl -p

Ps. hij logt ook steeds automatisch uit.

The-BosS
22/12/09, 18:20
Een vpn maakt nog altijd gebruik van de standaard dns servers, het kan dus zijn dat de sites die je wilt bezoeken op dns niveau geblokeerd worden. Je kan dus het best ook even dns settings etc controleren en indien nodig een eigen recursive dns draaien.

Een andere test die je zou kunnen proberen is bvb een ssh tunnel maken met je andere servers en kijken of dat de sites die je wilt bezoeken dan werken. Werken ze ook niet dan heeft dit waarschijnlijk ook met dns settings te maken.

timmy
23/12/09, 05:27
Een vpn maakt nog altijd gebruik van de standaard dns servers, het kan dus zijn dat de sites die je wilt bezoeken op dns niveau geblokeerd worden. Je kan dus het best ook even dns settings etc controleren en indien nodig een eigen recursive dns draaien.

Een andere test die je zou kunnen proberen is bvb een ssh tunnel maken met je andere servers en kijken of dat de sites die je wilt bezoeken dan werken. Werken ze ook niet dan heeft dit waarschijnlijk ook met dns settings te maken.

Ik heb pptp eruit gegooid en ben over gegaan op OpenVPN.
Het lijkt erop dat er wel een verbinding tot stand is. Echter YouTube kan ik niet openen.
Dat komt omdat in China (waar ik zit) dit wordt geblokeerd.

Iemand een idee hoe ik dit met OpenVPN kan omzeilen?

a.d.h.v. wat tests krijg ik het volgende:

-------------------------------
>ipconfig
Windows IP Configuration
Ethernet adapter OpenVPN_Tap:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.8.0.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . : RP614v4
IP Address. . . . . . . . . . . . : 10.0.0.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.0.0.1
-------------------------------
>ping 10.8.0.1

Pinging 10.8.0.1 with 32 bytes of data:

Reply from 10.8.0.1: bytes=32 time=642ms TTL=64
--------------------------------
#ifconfig
tap0 Link encap:Ethernet HWaddr 1A:6F:87:37:CD:F2
inet addr:10.8.0.1 Bcast:10.8.0.255 Mask:255.255.255.0
inet6 addr: fe80::186f:87ff:fe37:cdf2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:7640 (7.4 KiB)
-------------------------------
# ping 10.8.0.2
PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=128 time=324 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=128 time=322 ms
-------------------------------
#netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
xx.xx.xxx.xxx 0.0.0.0 255.255.255.128 U 0 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 xx.xx.xxx.xxx 0.0.0.0 UG 0 0 0 eth0
---------------------------------
#tcpdump -nlpi tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
07:31:51.57654 IP 10.8.0.2.netbios-dgm > 10.8.0.255.netbios-dgm: NBT UDP PACKET(138)
---------------------------------

maar met tcpdump komt er wel erg weinig data voorbij...

vipeax
23/12/09, 05:33
Gebruik je de Access Server versie met Push DNS?

timmy
23/12/09, 07:41
Gebruik je de Access Server versie met Push DNS?

Daarvan is me niets bekend.
Bind DNS heb ik op de server staan.

The-BosS
23/12/09, 18:48
Doe eens een traceroute van de webpagina die je probeert te bezoeken, dan kom je er direct al achter of deze daadwerkelijk over de vpn gaat en dat de dns server resovled naar het correcte ip adres.

DiedX
24/12/09, 09:51
Wat al een paar keer is aangegeven: zet een resolver DNS aan de Niet-China kant, en point je DNS servers in China naar het IP van je VPN-Tunnel. Hij pakt dan de resolver die vermoedelijk *WEL* alles geeft.

Overigens zou ik hier goed mee opletten: ik kan me goed voorstellen dat de Chinese overheid het hier niet mee eens is, en er zijn eerder mensen voor opgepakt. Het half-om-half gehakt is de laatste tijd wel erg goedkoop daar... (phun, deels serieus, intented)

timmy
24/12/09, 15:46
Doe eens een traceroute van de webpagina die je probeert te bezoeken, dan kom je er direct al achter of deze daadwerkelijk over de vpn gaat en dat de dns server resovled naar het correcte ip adres.

precies, en doet ie dus niet

Ward De Ridder
02/01/10, 23:56
Als je een ssh proxy opzet naar een eigen vps dan zit je in principe safe, dan is alles wat je doorstuurt beveiligd en weet zelfs de chinezen niet waar je mee bezig bent.

The-BosS
03/01/10, 05:43
Als je een ssh proxy opzet naar een eigen vps dan zit je in principe safe, dan is alles wat je doorstuurt beveiligd en weet zelfs de chinezen niet waar je mee bezig bent.

Ja en nee, je dns aanvragen gaan niet over vpn/ssh tunnels, deze worden gewoon bij de resolv servers gevraagd. Dus kunnen isp's nog altijd dns block of redirects uitvoeren en dan gaat dit ook verkeerd over de vpn/ssh tunnel. In firefox is er wel ergens een optie om verplicht de dns aanvragen ook over te tunnel te pushen.

1Ago
05/01/10, 03:01
Inderdaad.
Om toch te zorgen dat Firefox DNS aanvraagt over de SSH tunnel type je als adres "about:config".
Eventjes de waarschuwing wegklikken en je zoekt daarna op "network.proxy.socks_remote_dns". Deze waarde zet je op True en je herstart Firefox.

timmy
06/01/10, 07:57
Ja en nee, je dns aanvragen gaan niet over vpn/ssh tunnels, deze worden gewoon bij de resolv servers gevraagd. Dus kunnen isp's nog altijd dns block of redirects uitvoeren en dan gaat dit ook verkeerd over de vpn/ssh tunnel. In firefox is er wel ergens een optie om verplicht de dns aanvragen ook over te tunnel te pushen.

en hoe zit dat dan met OpenDNS.
Ik gebruik hun DNS ipv de service IP (ook om die terror chinezen buiten de deur te houden).

The-BosS
06/01/10, 11:55
en hoe zit dat dan met OpenDNS.
Ik gebruik hun DNS ipv de service IP (ook om die terror chinezen buiten de deur te houden).

Geen idee hoe jouw setup natuurlijk is dus ik geef maar oorzaken voor je probleem, maar om het even verder over dns etc te hebben. Ik ken bedrijven die zelfs als hun client pc's gebruiken maken van bvb een opendns dit toelaten maar op de firewall dit gewoon redirecten naar hun eigen dns. Kortom alles wat op de poort 53 komt wordt standaard gereroute naar hun eigen dns servers. Misschien dat je ook met zo iets te maken kan hebben. Indien je over nog een andere locatie zou beschikken kun je de zelfde instellingen daar eens testen en kijken of het wel werkt. Werkt het daar ook nog niet dan zit er iets niet juist in je instellingen, werkt het daar wel dan moet je op je oorspronkelijke locatie verder testen.