routen erstellen

superbear

Member
Hallo,

ich bin gerade dabei einen Full-Tunnel mit OpenVPN zu erstellen.
Es soll also aller Traffic über den Server gehen, damit ich auch in unsicheren umgebungen (Cafè mit Hotspot, etc.) meine Mails über ne verschlüsselte Leitung abrufen kann.
Die Sache sieht nun so aus:

Der Client verbindet sich mit dem VPN Server und bekommt eine IP aus dem Netz 192.168.250.0.
Sagen wir fürs Bsp: 192.168.250.10.

Der Server hat die VPN-IP 192.168.250.1 (device: tap1)

Auf die anderen OpenVPN Clients kann ich ohne Probleme zugreifen, aber ich kann keine Public Server erreichen, also niemand der außerhalb des VPN's ist (z.B. google.de).
Der Traffic geht aber schon komplett über den VPN-Server, dass ist nicht das Problem.

Ich denke mal mir fehlen da ein paar routen, da ich mich nur mit routen noch nicht so auskenne, weiß ich nicht so genau was ich da wie routen muss.
Vielleicht muss man ja auch noch ne iptables Regel angeben?

Ich wäre froh wenn ihr mir ein paar Tipps geben könntet.
 
upps ja vergessen zu sagen :) stimmt ist ja nen bsd forum hier :D
jo geht um ein Debian 4.0 (ok is etwas offtopic aber die leute hier sind so schlau, da musste ich einfach fragen und vieles ist doch gleich oder?)
 
soweit ich mich entsinne brauchst du kein iptables. das ganze sollte in der server cfg von openvpn einzustellen sein. Ist zwar schon etwas länger her aber wenn du die default server config nach route durchsuchen würdest solltest du entsprechendes finden
 
ja in der config muss man einefach redirect-gateway angeben. das habe ich ja gemacht.

aber das problem ist, das mein bridge script nicht tut. ich habe also keine bridge, aber das vpn tut wunderbar nur mit dem tap device.

und jetzt muss ich ihm natürlich sagen, wohin die anfragen gehen sollen, die das tap device nicht verarbeiten kann.
 
Mh also entweder du richtest einen nat ein auf deinem vpn server zb mit iptables, falls es linux sein soll, oder du übergibst mit "push" war das glaube ich openvpn die Routen zu dem Rechner, wo sie raus sollen. Bei iptables ging das glaube ich indem man es mit -t nat -j masquerade -o <interface>
Aber schau lieber mal genau nach.
 
hmm dann habe ich mal ne allgemeine frage zu routen.
also der server sagt dem client ja schicke alle deinen traffic über mich (redirect-gateway).

Der client bekommt also die entsprechenden routen automatisch gepushed.

jetzt muss ich doch noch dafür sorgen, dass der server weiß was er mit anfragen an ips machen soll, die auf tap1 (VPN-Device) ankommen und die er nicht kennt (ips die nicht aus seinem netz stammen).

dafür müsste ich doch wenn ich das richtig verstanden habe nun einen gateway eintrag in der routing tabelle vom server für das device tap1 einrichten oder?
und damit müssten die daten dann auf eth0 weitergeleitet werden, weil von daus ja das inet erreichbar ist.
damit ich den gw einrichten kann muss ich aber vorher das net einrichten.

also ungefähr sowas:
Code:
route add -net 192.168.250.0 broadcast 192.168.250.255 netmask 255.255.255.0 tap1

Code:
route add default gw <welche ip muss hier hin> netmask <welche netmask> tap1

sehe ich das richtig?
wenn ich beim gateway die server ip des vpn servers einsetze klappt es jedenfalls nicht.
 
Schau doch mal auf deinem Client, welche default-route gesetzt ist, nachdem du dich per OpenVPN aufm Server angemeldet hast.

Wenn ich das richtig in Erinnerung habe, setzt redirect-gateway auch nur die def-route auf dem Client zum VPN-Server. Andere Routen müsstest du dann auf dem Client erstmal nicht setzen. Mach mal nen traceroute vom Client auf einen Rechner im Internet.

Sollte die def-route nach Verbindungsaufbau auf den VPN-Server zeigen, müsstest du auf diesem schaun, wo es hackt; Evtl. NAT nicht für den IP-Bereich des VPN-Clients aktiviert?

EDIT:
im ovpn howto ist für Linux mit IPTables folgendes Beispiel
iptables -t nat -A POSTROUTING -s <oVPN-Client-Netz> -o eth0 -j MASQUERADE

<oVPN-Client-Netz> == 192.168.250.0/24 in deinem Beispiel
 
Zuletzt bearbeitet:
So wie ich das sehe, scheint der Client ja schon korrekt alles an den Server weiterzureichen.

Frage ist nun also, ob der Server überhaupt für IP-Routing eingestellt ist. Ich glaube, auch bei Linux braucht es hierfür einen sysctl-Eintrag. Anschließend muss der Server seine nächste Route kennen. Das ist im Heimnetz meist der DSL-Router oder sowas. Evtl. muss der wiederum wissen, dass die IPs die der Server routet auch zurück via Server erreichbar sind. Sowas muss hin und herpingen...

Wie auch schon von anderen beschrieben, gibts hierfür die Alternative NAT, welche Deine VPN-IP hinter dem Server "versteckt".

In beiden Fällen, müsstest Du evtl. noch etwas konkreter zu Deinem Setup werden (welche Rechner wie das Internet erreichen).

Interessant ist in jedem Falle immer traceroute um herauszufinden WO die Pakete stecken bleiben.
 
also habe mal eben ein Traceroute gemacht und vorher die IPTables mit dem Befehl von codephreaker bearbeitet.

geht leider nicht aber hier der trace:
Code:
Eltons-MBP:~ matthias$ ping google.de
PING google.de (216.239.59.104): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- google.de ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Eltons-MBP:~ matthias$ traceroute google.de
traceroute: Warning: google.de has multiple addresses; using 216.239.59.104
traceroute to google.de (216.239.59.104), 64 hops max, 40 byte packets
traceroute: sendto: No route to host
 1 traceroute: wrote google.de 40 chars, ret=-1
 *traceroute: sendto: No route to host
traceroute: wrote google.de 40 chars, ret=-1
 * *
traceroute: sendto: No route to host
 2 traceroute: wrote google.de 40 chars, ret=-1
^C
Eltons-MBP:~ matthias$


So hier mal das versprochene Diagramm, ich hoffe es erklärt son bischen wie die Situation ist: Struktur-Diagramm
 
Zuletzt bearbeitet:
traceroute: sendto: No route to host

das sagt es doch schon ganz richtig. Der Rechner kennt keinen Weg zum Ziel. Da es schon bei Dir am Laptop geschiet, scheint es wohl so dass der Client das Problem hat.

Dein Client weiss also nicht wie er weiterkommt mit seinen Paketen. Ich denke mal das passiert nachdem Du die Verbindung zum VPN-Server aufbaust? Vorher noch alles wunderbar?

Mach mal ein:
Code:
netstat -r -n

Interessiert bin ich am default gateway vor und nach dem VPN-Aufbau. Eigentlich müsste er beim Traceroute zumindest Deine 250.1 bringen, also Dein VPN-Endpoint auf der anderen Seite. Bei Strato kannst Du sicher nichts an deren Routingtables ändern, so dass NAT unerlässlich werden wird, ab Deinem Server ins restliche Netz.

Ich kann hoffentlich davon ausgehen, dass Du nach dem VPN-Aufbau auf dem VPN-Server zurechtkommst, soll heissen Du kommst per ping/ssh/HTTP etc auf die interne IP des Servers (vom Client aus).

Ich habe schon ein paarmal mit IPsec und OpenVPN ähnliche Setups aufgebaut. Eigentlich nicht problematisch, wenn man mal raus hat wohin die Pakete gehen.
 
Also vor Verbindungsaufbau:
Code:
Eltons-MBP:~ matthias$ netstat -r -n   
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.250      UGSc      121     2259    en0
10.37.129/24       link#8             UCS         1        0    en2
10.37.129.3        127.0.0.1          UHS         0       11    lo0
10.37.129.255      link#8             UHLWb       2       61    en2
10.211.55/24       link#9             UCS         1        0    en3
10.211.55.5        127.0.0.1          UHS         0       12    lo0
10.211.55.255      link#9             UHLWb       3       61    en3
127                127.0.0.1          UCS         0        0    lo0
127.0.0.1          127.0.0.1          UH         12    18407    lo0
169.254            link#4             UCS         0        0    en0
192.168.1          link#4             UCS         2        0    en0
192.168.1.10       127.0.0.1          UHS         0        6    lo0
192.168.1.250      0:1a:4f:fe:10:a0   UHLW      116      170    en0   1197
192.168.1.255      link#4             UHLWb       2       61    en0

Internet6:
Destination                             Gateway                         Flags      Netif Expire
::1                                     ::1                             UH          lo0
fe80::%lo0/64                           fe80::1%lo0                     Uc          lo0
fe80::1%lo0                             link#1                          UHL         lo0
fe80::%en0/64                           link#4                          UC          en0
fe80::219:e3ff:fe39:fe14%en0            0:19:e3:39:fe:14                UHL         lo0
fe80::%en2/64                           link#8                          UC          en2
fe80::21c:42ff:fe00:0%en2               0:1c:42:0:0:0                   UHL         lo0
fe80::%en3/64                           link#9                          UC          en3
fe80::21c:42ff:fe00:1%en3               0:1c:42:0:0:1                   UHL         lo0
ff01::/32                               ::1                             U           lo0
ff02::/32                               ::1                             UC          lo0
ff02::/32                               link#4                          UC          en0
ff02::/32                               link#8                          UC          en2
ff02::/32                               link#9                          UC          en3

Nach dem Aufbau der Verbindung:
Code:
Eltons-MBP:~ matthias$ netstat -r -n
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.250.1      UGSc       15       59   tap0
10.37.129/24       link#8             UCS         1        0    en2
10.37.129.3        127.0.0.1          UHS         0       11    lo0
10.37.129.255      link#8             UHLWb       2       61    en2
10.211.55/24       link#9             UCS         1        0    en3
10.211.55.5        127.0.0.1          UHS         0       12    lo0
10.211.55.255      link#9             UHLWb       3       61    en3
85.214.116.152/32  192.168.1.250      UGSc        1        0    en0
127                127.0.0.1          UCS         0        0    lo0
127.0.0.1          127.0.0.1          UH         14    18568    lo0
169.254            link#4             UCS         0        0    en0
192.168.1          link#4             UCS         2        0    en0
192.168.1.10       127.0.0.1          UHS         0        6    lo0
192.168.1.250      0:1a:4f:fe:10:a0   UHLW        3      172    en0   1194
192.168.1.255      link#4             UHLWb       2       61    en0
192.168.250        link#10            UC          1        0   tap0
192.168.250.1      link#10            UHRLW      11        0   tap0      6

Internet6:
Destination                             Gateway                         Flags      Netif Expire
::1                                     ::1                             UH          lo0
fe80::%lo0/64                           fe80::1%lo0                     Uc          lo0
fe80::1%lo0                             link#1                          UHL         lo0
fe80::%en0/64                           link#4                          UC          en0
fe80::219:e3ff:fe39:fe14%en0            0:19:e3:39:fe:14                UHL         lo0
fe80::%en2/64                           link#8                          UC          en2
fe80::21c:42ff:fe00:0%en2               0:1c:42:0:0:0                   UHL         lo0
fe80::%en3/64                           link#9                          UC          en3
fe80::21c:42ff:fe00:1%en3               0:1c:42:0:0:1                   UHL         lo0
ff01::/32                               ::1                             U           lo0
ff02::/32                               ::1                             UC          lo0
ff02::/32                               link#4                          UC          en0
ff02::/32                               link#8                          UC          en2
ff02::/32                               link#9                          UC          en3

Wenn ich die VPN Verbindung aufbaue kommt übringes das hier im Log:
Code:
Mon 10/01/07 03:09 PM: PUSH: Received control message: 'PUSH_REPLY
Mon 10/01/07 03:09 PM: OPTIONS IMPORT: timers and/or timeouts modified
Mon 10/01/07 03:09 PM: OPTIONS IMPORT: --ifconfig/up options modified
Mon 10/01/07 03:09 PM: OPTIONS IMPORT: route options modified
Mon 10/01/07 03:09 PM: gw 192.168.1.250
Mon 10/01/07 03:09 PM: TUN/TAP device /dev/tap0 opened
Mon 10/01/07 03:09 PM: /sbin/ifconfig tap0 delete
Mon 10/01/07 03:09 PM: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Mon 10/01/07 03:09 PM: /sbin/ifconfig tap0 192.168.250.10 netmask 255.255.255.0 mtu 1500 up
Mon 10/01/07 03:09 PM: /sbin/route add -net 85.214.116.152 192.168.1.250 255.255.255.255
Mon 10/01/07 03:09 PM: /sbin/route delete -net 0.0.0.0 192.168.1.250 0.0.0.0
Mon 10/01/07 03:09 PM: /sbin/route add -net 0.0.0.0 192.168.250.1 0.0.0.0
Mon 10/01/07 03:09 PM: Initialization Sequence Completed

Ein Ping auf 192.168.250.1 geht übringes auch nicht, aber das konnte ich noch nie. Die Clients können sich untereinander erreichen, aber die Clients können nicht auf die Server Dienste zugreifen.

Mein Server tap0 Device hat aber auch keine IP Adresse vielleicht sollte ich die mal zuweisen ;)

Aber warum sollte ich bei Strato keine Möglichkeit haben die Routen zu ändern?
Das ist nen Root Server auf den ich auch Root Zugriff habe.
 
kommst Du nicht auf den Server, dann geht auch kein Routing oder sonstwas darüber. Wenn die Clients untereinander kommunizieren können, scheint es aber so als ob das VPN an sich steht. Frage ist allerdings, ob man das braucht. Muss es tap sein?

Weise dem Server auf seinem tap auch mal eine IP zu. Ich hab leider nur Erfahrung mit tun. Das iptables-Log solltest Du auch beobachten, wenn da aufwändigeres drinsteht.

Ich meinte mit Strato dein nächstes Gateway, also das Default Gw von Deinem VPN-Server. Immerhin willst Du durch den ja ins Internet.
 
hehe also nun kann ich auch den server anpingen :)
habe dem tap device einfach die vpn-server ip zugewiesen.

nur tracen kann ich google immer noch nicht.

Code:
Eltons-MBP:~ matthias$ traceroute google.de
traceroute: Warning: google.de has multiple addresses; using 216.239.59.104
traceroute to google.de (216.239.59.104), 64 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
...usw. bis 64


ach so meintest du das mit den routen :D
 
hm wenn Du auf die Dienste vom Server kommst, ist die erste Hürde ja genommen. Als Gateway ist er auch eingetragen.

Mir fällt noch das hier für den Server ein:
(http://channel.debian.de/faq/ch-confignet.html)
6.2 Quick and Dirty SNAT (aka masquerading) HOWTO

SNAT bzw. Masquerading erlaubt es mehren Rechnern, welche RFC1918- (private) IP-Adressen in einem LAN haben, über einen Router, der eine öffentliche Adresse hat Zugriff auf das Internet zu geben.

IFNAME ist das externe Interface (z.B. ippp0). Bei statischer IP des externen Interfaces MASQUERADE bitte durch SNAT ersetzen und --to-source <ip-addresse> dranhängen.

Code:
iptables -t nat -A POSTROUTING -o $IFNAME -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
Statt dem echo 1 kann man auch in /etc/network/options ip_forward auf yes setzen (schöner).

(iptables braucht einen Kernel >= 2.4)
Damit der Kernel überhaupt mit weiterzuleitenden Paketen umgeht. Dann müsste soweit iptables mit forward auch richtig umgeht, zumindest das traceroute unter 1 Deine 250.1 zeigen. Wenn es dann auch mit NAT klappt müsste es auch weitergehen.

Google brachte mich kurzerhand hierher: http://www.debian.org/doc/manuals/reference/ch-gateway.de.html. Das scheint mir noch ein bischen kompletter auf Gateway-Tuning unter Debian einzugehen.
 
yehaaa,

danke euch allen, die mir geholfen haben!

Es geht!


Aber das geht nicht:
Statt dem echo 1 kann man auch in /etc/network/options ip_forward auf yes setzen (schöner).

ich muss das mit echo machen, oder muss ich nach dem schreiben der options noch irgendwas neu starten?


Also zusammenfassung was falsch war:

tap device hatte keine ip -> nun die in der vpn.config eingetragene server ip zugewiesen

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source <root-server ip>
echo 1 > /proc/sys/net/ipv4/ip_forward

danach geht alles perfekt :D

PS: Deshalb habe ich hier gefragt, weil ich das gefühl hatte das ihr hier voll viel Ahnung habt!

Eine kurze Frage noch:

Warum steht da quick and dirty?
Sollte man das lieber anders machen mit dem NAT?
 
In den Network-Options behälst Du die Einstellungen auch beim Neustart sicher.

Bzgl. quick&dirty: Du solltest auch die Firewall sicherlich etwas komplexer betreiben, wenn es sich um einen Rootserver handelt, der möglicherweise auch noch 2-3 andere Dinge tätigt.

Achso, für den Mac fällt mir hier übrigens noch das tolle GUI Tunnelblick ein. Allerdings nur für den Betrieb, nicht fürs Konfigurieren.

Und als letztes noch: Als Port solltest Du 443 (HTTPS) verwenden. Damit kommst Du auch in vielen Hotels mit restriktivem Internetzugang raus in die weite Welt.
 
ja mit dem 443 port das die nächste sache:

s. dieser post hier: http://www.bsdforen.de/showthread.php?t=19346
wenn du da auch so nette ideen hast schreib da ruhig was zu ;) ich werde jetzt die tage mal portknocking anschaun, damit ich auch noch https auf dem server verwenden kann. aber alles dazu in dem anderen post.

ich hatte das auch schon überlegt, weil der port 443 ja offen sein muss für https aber auch nicht gefiltert werden kann ;) is ja verschlüsselt was soll man da versuchen zu filtern.

ach ja tunnelblick is super danke, den verwende ich auch :D

also macht das jetzt meine iptables firewall unsicher was ich da vorhin gemacht habe oder wie? denn das sollte ja nicht sein. kannst du mir vielleicht kurz erklären was der iptables befehl genau macht? da laufen noch viele andere daemons drauf. z.B. nen apache2 und nen svn und so.
 
Zurück
Oben