Routing: VPN-Root(GER)-vServer(USA)

Thunderbyte said:
Aus den Gründen:
- Browserabhängigkeit
- Proxy wird z.B. in Flash nicht respektiert
- es gibt keine Möglichkeit, Standalone Apps über den Proxy zu jagen

eben
Click to expand...
doch ;-)
Ausgangssituation war, ich habe US-Server und deutschen Server sowie VPN zu deutschen Server.
Ziel:
Videos z.B. von Hulu zu sehen und die Steuerung der Liste zentral zu steuern und das kostenfrei.

Also ist die beschriebene Lösung doch die einzige?
 
Weißt Du was, ich habe alles gesagt und meine schon seit langem gut funktionierende Lösung geschildert. Mach doch was Du willst. Deine Lösung halte ich aus mehreren Gründen für Quatsch, aber wenn Du glücklich damit wirst, viel Erfolg. Aber dann mach halt auch mal was, lies Dich ein, fang an zu konfigurieren.
 
Latenzen hat man aber auch bei direkter Verbindung und 200 ms sind weder bei einer Shell-Sitzung noch bei einer Videokonferenz ein Problem.
Ich betreibe (aus leicht anderen Gründen ;)) etwas ähnliches zu unserer chinesischen Niederlassung (Shenzhen).
Wichtig ist, daß man nicht versucht, das mit Proxy-Software oder ähnlichen Zwischenpuffern zu lösen.

PS: Zu [post=318614]Deiner Frage[/post]:
Das hat eigentlich kaum etwas mit der OpenVPN-Konfiguration zu tun und viel mit Routing.
Weil ich den "automagischen" Mechanismen in OpenVPN sowieso etwas mißtraue, würde ich das Routing auch statisch bzw. mittels ifup/ifdows-Skripten aufsetzen - aber das ist natürlich Geschmackssache.
Der amerikanische Knoten ist dabei einfach in Standard-Konfiguration für ein Internet-Gateway mit eth0 als externem und tun0 als internem Interface.
Theoretisch reicht fa einfach eine Fritzbox oder so, aber ich kenne gerade keinen Serveranbieter, der Fritz-Boxen hostet :D
Egal, ob man die Konfiguration per Wizard oder von Hand aufsetzt - am Ende ist es immer irgendwas in der Art
Code: 
iptables -A POSTROUTING -j MASQUERADE -t nat -s ... -d ...
Der Deutsche Knoten hat einfach mehrere tun-interfaces und eine passende Routing-Tabelle, z.B.
Code: 
route add -net 199.200.48.0/22 dev tun-usa
route add -net 208.91.156.0/22 dev tun-usa
 
Whistler said:
PS: Zu [post=318614]Deiner Frage[/post]:
Der amerikanische Knoten ist dabei einfach in Standard-Konfiguration für ein Internet-Gateway mit eth0 als externem und tun0 als internem Interface.
Click to expand...

Vielen Dank für deine Hilfe!
Entschuldige bitte meine dumme Nachfrage; Ich verbinde den US-Server im VPN mit meinem DE-Server. VPN ist das gleiche wie die Clienten selbst.

DE-Server hat eth0 lo tun0
tun0 logischerweise ist OpenVPN:
inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255

Auf dem US-Server ist die Gegenseite mit 10.8.0.x z.B. 3
Wie richte ich dann, dass Routing ein? Weil Routing ist doch Interface abhängig und das VPN ist doch nur ein Interface?!
Aufsplitten in zwei VPNs finde ich unpraktisch, da man dann an den Rechnern selbst kein direktes Routing über den US-Server machen kann...
 
Das Routing läßt sich am übersichtlichsten mit Supernetzen machen.
Der US-Server hat sein eth0 und die öffentliche IP als Default-Gateway und z.B. 10.0.0.0/8 (als Maske 255.0.0.0) als zusätzliche Route via tun0.
Der DE-Server hat tun1 mit 10.8.0.3 als gateway für die "interessanten" IP-Bereiche (oben tun-usa genannt).
Die Clienten haben das VPN als Standardgateway.

Die Routing-Entscheidung läuft dann folgendermaßen ab:
Client: 208.91.157.43 (hulu.com) geht wie alles über das VPN 10.8.0.1 (Standardgateway).
DE-Server: 208.91.157.43 ist in 208.91.156.0/22 und geht deswegen an tun1 (VPN zum US-Server).
US-Server: 208.91.157.43 ist nicht in 10.0.0.0/8 und geht per NAT über das Standardgateway eth0 mit öffentlicher IP.
Rückwärts:
Der Client 10.8.0.1 ist in 10.0.0.0/8 und wird vom US-Server zum DE-Server geroutet.
10.8.0.1 ist direkt am DE-Server verbunden und wird von diesem erreicht.
hulu.com sieht wegen dem NAT nur die öffentliche IP des US-Servers und keine 10er IPs.
Vom Clienten aus zeigt ein Traceroute 10.8.0.1, 10.8.0.3, die IP des US-Servers und dann den ganz normalem Pfad.
 
Hallo und danke für diese super Erklärung,
jetzt schwebt mir immer noch eine Frage im Kopf.

Whistler said:
...und geht deswegen an tun1 (VPN zum US-Server).
...
Click to expand...

Woher habe ich tun1, weil das VPN zum US ist das gleiche wie das der Clienten liegt demnach auch auf dem gleichen Interface tun0.
Oder sollte ich dafür ein weiteres OpenVPN einrichten und dann wie beschrieben das Routing machen?

Geht es nicht, dass ich statt tun1 direkt die IP des anderes Servers angebe?
 
Last edited by a moderator:
Das müßte auch gehen, ich habe es damals nur so aufgesetzt, weil das VPN nach China völlig anders konfiguriert war als das zum Einwählen.
 
Code: 
route add -net 199.200.48.0/22 gw 10.8.0.6
?

Wie kann ich mir dafür ein gutes Script schreiben, damit ich diese Routen auf Knopfdruck einfügen und entfernen kann, sonst dürfte die Liste schnell unübersichtlich werden. Gibt es Möglichkeiten einer Route einen Kommentar oder Namen zu geben?
 
Hm, bin da gestern noch auf eine andere Herangehensweise gestoßen: http://www.unblock-us.com bietet alternative DNS Server, die auf den betreffenden Seiten andere Antworten liefern als "normal". Der Vorteil einer solchen Lösung ist, dass man keine "Zwischenstation" (US VPN Server) hat, die Bandbreite frisst. Der Nachteil ist, dass man den DNS Servern des Anbieters vertrauen muss.

Für den vorliegenden Fall könnte das jedoch eine SEHR einfache Lösung sein, denn wahrscheinlich müsste man bei Dir nichts anderes machen als die DNS Server des DE Servers zu ändern, einmal die IP Adresse auf den Server festlegen und JEDER per VPN verbundene Endnutzer hat US UND UK Zugang zu betreffenden Services (der BBC iPlayer geht auch).

Der Weg wäre dann für den Traffic nur: US oder UK Service - DE VPN Server - Endnutzer.

Ich probiere das gerade bei mir aus, einmal zentral im Router die DNS Server eintragen genügt, um JEDEM Gerät im Haus US Services zu ermöglichen. Also z.B. auch Netflix am Apple TV / iPlayer auf der Boxee Box oder Pandora als App oder am PC. (Meine Empfehlung ist übrigens ganz klar eine Boxee Box!!)
 
Last edited by a moderator:
Thunderbyte said:
Hm, bin da gestern noch auf eine andere Herangehensweise gestoßen: http://www.unblock-us.com bietet alternative DNS Server, die auf den betreffenden Seiten andere Antworten liefern als "normal". Der Vorteil einer solchen Lösung ist, dass man keine "Zwischenstation" (US VPN Server) hat, die Bandbreite frisst. Der Nachteil ist, dass man den DNS Servern des Anbieters vertrauen muss.
Click to expand...

Finde ich sehr interessant, aber wie funktioniert das den praktisch?
Die US-Seiten blocken doch, weil die Anfrage von einer DE IP kommen.
Woher der deutsche Client die IP hat (DNS-Abfrage) dürfte doch der US-Webseite egal sein?
 
http://support.unblock-us.com/customer/portal/questions/272798-how-does-your-service-work- zeigts vielleicht am Besten (siehe auch den Post mit dem Traceroute).

Der Knackpunkt ist wohl: der GeoIP Entscheidungsprozess wird per DNS beeinflußt, die eigentliche Datenübertragung nicht. Daher bekommt man, wie quasi jeder andere US/UK Bürger die Videos/Mp3s direkt vom Distributionsnetzwerk und muss sie nicht über eigene Leitungen schicken.

Funktioniert bei meinen Tests astrein, der Knackpunkt ist eher: will man dem Anbieter trauen oder nicht.
 
Würde es nicht reichen, einen US DNS einzutragen?
Also wo ist der unterschied? kann ich ja gerne auch mit meinem US-Server testen wenn mir einer ein HowTo zur Verfügung stellt...

-----------------------------

Alle können sich pingen, Client, US und DE-Server.
Ich habe nun zum testen von wieistmeineip.de folgende route eingetragen:
Code: 
route add -net 212.19.62.76 netmask 255.255.255.255 gw 10.8.0.18
--> vhost03.anw.de  10.8.0.18       255.255.255.255 UGH   0      0        0 tun0

// kann man natürlich auch mit -host machen, gibt aber die gleiche route...

und zack ist die Webseite von meinem VPN aus nicht mehr erreichbar.
Weder vom Clienten noch von VPN-Server.

Das gute ist, zu wissen das dies im VPN irgend wo weitergeleitet wird, das schlechte ist ich weiß nicht wo dran der Fehler liegt :-(
IP_Forwarding ist überall an...

Code: 
DE-Server # route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
vhost03.anw.de  10.8.0.18       255.255.255.255 UGH   0      0        0 tun0
localnet        *               255.255.255.224 U     0      0        0 eth0
10.8.0.0        10.8.0.1        255.255.255.0   UG    0      0        0 tun0
default         öfftl.IP.    0.0.0.0         UG    0      0        0 eth0

Code: 
US-Server# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.17       *               255.255.255.255 UH    0      0        0 tun0
10.8.0.0        10.8.0.17       255.255.255.0   UG    0      0        0 tun0
default         *               0.0.0.0         U     0      0        0 venet0

Beim DE-Server sieht das dann so aus:
Code: 
PING wieistmeineip.de (212.19.62.76) 56(84) bytes of data.
^C
--- wieistmeineip.de ping statistics ---
24 packets transmitted, 0 received, 100% packet loss, time 23184ms
 
Last edited by a moderator:
Firewalls sind gerade offen
ACCEPT all all

Ping kommt bei einem externen Server nur vom us-Server an nicht von client oder de-Server
Die sagen immer server not reachable...
Code: 
DE-Server
# tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
19:24:19.227714 IP 10.8.0.10 > vhost03.anw.de: ICMP echo request, id 1, seq 192, length 40
19:24:19.227751 IP 10.8.0.1 > 10.8.0.10: ICMP host vhost03.anw.de unreachable, length 68

US-Server bekommt auf nomalem Weg anfragen aber nicht wenn es um weitergeleitete Anfragen geht:
Code: 
root@vps:~# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
21:21:10.176051 IP 10.8.0.10 > 10.8.0.18: ICMP echo request, id 1, seq 166, length 40
21:21:10.176078 IP 10.8.0.18 > 10.8.0.10: ICMP echo reply, id 1, seq 166, length 40
21:21:11.178622 IP 10.8.0.10 > 10.8.0.18: ICMP echo request, id 1, seq 167, length 40
21:21:11.178653 IP 10.8.0.18 > 10.8.0.10: ICMP echo reply, id 1, seq 167, length 40
 
Last edited by a moderator:
Denk' dran, daß der US-Vserver NAT machen muß.
wieistmeineip.de kann weder mit 10.8.0.18 noch mit 10.8.0.1 etwas anfangen, die Anfragen müssen von der öffentlichen IP des Servers (die auf venet0 gebunden ist) kommen.
Das ist ja gerade der Sinn der Aktion: alle Kommunikation soll hinter der US-IP maskiert werden.
 
Um NAT einzuschalten hat bei mir folgendes funktioniert:

Bis zum nächsten Neustart aktiv (einfach in die Konsole pasten):

Code: 
# NAT einschalten (damit die Pakete zurückkommen)

iptables --table nat --append POSTROUTING --out-interface eth0 --jump MASQUERADE


--> AUTOMATISIEREN:
Code: 
sudo nano /etc/init.d/iptables
---iptables--------------------------------------
iptables --table nat --append POSTROUTING --out-interface eth0 --jump MASQUERADE
---iptables--------------------------------------
sudo chmod a+x /etc/init.d/iptables
sudo update-rc.d iptables defaults

Vorsicht: alles auf eigene Gefahr, evtl müssten Teile angepasst werden.

Super Diagnosetool: http://poptop.sourceforge.net/dox/diagnose-forwarding.phtml
 
Dachte das würde Shorewall für mich übernehmen, tut es zumindetens auf meinem de-Server:

Code: 
#
# Shorewall version 4 - Masq file
#
# For information about entries in this file, type "man shorewall-masq"
#
# The manpage is also online at
# http://www.shorewall.net/manpages/shorewall-masq.html
#
##########################################################################$
#INTERFACE              SOURCE          ADDRESS         PROTO   PORT(S) IP$

venet0                10.8.0.0/24      public.IP
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Code: 
root@vps:/home/toor# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4318 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4318 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:481548 (470.2 KiB)  TX bytes:481548 (470.2 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.18  P-t-P:10.8.0.17  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:96 errors:0 dropped:0 overruns:0 frame:0
          TX packets:109 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:7452 (7.2 KiB)  TX bytes:8460 (8.2 KiB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:31453 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36170 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3063783 (2.9 MiB)  TX bytes:5345223 (5.0 MiB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:pubIP  P-t-P:...  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

Leider ändert auch die vorgeschlagene Variante nichts.
Code: 
iptables --table nat --append POSTROUTING --out-interface venet0 --jump MASQUERADE

Das mit dem Test muss ich mir morgen noch mal zu genüge führen.
Wie gesagt, eigentlich ist das die gleiche Konfig wie auf dem dem Server wo es funktioniert.
Bisher glaube ich, dass sich das routing einfach im kreis bewegt zwische de und us server bzw. der de Server garnicht bis zum us server weiterroutet.

tcpdump -i tun0 gibt eben nichts aus :-(
 
You must log in or register to reply here.
Back
Top