VPN - Routing nicht möglich

worker · 8 Juni 2007

Hi Leute,

ich bin nun 4. Tag an der besch... Konfig. von pptpd ...

Als erstes habe ich dieses Problem ( http://www.linux-club.de/ftopic82045.html ) immer noch :-( ...

Als zweites Problem gestaltet sich das Routing ...

Zum Hintergrund:
Ich möchte ein VPN aufbauen, um mit Freunden LAN-Games spielen zu können, aber auch event. Dateien tauschen zu können.
Klar, geht auch per FTP, aber per VPN ist das doch irgendwie "cooler" ;-)

So, jetzt habe ich VPN soweit eingerichtet (unter SuSE 10.2), dass ich mich mit XP-Clients am Server anmelden kann.

Leider funktioniert nur der Ping wie folgt:
- Von jedem Client zum Server
- Vom Server aus zu jedem Client

Leider bekomme ich es (echt um´s verrecken) nicht hin, dass der Server die unterschiedlichen IP´s (alle Clients im Subnetz: 192.168.1.0) untereinander routet.

Meine Konfiguration des Servers ...

/etc/ppp/options.pptpd :

Code:

# Servername
name XXX

# Netzmaske
netmask 255.255.255.0

# Route
#nodefaultroute

# Routing zu VPN-Netzwerken
proxyarp

#
# Lock the port
#
lock

#
# We don't need the tunnel server to authenticate itself
#
auth

#
# Turn off transmission protocols we know won't be used
#
nobsdcomp
nodeflate

#
# We want MPPE
#
#require-mppe
require-chap

#
# We want a sane mtu/mru
#
mtu 1000
mru 1000

#mtu 1490
#mru 1490

#
# Time this thing out of it goes poof
#
lcp-echo-failure 10
lcp-echo-interval 10

ipcp-accept-local
ipcp-accept-remote

/etc/pptpd.conf :

Code:

################################################################################
# PoPToP version 1.0.0
#
################################################################################

# TAG: speed
#
#	Specifies the speed for the PPP daemon to talk at.
#	Some PPP daemons will ignore this value.
#
speed 115200

# TAG: option
#
#	Specifies the location of the PPP options file.
#	By default PPP looks in '/etc/ppp/options'
#
#option /this/is/the/options/file
option /etc/ppp/options.pptpd

# TAG: debug
#
#	Turns on (more) debugging to syslog.
#
debug

# TAG: localip
# TAG: remoteip
#
#	Specifies the local and remote IP address ranges.
#
#	You can specify single IP addresses seperated by commas or you can
#	specify ranges, or both. For example:
#
#		192.168.0.234,192.168.0.245-249,192.168.0.254
#
#	IMPORTANT RESTRICTIONS:
#
#	1. No spaces are permitted between commas or within addresses.
#
#	2. If you give more IP addresses than MAX_CONNECTIONS, it will
#	   start at the beginning of the list and go until it gets 
#	   MAX_CONNECTIONS IPs. Others will be ignored.
#
#	3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#	   you must type 234-238 if you mean this.
#
#	4. If you give a single localIP, that's ok - all local IPs will
#	   be set to the given one. You MUST still give at least one remote
#	   IP for each simultaneous client.
#
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245

localip 192.168.1.1
remoteip 192.168.1.10-20

# TAG: ipxnets
#
#	This gives the range of IPX networks to allocate to clients.  By
#	default IPX network number allocation is not handled internally.
#	By putting a low and high network number here a pool of IPX networks
#	can be defined.  If this is done then there must be one IPX network
#	per client.
#
#	The format is a pair of hex numbers without any 0x prefix separated
#	by a hyphen.
#
#ipxnets 00001000-00001FFF

# TAG: listen
#
#	Defines the IP address of the local interface on which pptpd
#	should listen for connections.  The default is to listen on all
#	local interfaces (even ones brought up by pptp connections, thus
#	permitting pptp tunnels inside the pptp tunnels).
#
#listen 192.168.1.1

# TAG: pidfile
#
#	This defines the file name in which pptpd should store its process
#	ID (or pid).  The default is /var/run/pptpd.pid.
#
pidfile /var/run/pptpd.pid

IP-Weiterleitung habe ich per YaST aktiviert.
Auch habe ich bereits versucht das Netz direkt zu routen - also:

Netz | GW | Mask | Dev
192.168.1.0 | 192.168.1.1 | 255.255.255.255 | eth0/ppp/lo

Beim "Dev" hatte ich der Reihe nach probiert: eth0, ppp, lo, "" (leer)

Was mich recht verwirrt ist, dass pptpd jedesmal, wenn sich ein Client anmeldet, pptpd ein neues Interface (Dev) erstellt: pppX
Aber, wie soll dann der Linux-Server wissen, wo bzw. über welches device er die VPN-Verbindungen routen soll ?

(Hinzu kommt aber auch die Netzwerkmaske - ist nicht auf 255.255.255.0)

Ich hatte echt _etliche_ Webseiten durchforstet, aber ich komme einfach nicht weiter. Wäre super, wenn mir jemand mal die Richtung "weisen" könnte ;-)

Grüße und schon mal Danke im Voraus
W.

PS: Nein, ich möchte nicht zu openVPN wechseln ;-)

worker · 8 Juni 2007

Mir ist gerade eingefallen ... kann es sein, dass das Problem auf unseren XP-Kisten ist - also am Client ?
Da ja das VPN-Netz quasi als "nicht bekannt" gilt, und die Pakete dann über das GW laufen - d.h. bei mir: zum Fritz-Router (von da mögliche Richtungen: Internet oder LAN).

worker · 8 Juni 2007

route print (XP-Client) ergab:

Code:

===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0    192.168.178.1  192.168.178.10       30
     xx.xx.xx.xx  255.255.255.255    192.168.178.1  192.168.178.10       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.1.0    255.255.255.0     192.168.1.10    192.168.1.10       1
     192.168.1.10  255.255.255.255        127.0.0.1       127.0.0.1       50
    192.168.1.255  255.255.255.255     192.168.1.10    192.168.1.10       50
    192.168.178.0    255.255.255.0   192.168.178.10  192.168.178.10       30
   192.168.178.10  255.255.255.255        127.0.0.1       127.0.0.1       30
  192.168.178.255  255.255.255.255   192.168.178.10  192.168.178.10       30
        224.0.0.0        240.0.0.0     192.168.1.10    192.168.1.10       50
        224.0.0.0        240.0.0.0   192.168.178.10  192.168.178.10       30
  255.255.255.255  255.255.255.255     192.168.1.10    192.168.1.10       1
  255.255.255.255  255.255.255.255   192.168.178.10  192.168.178.10       1
Standardgateway:     192.168.178.1
===========================================================================
Ständige Routen:
  Keine

So, jetzt bin ich echt "am Ende" ...
192.168.1.0 und 192.168.1.10 ... warum tut er das ??
Ich habe ja keine Routen manuell eingetragen.

nbkr · 8 Juni 2007

Was sagt den "ipconfig /all" unter Windows?

worker · 8 Juni 2007

Hi nbkr,

ipconfig /all (auf xp):

Code:

Windows-IP-Konfiguration

        Hostname. . . . . . . . . . . . . : basis-pc
        Primäres DNS-Suffix . . . . . . . :
        Knotentyp . . . . . . . . . . . . : Unbekannt
        IP-Routing aktiviert. . . . . . . : Nein
        WINS-Proxy aktiviert. . . . . . . : Nein

Ethernetadapter 100MBit-LAN:

        Verbindungsspezifisches DNS-Suffix:
        Beschreibung. . . . . . . . . . . : Realtek RTL8169/8110 Family Gigabit
Ethernet NIC
        Physikalische Adresse . . . . . . : XX-XX-XX-XX-XX-XX
        DHCP aktiviert. . . . . . . . . . : Nein
        IP-Adresse. . . . . . . . . . . . : 192.168.178.10
        Subnetzmaske. . . . . . . . . . . : 255.255.255.0
        Standardgateway . . . . . . . . . : 192.168.178.1
        DNS-Server. . . . . . . . . . . . : 192.168.178.1

PPP-Adapter VPN-Home-Server:

        Verbindungsspezifisches DNS-Suffix:
        Beschreibung. . . . . . . . . . . : WAN (PPP/SLIP) Interface
        Physikalische Adresse . . . . . . : XX-XX-XX-XX-XX-XX
        DHCP aktiviert. . . . . . . . . . : Nein
        IP-Adresse. . . . . . . . . . . . : 192.168.1.10
        Subnetzmaske. . . . . . . . . . . : 255.255.255.255
        Standardgateway . . . . . . . . . :
        DNS-Server. . . . . . . . . . . . : 192.168.1.1

Ich schätze mal es ist wirklich ein Problem von der Client-Seite her ...
Auch frage ich mich, warum das 192.168.1.0 Netz nicht den GW vom VPN-Server bekommt.

worker · 8 Juni 2007

route (auf dem Linux-VPN-Server) gibt folgendes aus:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.10    *               255.255.255.255 UH    0      0        0 ppp0
192.168.1.11    *               255.255.255.255 UH    0      0        0 ppp1
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         fritz.fonwlan.b 0.0.0.0         UG    0      0        0 eth0

nbkr · 8 Juni 2007

Gib dem PPP Adapter mal eine Defaultroute mit. Das sollte sich über die Netzwerkeinstellungen bewerkstelligen lassen.

Alternativ mal auf den Clients und dem Server einen Sniffer mitlaufen lassen und schauen welche Pakete wo ankommt und wer sie nicht richtig weiterleitet.

Ein Traceroute von einem Client zum anderen könnte evtl. auch aufschlussreich sein.

worker · 8 Juni 2007

OK, zuerstmal wegen dem PPP-Adapter und der Defaultroute ...

Wie stelle ich das an ?
Zumal das wahrsch. über ein Script laufen muss, da der PPP-Adapter ja quasi nur "virtuell" existiert (bei jedem neuen Client = ppp_n+1, bzw. beim Abmelden = ppp_n wird gelöscht)

Jedenfalls danke ich Dir für Deine Hilfe ;-)
Aber so langsam wird´s für mich echt interessant ... hoffentlich bringe ich es auch zum Laufen

...

worker · 8 Juni 2007

Hm tracert gibt von client2client gar nichts aus bzw. nur ein "Zeitüberschreitung" ...
Wir wohl daran liegen, dass auch kein Ping geht.

nbkr · 8 Juni 2007

worker schrieb:
Wie stelle ich das an ?
Zumal das wahrsch. über ein Script laufen muss, da der PPP-Adapter ja quasi nur "virtuell" existiert (bei jedem neuen Client = ppp_n+1, bzw. beim Abmelden = ppp_n wird gelöscht)

Der Linuxrechner hat alle Routen, nur den Clients fehlt da scheinbar was. Und die Clients haben ja nur einen PPP Adapter, oder?

worker · 8 Juni 2007

Ja, die Clients haben je nur einen PPP-Adapter.

Beim Sniffen auf den XP Kisten ist keine Aktion zu verzeichnen --> client2client.

Beim Sniffen auf der Linux-Kiste, über tcpdump, bin ich noch am "experimentieren" wie das eigentlich geht ;-)
(man snifft ja nicht alle tage

)

worker · 8 Juni 2007

Hm, also ein "tcpdump -i ppp0" ergab, dass kein einziges Paket an-/durchkommt an diesem device.

Der Ping wurde hier vom 192.168.1.11 (auf dem Server ist es das device: ppp1) zum 192.168.1.10 (device: ppp0) geschickt.

Der gleiche Ping (gleiche richtung), jedoch mit "tcpdump -i ppp1":

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
22:49:40.952189 IP 192.168.1.11 > 192.168.1.10: ICMP echo request, id 768, seq 1280, length 40
22:49:46.384768 IP 192.168.1.11 > 192.168.1.10: ICMP echo request, id 768, seq 1536, length 40
22:49:51.893689 IP 192.168.1.11 > 192.168.1.10: ICMP echo request, id 768, seq 1792, length 40

Also doch kein Routing auf dem Server ?

Wieso leitet er den Netzwerkverkehr nicht weiter ?
Hat das was mit der Maske zu tun ?

worker · 9 Juni 2007

OK, hier kommt die halbe Lösung ...

Ich habe das Netz 192.168.1.0 manuell in die Routing-Tabelle eingetragen:
192.168.1.0 | 192.168.178.241 | 255.255.255.0

Nachtrag: 192.168.178.241 = VPN-Server (eth0)

Jetzt bekomme ich so viele Pings, wie ich will ;-) ...
Sprich: Verbindungen stehen

Die Eintragungen habe ich zwar vorher auch gemacht, aber die SuSEFirewall wurde (obwohl vorher abgeschaltet) wohl jedesmal neu eingeschaltet/gestartet.

Das Problem war und ist bis jetzt die SuSEFirewall ... die ist jetzt OFF.
Ich habe noch keine Ahnung, wie ich die ON stelle, ohne dass sie die pppX-devices blockieren wird.

Naja, zumindest besser so, als garnicht ;-)

Ich danke Dir nbkr für Deine Hilfe ;-) !!!!

Grüße
W.

PS: Wenn ich ne Lösung für die FW habe, werde ich sie hier posten ...

worker · 9 Juni 2007

Also wenn jemand eine Idee/Vorschlag etc. wegen der Firewall hat - immer her damit ;-) ...
Es will nicht laufen.

nbkr · 9 Juni 2007

Versuch mal ob Du die PPP Interfaces unter YaST als "intern" markieren kannst.

worker · 9 Juni 2007

Wollte ich machen, nur die FW "erkennt" die ppp - Interfaces anscheinend garnicht :-| ... die tauchen in den FW-Einstellungen überhaupt nicht auf.

Habe dann versucht unter "Schnittstellen" einen "Benutzerdefinierten String" als ppp einzutragen und den dann als interne Zone zu definieren, aber die FW blockt trotzdem die Pings der Client2Client.

VPN - Routing nicht möglich

worker

Member

worker

Member

worker

Member

nbkr

Guru

worker

Member

worker

Member

nbkr

Guru

worker

Member

worker

Member

nbkr

Guru

worker

Member

worker

Member

worker

Member

worker

Member

nbkr

Guru

worker

Member