[gelöst] OpenVPN auf Rootserver

[Muldini]

Lösung: Route auf dem Server fehlte, die FB setzt diese automatisch, ein Debian Server nicht.

Dann gehts jetzt an die FB als Client

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

Hallo,

ich hoffe der Thread hier geht in Ordnung, auch wenn die FritzBox in diesem Fall "nur" den zweitrangigen Client spielt

Folgender Sachverhalt:

Mein Rootserver mit der IP 84.100.100.48 soll mein OpenVPN Gateway sein. Zu diesem sollen sich mehrere Clients aus wechselnden (privaten) Netzen verbinden (z.B. zwei Notebooks). Mein VPN Netz ist 10.0.0.0. Zusätzlich soll sich die FB als weiterer Client am Server anmelden und den gesicherten Zugang für das Netz hinter der FB (192.168.75.0) zum Server bilden.

Server Config:

port 443
proto tcp-server
mode server
dev tun
dev-node /var/tmp/tun

topology subnet
ifconfig 10.0.0.1 255.255.255.0
ifconfig-pool 10.0.0.2 10.0.0.10


Zertifikate etc. ...

mssfix
nice 1
ping 10
ping-restart 60
push "ping 15"
push "ping-restart 60"
comp-lzo

max-clients 4
verb 6
mute 50
#daemon
persist-key
persist-tun
user nobody
group nogroup

push "route 84.100.100.0 255.255.255.0"
push "route-gateway 10.0.0.1"
push "redirect-gateway"
push "topology subnet"
push "dhcp-option DNS 10.0.0.1"

float

Client Config:

Zertifikate etc. ...
dev tun
proto tcp-client
dev-node VPN
nobind
tls-client
#tls-auth ta.key
ns-cert-type server
pull
remote 84.100.100.48 443
comp-lzo
verb 4
persist-tun 
persist-key
nice 1  
ping 10
ping-restart 60

Die Verbindung klappt, ich kann vom Server (10.0.0.1) mein Notebook (10.0.0.2) und andersrum pingen. Versuche ich nun etwas hinter dem Server zu erreichen, z.B. durchs surfen, bekomme ich folgende Fehlermeldung:

MULTI: bad source address from client, packet dropped

Die gleichen configs funktionieren so wie sie sind wenn die FritzBox den Server stellt. Der einzige Unterschied den ich erkenne ist, dass die FB noch eine "interne" IP mit dem dazugehörigen Netz hat.

Jetzt kommt ihr ...

Viele Grüße

 

[MaxMuster]

Ein typisches "Multiclient"-Problem:

Auf dem Server bekommt der openvpn-Prozess zwar über das "normale" Routing alle Pakete, die er weiterverteilen soll, allerdings muss er auch noch innerhalb des VPNs wissen, welches Netz bei welchem Client ist. Dafür gibt es ein zusätzliches Routing mit dem Befehl "iroute". Der Parameter muss ins "client-config-dir" oder in einem "client-connect" Skript gesetzt werden.

Ich mache sowas mit dem ersten Weg:
In die Server-Config kommt dann z.B. ein "client-config-dir /var/ovpn/ccd" (oder wo auch immer du ein solches Verzeichnis "ccd" anlegen kannst). In dem Verzeichnis liegt dann für jeden CLient, zu dem ein Netz geroutet werden soll eine Datei die so heisst, wie der Name deines Zertifikates ist (sagen wir mal "fbox"), dann müsste die Datei /var/ovpn/ccd/fbox diesen Inhalt haben (die Routen würde ich auch da reinpacken):

ifconfig-push 10.0.0.222 10.0.0.1
iroute 192.168.75.0 255.255.255.0
push "route-gateway 10.0.0.1"

Das ist vom Inhalt her ziemlich selbsterklärend: Jedem "bekannten" Client wird so eine feste IP zugeordnet und eben speziell der iroute Eintrag gesetzt.

In der Server-Config dann noch den route-Eintrag so ergänzen:

route 192.168.75.0 255.255.255.0

Jörg

 

[Muldini]

Hallo Jörg,

danke für die Antwort, dazu eineFrage.

Im Fall der Fbox ist das Netz ja bekannt, wie mache ich das aber für meine Notebooks, die häufig in verschiedenen Netzen sind?

Viele Grüße

 

[MaxMuster]

Hab ich schon korrigiert (war falsch kopiert):
Die IP wird dann die vorgegebene "VPN-IP" 10.0.0.222, die dann nicht aus dem normal genutzen Pool (ifconfig-pool 10.0.0.2 10.0.0.10) kommt...

EDIT: Die route und iroute Einträge brauchst du nur, wenn Netze "hinter" einem Client sind. Der Part sollte ja eigentlich immer gleich bleiben (also Netz "C12" ist immer beim "Client12"). Dafür benötigt das OpenVPN nur diese Angabe, bei welchem CLient ein Netz ist. Dessen (wechselnde) offizielle IP trägt es sich beim Verbindungsaufbau ein...


EDIT2: Habe das gerade nochmal gelesen und muss nochmal zu der Fehlermeldung nachfragen: Von wo aus hast du denn den Zugriff Versucht, als der Fehler kam? Direkt von dem Rechner mit dem VPN-Client oder von einem "dahinter" befindlichen Rechner? Diese Meldung kommt eigentlich dann, wenn über eine VPN-Verbindung eine IP-Adresse ankommt, die nicht die VPN-IP ist oder die per iroute dort bekannt ist...


Jörg

 

[Muldini]

Hallo Jörg,

die Fehlermeldung erscheint, wenn ich mich direkt von meinem Notebook (Client) am Server anmelde. Das NB soll in diesem Fall nicht für dahinterliegende Clients ein Gateway darstellen sondern nur "für sich selbst sorgen".

Das Problem ist aber ja, dass es nicht wie du schreibst (Client 12 kommt immer aus Netz 12) ist, sondern dass die NBs sich entsprechend ihrem aktuellen Einsatzort in wechselnden Subnetzen liegen. Ich dachte aber (aus einer früheren Hilfestellung deinerseits), dass das Subnetz für diesen Fall auch keine Rolle spielt.

Die FB ist eigentlich mein zweiter Schritt, diese soll dann später schon "ihr Netz" versorgen, aber wie gesagt, im Moment erstmal muss das NB laufen. (Aus dem Grund, dass im Moment die FB noch mein Gateway ist, und ich erst ein neues möchte bevor die FB zum Client des Neuen wird)

Viele Grüße

 

[MaxMuster]

Moin,

das mit Client12 und C12 gilt auch nur für den Fall, dass C12 das "Netz hinter dem Client" ist (wie das 192.168.75.0 bei der FBF). In welchem Netz der Client selbst ist, ist tatsächlich egal...

Aber zurück zum Fehler: Dein NB mit 10.0.0.2 kann zwar die 10.0.0.1 erreichen, aber ein anderes Netz über die 10.0.0.1 nicht? Wie sieht denn die Routingtabelle auf dem Client aus nach der Verbindung? Solange der Client mit der 10.0.0.2 beim Server ankommt, sollte die Fehlermeldung eigentlich nicht kommen...
Ansonsten wäre mal ein Server-Log mit höherem "verb" Level davon interessant ("verb 6").

Jörg

 

[Muldini]

Genau, beim Surfen über die 10.0.0.1 durch das redirect gateway.
Die folgenden Infos/Logs sind mit den aus meinem ersten Post gezeigten configs gemacht/entstanden, denn wenn ich dich richtig verstanden habe waren für den ersten Schritt (direkte NB Verbindung) keine Änderungen notwendig?

Routingtabelle auf dem Client, sieht für mich OK aus:

route print

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0         10.0.0.1        10.0.0.2       1
         10.0.0.0    255.255.255.0         10.0.0.2        10.0.0.2       30
         10.0.0.2  255.255.255.255        127.0.0.1       127.0.0.1       30
   10.255.255.255  255.255.255.255         10.0.0.2        10.0.0.2       30
     84.100.100.0    255.255.255.0         10.0.0.1        10.0.0.2       1
   84.100.100.48  255.255.255.255      192.168.0.1   192.168.0.170       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0    255.255.255.0    192.168.0.170   192.168.0.170       20
    192.168.0.170  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.0.255  255.255.255.255    192.168.0.170   192.168.0.170       20
        224.0.0.0        240.0.0.0         10.0.0.2        10.0.0.2       30
        224.0.0.0        240.0.0.0    192.168.0.170   192.168.0.170       20
  255.255.255.255  255.255.255.255         10.0.0.2        10.0.0.2       1
  255.255.255.255  255.255.255.255    192.168.0.170   192.168.0.170       1
Standardgateway:          10.0.0.1
===========================================================================
Ständige Routen:
  Keine

Im Moment befindet sich das Notebook im 192.168.0.0/24 Netz.

Server log mit verb 6 einer Verbindung:

Fri Nov 28 09:36:00 2008 us=621920 217.231.XXX.XXX:55798 [notebook] Peer Connection Initiated with 217.231.XXX.XXX:55798
Fri Nov 28 09:36:00 2008 us=622005 notebook/217.231.XXX.XXX:55798 MULTI: Learn: 10.0.0.2 -> notebook/217.231.XXX.XXX:55798
Fri Nov 28 09:36:00 2008 us=622038 notebook/217.231.XXX.XXX:55798 MULTI: primary virtual IP for notebook/217.231.XXX.XXX:55798: 10.0.0.2
Fri Nov 28 09:36:01 2008 us=753871 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [104] from 217.231.XXX.XXX:55798: P_CONTROL_V1 kid=0 [ ] pid=34 DATA len=90
Fri Nov 28 09:36:01 2008 us=754009 notebook/217.231.XXX.XXX:55798 PUSH: Received control message: 'PUSH_REQUEST'
Fri Nov 28 09:36:01 2008 us=754070 notebook/217.231.XXX.XXX:55798 SENT CONTROL [notebook]: 'PUSH_REPLY,ping 15,ping-restart 60,route 84.100.100.0 255.255.255.0,route-gateway 10.0.0.1,redirect-gateway,topology subnet,dhcp-option DNS 10.0.0.1,ifconfig 10.0.0.2 255.255.255.0' (status=1)
Fri Nov 28 09:36:01 2008 us=754121 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER WRITE [22] to 217.231.XXX.XXX:55798: P_ACK_V1 kid=0 [ 34 ]
Fri Nov 28 09:36:01 2008 us=754173 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER WRITE [114] to 217.231.XXX.XXX:55798: P_CONTROL_V1 kid=0 [ ] pid=37 DATA len=100
Fri Nov 28 09:36:01 2008 us=754214 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER WRITE [114] to 217.231.XXX.XXX:55798: P_CONTROL_V1 kid=0 [ ] pid=38 DATA len=100
Fri Nov 28 09:36:01 2008 us=754254 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER WRITE [64] to 217.231.XXX.XXX:55798: P_CONTROL_V1 kid=0 [ ] pid=39 DATA len=50
Fri Nov 28 09:36:02 2008 us=66796 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [22] from 217.231.XXX.XXX:55798: P_ACK_V1 kid=0 [ 37 ]
Fri Nov 28 09:36:02 2008 us=159336 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [26] from 217.231.XXX.XXX:55798: P_ACK_V1 kid=0 [ 38 39 ]
Fri Nov 28 09:36:11 2008 us=166508 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER WRITE [69] to 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=68
Fri Nov 28 09:36:11 2008 us=190915 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:11 2008 us=190986 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:11 2008 us=596180 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [85] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=84
Fri Nov 28 09:36:11 2008 us=596313 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:11 2008 us=659781 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:11 2008 us=659904 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:12 2008 us=436418 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [85] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=84
Fri Nov 28 09:36:12 2008 us=436532 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:12 2008 us=664195 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:12 2008 us=664319 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:14 2008 us=116404 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [85] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=84
Fri Nov 28 09:36:14 2008 us=116521 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:14 2008 us=678401 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:14 2008 us=678517 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:16 2008 us=692275 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:16 2008 us=692389 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:17 2008 us=476480 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [85] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=84
Fri Nov 28 09:36:17 2008 us=476601 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:18 2008 us=708903 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:18 2008 us=709002 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:21 2008 us=846352 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER WRITE [69] to 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=68
Fri Nov 28 09:36:22 2008 us=736941 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:22 2008 us=737052 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:24 2008 us=197202 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [85] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=84
Fri Nov 28 09:36:24 2008 us=197313 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:30 2008 us=694957 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER READ [133] from 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=132
Fri Nov 28 09:36:30 2008 us=695059 notebook/217.231.XXX.XXX:55798 MULTI: bad source address from client [192.168.0.170], packet dropped
Fri Nov 28 09:36:31 2008 us=748296 notebook/217.231.XXX.XXX:55798 TCPv4_SERVER WRITE [69] to 217.231.XXX.XXX:55798: P_DATA_V1 kid=0 DATA len=68
Fri Nov 28 09:36:37 2008 us=15338 notebook/217.231.XXX.XXX:55798 Connection reset, restarting [-1]
Fri Nov 28 09:36:37 2008 us=15466 notebook/217.231.XXX.XXX:55798 SIGUSR1[soft,connection-reset] received, client-instance restarting
Fri Nov 28 09:36:37 2008 us=15673 TCP/UDP: Closing socket

Es scheint also als würden die Pakete von meiner "internen Netz IP" kommen, statt von der VPN IP 10.0.0.2?

Viele Grüße

 

[MaxMuster]

Also "eigentlich" scheint deine Config so richtig. Aber aus welchem Grund auch immer nutzt der Client als Absende-IP nicht die VPN-IP sondern die LAN-IP, was natürlich eigentlich falsch ist. Sowas kann z.B. bei Microsoft-Protokollen (Windows Freigaben und sowas) auftreten, beim "normalen" Routing aber eigentlich nicht.

Geht denn der Zugriff über die "Eingabeauffoderung", also z.B. ein ping www.google.de oder sowas? Könntest du einen anderen Browser testen, oder evt. einen anderen (neueren) OpenVPN Client?

Jörg

 

[Muldini]

Habe mal alle Freigaben deaktiviert, bringt aber keine Änderung. Ein ping klappt auch nicht (Zeitüberschreitung ...). Client sowie Server sind schon rc15.

 

[MaxMuster]

Kriegst du beim Ping denn eine IP für den Namen?

Sonst probier doch bitte mal: "tracert -d 74.125.43.99"

Jörg

 

[Muldini]

C:\Dokumente und Einstellungen\>tracert -d 74.125.43.99

Routenverfolgung zu 74.125.43.99 über maximal 30 Abschnitte

  1    65 ms    73 ms    73 ms  10.0.0.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *     
C:\Dokumente und Einstellungen\>tracert -d google.de

Routenverfolgung zu google.de [66.249.93.104]  über maximal 30 Abschnitte:

  1    65 ms    74 ms    66 ms  10.0.0.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *

C:\Dokumente und Einstellungen\>nslookup google.de
*** Der Servername für die Adresse 10.0.0.1 konnte nicht gefunden werden:
No response from server
Server:  DNS-Server
Address:  192.168.0.3

Nicht autorisierte Antwort:
Name:    google.de
Addresses:  216.239.59.104, 66.249.93.104, 72.14.221.104

 

[MaxMuster]

Das sieht doch erstmal ganz o.k. aus: Du kriegst eine Antwort vom Server!
Hast du denn auf dem Server auch die benötigte NAT eingerichtet, so dass die Adressen aus dem 10.0.0.0-er Netz auf dem Weg ins Internet "genattet" werden?

Jörg

 

[Muldini]

Da habe ich auch von damals in Erinnerung, dass du sagtest "der Server wüsste über seine Netze bescheid". Hintergrund war damals ob die FB, die sich auch ins Inet einwählt eine Route braucht oder nicht, eine andere FB hinter der "DSL FB" bräuchte unbedingt eine.

Lange Rede kurzer Sinn, ich hab nur generell routing auf dem Server aktiviert, eine spezielle Route nicht. Kann ich das über die config machen?

 

[MaxMuster]

Klar, der weiß über seine Netze Bescheid.
Aber wenn du z.B. surfen willst, "verlässt" du ja den Server. Und kein Gerät im Internet weiß darüber Bescheid, dass deine "VPN-IP" 10.0.0.2 über den Root-Server zu erreichen ist.
Die Fritzbox macht "automatisch" eine NAT, wenn eine interne IP ins Internet geht, so dass im Internet nur die öffentliche IP der Box sichtbar ist.
Bei deinem Rootserver musst du das von Hand erledigen, z.B. mit iptables...

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE

für "eth0" halt dein Interface ins Internet einsetzen


Jörg

 

[Muldini]

Ich hatte gehofft da komm ich drum rum, denn:

modprobe ipt_state
FATAL: Could not load /lib/modules/2.6.18-12-fza-686-bigmem/modules.dep: No such file or directory

und ich kann (darf) den Kernel nicht neu kompilieren.

Gibts dafür eine Alternative?

 

[MaxMuster]

Fällt mir auf Anhieb nichts ein. Du musst NAT machen, und dabei wirst du um eine Kernel-Unterstützung nicht herum kommen.
Einzige Alternative wäre m.E. ein Proxy auf dem Rootserver, über den du dann zumindest Surfen kannst...

Jörg

 

[Muldini]

Du hattest Recht, es fehlte Unterstützung für 'Masquerading'. Hab das Thema dahingehend auf "gelöst" gestellt.

Die Verbindung von meinem NB zum Server aus einem beliebigen Netz klappt jetzt. Ich habe daraufhin versucht die gleiche config für UDP zu nehmen (tcp-server -> udp, tcp-client -> udp). Ich habe also zwei Instanzen von OpenVPN mit zwei verschiedenen configs am laufen.
Verbindungsaufbau klappt an beide Instanzen, alles darüber hinausgehende nur über die TCP Instanz. Auf der UDP Instanz ist nicht ein mal die 10.0.0.1 zu erreichen.

Das hat mich dazu gebracht in Frage zu stellen ob das was ich möchte überhaupt unterstützt wird.

Eine Mischung von TCP und UDP Clients in einem Netz via client-to-client in beiden configs? Sprich die FB wählt sich als Client via UDP ein, das NB unterwegs via TCP (z.b. weil ein Proxy dazwischen kein UDP durchlässt) und beide können sich "unterhalten".

Gesetz dem Fall das sollte nicht unterstützt werden, kann ich zwei verschiedene IP-Adressbereiche nehmen und über den Server routen?

Ferner wird beim Start der zweiten Instanz auch ein zweiter Tun Adapter (tun1) erstellt, liegt das an UDP oder wird generell pro Instanz ein Adapter angelegt?

Viele Grüße

 

[MaxMuster]

Du kannst natürlich zwei Server parallel laufen lassen, einen mit TCP einen mit UDP, die beide ein eigenes Interface haben (die sinnd ja unterschiedliech Prozesse) Deshalb muss aber eben auch die IP-Config verschieden sein:
Nutzt TCP 10.0.0.x 255.255.255.0 dann muss UDP 10.0.1.x 255.255.255.0 nutzen oder so. Auch hier gilt eben für die IP: Es kann nur einen geben ;-)

Jörg

 

[Muldini]

Kurze Rückmeldung, dass nun auch die FB als Client verbunden ist. Klappte auf Anhieb wie oben von dir beschrieben. Wiedereinmal tausend Dank, Jörg.