Probleme mit VPN Verbindung unter Ubuntu

Im Unterforum Hardware, Betriebssysteme, Programmiersprachen - Beschreibung: Alles zu Software, Hardware, Windows, Linux, Programmiersprachen
Anfragen zu Modding, Games, Cracks, etc. unerwünscht.

Elektronik Forum Nicht eingeloggt       Einloggen       Registrieren




[Registrieren]      --     [FAQ]      --     [ Einen Link auf Ihrer Homepage zum Forum]      --     [ Themen kostenlos per RSS in ihre Homepage einbauen]      --     [Einloggen]

Suchen


Serverzeit: 13 6 2024  03:58:12      TV   VCR Aufnahme   TFT   CRT-Monitor   Netzteile   LED-FAQ   Osziloskop-Schirmbilder            


Elektronik- und Elektroforum Forum Index   >>   Hardware, Betriebssysteme, Programmiersprachen        Hardware, Betriebssysteme, Programmiersprachen : Alles zu Software, Hardware, Windows, Linux, Programmiersprachen
Anfragen zu Modding, Games, Cracks, etc. unerwünscht.


Autor
Probleme mit VPN Verbindung unter Ubuntu

    







BID = 720552

wulf

Schreibmaschine



Beiträge: 2246
Wohnort: Bozen
 

  


Hallo,
ich hab wieder mal ein kleineres Problem:
Bisher habe ich von meinem Studentenheim aus immer den Shrew Soft VPN Client auf Win7 benutzt um bei mir zu Hause im Heimnetz einzusteigen. Das hat auch wunderbar funktioniert.
Ich bin seit kurzem auf Ubuntu (10.10) umgestiegen und war eigentlich ganz froh, dass es den gleichen VPN Client auch auf Linux gibt.

Das Problem ist aber folgendes: Der VPN Client baut die Verbindung (laut Client) erfolgreich auf, aber ich kann trotzdem nicht auf das Heimnetz zugreifen.
Der Router im Heimnetz (= VPN Server) zeigt die Verbindung auch brav an.

Kann es sein, dass ich mit meiner Routingtabelle ein Problem habe?

Angehängt ein Bild meiner Routingtabelle

192.168.1.0 ist das Heimnetz
172.16.0.0 ist das Netz im Studentenheim
192.168.200.200 ist eine Adresse die der VPN Client für sich selbst braucht. (für den Virtuellen Adapter? In der Anleitung steht nur sie soll außerhalb beider Netze liegen)

Was ich jetzt nicht auf Anhierb cerstehe ist, warum er 192.168.200.0 auf das "gateway" 0.0.0.0 leitet. Bedeutet das, dass er weiter unten von 0.0.0.0 auf 172.16.1.1 (Studentenheimgateway) weiterleitet ?

Grüße
Simon


_________________
Simon
IW3BWH

BID = 720610

clembra

Inventar



Beiträge: 5404
Wohnort: Weeze / Niederrhein
ICQ Status  

 

  

Gateway 0.0.0.0 bedeutet, dass er die Pakete über das hinten genannte Interface direkt zustellen kann. Bei 192.168.200.0/24 (/24 = Netzmaske 255.255.255.0) bedeutet das, die Pakete werden über tap0, das virtuelle "VPN" Interface, zugestellt. Das ist auch korrekt so.
Welche IPs im VPN-Netz hast du denn an beiden VPN-Endpunkten? Ein ifconfig tap0 müsste eine IP im 200er Netz anzeigen, nach eigener Aussage sollte das die 192.168.200.200 sein.
Diese dürfte als Gateway aber nicht die richtige sein, es müsste vielmehr die IP des Home-Routers sein, also evtl. 192.168.200.1

Wichtige Frage: Kannst du deinen Home-Router über seine 200er-IP anpingen? Das ist erstmal erforderlich. Dann kommt neben der korrekten Hin-Route auch gerne ein Problem mit passender Rückroute hinzu. Wenn der VPN-Server aber auf dem Internet-Router bei dir zuhause läuft, welcher so oder so als Standardgateway eingetragen ist dürfte das Problem nicht auftreten.

_________________
Reboot oder be root, das ist hier die Frage.

BID = 720619

wulf

Schreibmaschine



Beiträge: 2246
Wohnort: Bozen

Hallo,
hab jetzt eine Weile rumprobiert. Ausser 192.168.200.200 (ja das ist der tap0) gibts da nichts. Weder Ping noch irgendwelche Dienste. Auf 192.168.200.200 gibt mir NMAP folgendes aus:
139/tcp open netbios-ssn
445/tcp open microsoft-ds

Ich verstehe auch nicht warum der Heimrouter irgendwo im Subnet 192.168.200.0 sein sollte. Braucht der tap0 nicht nur irgendeine Adresse um dann die Packete über eth0 an die WAN Adresse vom Heimrouter weiterzuleiten?

Grüße
Simon


_________________
Simon
IW3BWH

BID = 720626

clembra

Inventar



Beiträge: 5404
Wohnort: Weeze / Niederrhein
ICQ Status  

Nein, so funktioniert das Routing nicht.
Es gibt (grob überschlagen) zwei Arten von VPNs: geroutete und "gebridgte".
Bridge: Es gibt einen VPN-Server mit LAN. Das VPN und das LAN befinden sich im gleichen Subnetz. Wenn sich jemand per einwählt bekommt er ebenfalls eine IP aus diesem Subnetz. Es ist dabei auch möglich ein physikalisches Interface des VPN-Clients mit dem VPN-Interface zu bridgen, was zur Folge hätte, dass es für einen dritten PC egal ist, ob er sich im Home-Netzwerk anstöpselt oder an dem VPN-Client (-Router?). Dies ist bei dir nicht der Fall, kommt bei Firmen-VPNs aber öfter vor.

Route: Das VPN hat ein eigenes IP-Subnetz. Entweder liegen alle Clients und der Server im gleichen Subnetz (wie bei dir, Netzlänge meist 24) oder jeder Client bzw. der Server haben je ein eigenes Mini-Subnetz (30; 255.255.255.252). Die Kommunikation erledigt dann die VPN-Software (OpenVPN macht das gerne so).

So, nun zu deinem Fall:
Die Pakete verlassen deinen Rechner über das VPN mit der Quell-IP 192.168.200.200 und sollen Richtung Heimnetz. Der nächste Punkt (Ziel-IP oder Next-Hop) muss ebenfalls im Netz 192.168.200.0/24 liegen. Dies kann entweder ein zweiter VPN-Client sein oder aber der VPN-Server. Den VPN-Server (deinen Router im Heimnetzwerk) kannst du dann über die IP 192.168.200.x direkt erreichen. Für alle anderen PCs im Heimnetzwerk (192.168.1.0/24) ist eine Route erforderlich, die den Router als Gateway festlegt.

Daher bitte mal von deinem Ubuntu-Rechner bei aktiver VPN-Verbindung (ob da was durchgeht oder nicht ist egal) die Befehle ausführen:


Code :


route -n
ifconfig


und das Ergebnis hierher.

Welcher Router ist denn bei dir als VPN-Server im Einsatz?

_________________
Reboot oder be root, das ist hier die Frage.

BID = 720642

wulf

Schreibmaschine



Beiträge: 2246
Wohnort: Bozen

Hallo,
danke für die Erklärung. An den Unterschied bridging/routing hab ich in dem zusammenhang nicht mehr gedacht (obwohl ich auch mal mit openVPN gespielt habe und es da vorgekommen ist).

Hier erstmal deine gefragte Info:


Code :


route -n

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 192.168.200.200 255.255.255.0 UG 0 0 0 tap0
192.168.200.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 1000 0 0 eth0
172.16.0.0 0.0.0.0 255.255.0.0 U 1 0 0 eth0
0.0.0.0 172.16.1.1 0.0.0.0 UG 0 0 0 eth0





Code :


ifconfig

eth0 Link encap:Ethernet HWaddr 00:1c:23:9c:4b:5b
inet addr:172.16.12.XXX Bcast:172.16.255.255 Mask:255.255.0.0
inet6 addr: fe80::21c:23ff:fe9c:4b5b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:838360 errors:0 dropped:0 overruns:0 frame:0
TX packets:1199028 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:516467581 (516.4 MB) TX bytes:105098470 (105.0 MB)
Interrupt:18

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:3881 errors:0 dropped:0 overruns:0 frame:0
TX packets:3881 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:213671 (213.6 KB) TX bytes:213671 (213.6 KB)

tap0 Link encap:Ethernet HWaddr 8e:66:1f:ca:5a:97
inet addr:192.168.200.200 Bcast:192.168.200.255 Mask:255.255.255.0
inet6 addr: fe80::8c66:1fff:feca:5a97/64 Scope:Link
UP BROADCAST RUNNING MTU:1380 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)



Sorry, aber die genaue Netzwerkadresse musste ich maskieren da die im Heim hier speziell ist (Ist hauptsächlich ein Schülerheim, ich genieße als Student das Privileg einer statischen IP ohne Proxyfilter).

Die Konfiguration des Routers wird hier beschrieben:
http://www.shrew.net/support/wiki/HowtoLinksys
Da habe ich, mit Anpassungen, übernommen und hat auch bisher, mit Windows und Shrew Soft VPN Client, so funktioniert.
Der Router ist der Linksys RV-042

Danke für deine Mühe.

LG
Simon

P.S. Das ist für mich inzwischen etwas peinlich. Ich studiere nämlich in Richtung Netzwerktechnik.

_________________
Simon
IW3BWH

BID = 720676

clembra

Inventar



Beiträge: 5404
Wohnort: Weeze / Niederrhein
ICQ Status  

Was hast du bei "Local Group Setup" für eine IP-Adresse eingetragen?
Ich vermute mal, da müsste etwas wie 192.168.200.1/255.255.255.0 rein. Ansonsten bin ich auch überfragt.
Kann mir jemand sagen, was "autopopulate" in diesem Zusammenhang bedeutet?

Einen Linksys hätte ich zwar hier, aber da läuft openwrt drauf

_________________
Reboot oder be root, das ist hier die Frage.

BID = 720730

wulf

Schreibmaschine



Beiträge: 2246
Wohnort: Bozen

Bei Local Group Setup
Hab ich Subnet
192.168.1.0
255.255.255.0
eingetragen.

Aber in der Beschreibung steht, dass das der Adressbereich ist, der die lokalen Benutzer in de VPN Tunnel lässt.

Autopopulate wird in diesem Zusammenhang aussagen, dass sich die Eingabefelder automatisch ausfüllen (das passiert nämlich).

Grüße
Simon

P.S. Habe jetzt nebenbei die Funktion PPTP Server beim Router probiert und kann jetzt mit dem Linux PPTP Client zugreifen. Allerdings funktioniert das eher schlecht als recht. Die halben Pingpackete gehen auf dem Weg verloren.
Und ob die Verbindung verschlüsselt ist bezweifle ich mal stark.

_________________
Simon
IW3BWH

BID = 721258

wulf

Schreibmaschine



Beiträge: 2246
Wohnort: Bozen

Hallo clembra,
ich hab jetzt nach längerem Stöbern eine Lösung auf einer Mailinglist gefunden.
Es hatte gar nichts mit der Verbindung direkt zu tun.



Code :


I have been troubleshooting an issue on Linux which has been reported by
several people. The problem was difficult to identify since the client
can establish a connection and negotiate IPSec SAs, but return traffic
never makes it to the userland applications. For example, ping displays
the following stalled output ...

mgrooms at ubuntu8-64:~$ ping 10.1.2.100
PING 10.1.2.100 (10.1.2.100) 56(84) bytes of data.

... even though you can see response packets using tcpdump ...

mgrooms at ubuntu8-64:~$ sudo tcpdump -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:46:45.102547 IP 10.1.2.100 > 10.2.20.5: ICMP echo reply, id 32537,
seq 1, length 64
12:46:46.102905 IP 10.1.2.100 > 10.2.20.5: ICMP echo reply, id 32537,
seq 2, length 64

After a lot of tinkering, I was able to determine that the following
sysctl setting will cause the kernel to drop packets received on one
interface when the destination address is owned by another interface.

net.ipv4.conf.all.rp_filter

The documentation states the following ...

rp_filter - INTEGER
2 - do source validation by reversed path, as specified in RFC1812
Recommended option for single homed hosts and stub network
routers. Could cause troubles for complicated (not loop free)
networks running a slow unreliable protocol (sort of RIP),
or using static routes.

1 - (DEFAULT) Weaker form of RP filtering: drop all the packets
that look as sourced at a directly connected interface, but
were input from another interface.

0 - No source validation.

For the client to work properly, this option value must be set to 0.
Making the value stick on some systems can be a bit challenging. For
example, the 8.10 Ubuntu host I used for testing has the following
references to this sysctl option under etc ...

mgrooms at ubuntu8-64:/etc$ grep -r rp_filter *
sysctl.conf:#net.ipv4.conf.default.rp_filter=1
sysctl.conf:#net.ipv4.conf.all.rp_filter=1
sysctl.d/10-network-security.conf:net.ipv4.conf.default.rp_filter=1
sysctl.d/10-network-security.conf:net.ipv4.conf.all.rp_filter=1
ufw/sysctl.conf:net/ipv4/conf/all/rp_filter=1
ufw/sysctl.conf:net/ipv4/conf/default/rp_filter=1

I'm not sure which one should be set under what circumstances, but I was
able to comment out all but the 10-network-security.conf line and set it
to 0. After rebooting the host, the sysctl values looked like this ...

mgrooms at ubuntu8-64:/etc$ sysctl -a | grep rp_filter | grep -v arp
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.pan0.rp_filter = 0
net.ipv4.conf.tap0.rp_filter = 0

And finally, everything works as expected using the VPN client ...

mgrooms at ubuntu8-64:/etc$ ping 10.1.2.100
PING 10.1.2.100 (10.1.2.100) 56(84) bytes of data.
64 bytes from 10.1.2.100: icmp_seq=1 ttl=64 time=1.55 ms
64 bytes from 10.1.2.100: icmp_seq=2 ttl=64 time=0.873 ms


Quelle: http://lists.shrew.net/pipermail/vpn-help/2008-November/000950.html

Danke nochmal für die Mühe.

Liebe Grüße
Simon

_________________
Simon
IW3BWH

BID = 721271

clembra

Inventar



Beiträge: 5404
Wohnort: Weeze / Niederrhein
ICQ Status  

Da komm auch mal einer drauf .
Freut mich, dass es nun funktioniert und danke für die Lösung. Vielleicht ist die ja noch für andere hilfreich

clembra

_________________
Reboot oder be root, das ist hier die Frage.

BID = 721277

wulf

Schreibmaschine



Beiträge: 2246
Wohnort: Bozen

Als ich das das erste mal gelesen habe musste ich die Kinnlade erstmal manuell zuklappen.

Und ich fing schon an an meinen Fähigkeiten als angehender Netzwerker zu zweifeln.

_________________
Simon
IW3BWH

BID = 721321

clembra

Inventar



Beiträge: 5404
Wohnort: Weeze / Niederrhein
ICQ Status  

Naja, dass der Kernel einige Firewall-Techniken (Anti-IP-Spoofing etc.) integriert hat war mir schon bewusst, aber an so etwas denkt man für gewöhnlich nicht. Die sind eben da
Ursache dürfte wohl die komische Vorgehensweise von dem VPN-Client sein. Normalerweise bekommt das tap-Interface die IP-Adresse vom VPN-Server zugeteilt. Dann ist der Kernel zufrieden, da die Ziel-IP der Pakete mit der IP des Interfaces übereinstimmt. In diesem Fall bekommt das TAP-Interface eine IP aus einem komplett anderen Subnetz. Vermutlich werden die Pakete aber dennoch an eine IP aus deinem Home-Netz adressiert. Diese werden dann vom VPN-Client mit der original-IP an das tap0 zugestellt und der Kernel ist verwirrt.

_________________
Reboot oder be root, das ist hier die Frage.


Zurück zur Seite 0 im Unterforum          Vorheriges Thema Nächstes Thema 


Zum Ersatzteileshop


Bezeichnungen von Produkten, Abbildungen und Logos , die in diesem Forum oder im Shop verwendet werden, sind Eigentum des entsprechenden Herstellers oder Besitzers. Diese dienen lediglich zur Identifikation!
Impressum       Datenschutz       Copyright © Baldur Brock Fernsehtechnik und Versand Ersatzteile in Heilbronn Deutschland       

gerechnet auf die letzten 30 Tage haben wir 15 Beiträge im Durchschnitt pro Tag       heute wurden bisher 0 Beiträge verfasst
© x sparkkelsputz        Besucher : 181457235   Heute : 267    Gestern : 6073    Online : 420        13.6.2024    3:58
1 Besucher in den letzten 60 Sekunden        alle 60.00 Sekunden ein neuer Besucher ---- logout ----viewtopic ---- logout ----
xcvb ycvb
0.0609321594238