PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : pptpd vergibt default IP-Adresse!!



Basti_litho
28.07.07, 22:33
Hallo zusammen,

ich verzweifle langsam an mir und an Debian und pptpd.

Er vergibt den Clients immer irgendwelche Standard IP-Adressen - diese habe ich aber nicht konfiguriert!! Problem ist das die aus einem Bereich sind den ich nicht gebrauchen kann.

Hier kurz die Struktur des Netzes:

192.168.0.0/24 - dort sind alle Server, auch ein DHCP-Server (der im übrigen die 192.168.0.1 hat).

Wenn sich ein Client einwählt bekommt er die "192.168.1.1" und der pptpd Server nimmt sich die "192.168.0.1" <-- und das ist falsch weil der DHCP Server die ja schon hat.

Die option "proxyarp" habe ich bewußt herausgenommen - weil der meinte er könne meine ip-adresse nicht ermitteln (wobei auf der Webseite steht das es per "hostname -i" ermittelt wird - was auch klappt.

Nachdem ich das rausgenommen habe und "localip" und "remoteip" definiert habe - werden diese Optionen trotzdem ignoriert und die beiden IP-Adressen verwendet.

Hier mal meine configs:
pptpd.conf:


option /etc/ppp/options
debug
localip 192.168.0.234
remoteip 192.168.0.240-250
pidfile /var/run/pptpd.pid
/etc/ppp/options
debug
lock
auth
+chapms-v2
mppe-128
mppe-stateless
mru 1436
mtu 1436
noipx
noproxyarp
ms-dns 192.168.0.107
ms-wins 192.168.0.107


und die "/etc/ppp/options":


asyncmap 0
noauth
crtscts
lock
hide-password
modem
debug
lcp-echo-interval 30
lcp-echo-failure 4
noipx


Mir fällt nichts mehr ein - bin echt ratlos.
Ich weiß zwar das die eigentlich im getrennten IP-Adress Bereich liegen sollten - aber ist mir egal - hauptsache die Clients kommen an die Server ran - und der pptpd-Server bekommt nicht die IP-Adresse vom DHCP-Server.

Hoffentlich fällt jemanden noch was ein.

Vielen Dank fürs lesen :)


PS: aus den Quellen habe ich es auch schon versucht zu installieren - was fehlgeschlagen ist. :(

bla!zilla
29.07.07, 09:21
Proxyarp hat einen anderen Hintergrund. Es geht darum das deine Maschine auf ARP Anfragen antworten darf, die sie beantworten kann. Das soll Traffic minimieren. Die IPs _müssen_ aus einem anderen Range sein, Stichwort "sauberes Routing".

Basti_litho
29.07.07, 17:20
Hallo,

ok - wie gesagt - es ist mir schon bewußt das die IP-Adressen aus verschiedenen Bereichen kommen sollten - aber kann ich denn diese Bereiche nicht selbst bestimmen?

bla!zilla
29.07.07, 17:54
Ja kannst du. Aber dein pptpd ist nicht zufällig mit --with-pppd-ip-alloc kompiliert worden, oder?



localip ip-specification

one or many IP addresses to be used at the local end of the tunnelled PPP links between the server and the client. If one address only is given, this address is used for all clients. Otherwise, one address per client must be given, and if there are no free addresses then any new clients will be refused. localip is ignored if pptpd(8) was compiled with --with-pppd-ip-alloc.

remoteip ip-specification

a list of remote IP addresses to be used on the tunnelled PPP links between the server and the client. There must be at least one IP address per client permitted to connect simultaneously, and preferably some spare addresses. A warning will be sent to syslog(3) when the IP address pool is exhausted. remoteip was ignored if pptpd(8) is compiled with --with-pppd-ip-alloc.

Basti_litho
29.07.07, 19:38
Ja, das hab ich auch schon gedacht - und daher die Quellen ausprobiert - was aber an ppp gescheitert ist. Das rpm hatte nur patches - das war mir zu mühsam die alle anzuwenden - bzw. ich weiß auch nicht in welcher reihenfolge.

Naja, weiß nicht - evtl. muss ich dann die IP-Adresse des DHCP Servers ändern - oder doch den ppp neu übersetzen (mit den 10 patches). :(

Danke trotzdem für deine Antworten. :)

Schönen Gruß
Basti

bla!zilla
29.07.07, 19:51
Das ist bei dir einfach nur ein Konfigurationsfehler oder ein fehlerhaftes Paket. Ich verstehe auch nicht warum die IPs im gleichen Range sein müssen. Woher soll die Kiste denn wissen welche Clients über einen Tunnel erreichbar sind und welche nicht? So wird das nie was.

Basti_litho
29.07.07, 20:04
Mir ist es eigentlich egal ob im gleichen Netz oder nicht - ich will doch einfach nur das die Clients die Rechner im internen Netz erreichen.

Soweit so gut - wenn die IP-Adressen zumindest nicht so vergeben werden.

Derzeit hat der vpn tunnel die gleiche Adresse wie der DHCP Server im internen Netz - was ja falsch ist.

Internes Netz:
192.168.0.0/24
DHCP-Server: 192.168.0.1
Clients: 192.168.0.100 - 192.168.0.200
Nach der einwahl:

ppp device = 192.168.0.1
Client = 192.168.1.1

und mit der Konfiguration erreiche ich niemanden im internen Netz! :(
selbst mit aktivem ip-forwarding.

Was das falsche Paket betrifft: das könnte schon sein - obwohl es mich wundert weil es doch einfach ein Paket von Debian ist - d.h. es müssten doch mehr Leute damit Probleme haben.

bla!zilla
30.07.07, 08:32
Mir ist es eigentlich egal ob im gleichen Netz oder nicht - ich will doch einfach nur das die Clients die Rechner im internen Netz erreichen.

Ein Router verbindet unterschiedliche Netze, ein Router kann nicht die gleichen Subnetze an unterschiedlichen Schnittstellen haben. Dein Linux-Server mit PPTP ist aber im Prinzip ein Router. Du _brauchst_ unterschiedliche Subnetze.

Poste bitte endlich mal deine pptpd.conf.

Basti_litho
01.08.07, 14:40
Hallo,

sorry das ich mich jetzt erst melde - hab kein DSL mehr :(



Poste bitte endlich mal deine pptpd.conf.

Ist immer noch die selbe wie aus meinem ersten Posting ;)

Das einzige was ich jetzt noch geändert habe ist die localip ("192.168.1.234") und remoteip ("192.168.1.240-250") - was auch nichts geholfen hat :(

Jetzt habe ich auch die Quellen von "ppp" und "pptpd" übersetzt und installiert um zu verhindern das die Paketbauer die gesagte Option gesetzt haben, was auch nicht geholfen hat. :(

Ich bin echt am Ende meines Lateins *heul*.

bla!zilla
01.08.07, 14:59
Shit, mein Fehler. Hatte es für die ppp.conf gehalten.

Basti_litho
01.08.07, 15:19
kein thema :)

also - bin einen minischritt weiter:

wenn ich mir die Prozesse anschaue ("ps aux") nach einem Verbindungsaufbau - dann sehe ich folgendes:


/usr/sbin/pppd local file /etc/ppp/pptpd-options 115200 192.168.0.1:192.168.1.1 ipparam 80.xxx.xx.x plugin /usr/lib/pptpd/...

Das macht er anscheindend über das "ip-up" script - aber woher er die IP-Adressen angaben nimmt ist mir total rätselhaft.

Die pptpd-options:



name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns 192.168.0.107
ms-dns 192.168.0.107
ms-wins 192.168.0.107
nodefaultroute
debug
lock
nobsdcomp

bla!zilla
01.08.07, 15:27
Poste mal die Logs.

Basti_litho
01.08.07, 15:39
syslog:


Aug 1 15:34:59 sbs2003 -- MARK --
Aug 1 15:35:00 sbs2003 pptpd[9203]: CTRL: Client 80.xx.xx.xx control connection started
Aug 1 15:35:00 sbs2003 pptpd[9203]: CTRL: Starting call (launching pppd, opening GRE)
Aug 1 15:35:00 sbs2003 pppd[9204]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Aug 1 15:35:00 sbs2003 pppd[9204]: pptpd-logwtmp: $Version$
Aug 1 15:35:00 sbs2003 pppd[9204]: pppd 2.4.3 started by root, uid 0
Aug 1 15:35:00 sbs2003 pppd[9204]: using channel 30
Aug 1 15:35:00 sbs2003 pppd[9204]: Using interface ppp0
Aug 1 15:35:00 sbs2003 pppd[9204]: Connect: ppp0 <--> /dev/pts/1
Aug 1 15:35:00 sbs2003 pppd[9204]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xa2b361c8> <pcomp> <accomp>]
Aug 1 15:35:00 sbs2003 pptpd[9203]: GRE: Bad checksum from pppd.
Aug 1 15:35:00 sbs2003 pppd[9204]: rcvd [LCP ConfReq id=0x0 <mru 1400> <magic 0x2b181344> <pcomp> <accomp> <callback CBCP>]
Aug 1 15:35:00 sbs2003 pppd[9204]: sent [LCP ConfRej id=0x0 <callback CBCP>]
Aug 1 15:35:00 sbs2003 pppd[9204]: rcvd [LCP ConfReq id=0x1 <mru 1400> <magic 0x2b181344> <pcomp> <accomp>]
Aug 1 15:35:00 sbs2003 pppd[9204]: sent [LCP ConfAck id=0x1 <mru 1400> <magic 0x2b181344> <pcomp> <accomp>]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xa2b361c8> <pcomp> <accomp>]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xa2b361c8> <pcomp> <accomp>]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [LCP EchoReq id=0x0 magic=0xa2b361c8]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [CHAP Challenge id=0x4d <659c40992d4849a4e00c47992ec2b080>, name = "pptpd"]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [LCP code=0xc id=0x2 2b 18 13 44 4d 53 52 41 53 56 35 2e 32 30]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [LCP CodeRej id=0x2 0c 02 00 12 2b 18 13 44 4d 53 52 41 53 56 35 2e 32 30]
Aug 1 15:35:03 sbs2003 pptpd[9203]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [LCP code=0xc id=0x3 2b 18 13 44 4d 53 52 41 53 2d 30 2d 4b 55 4b 4f 56 45 54 5a 4c 41 50 54 4f 50]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [LCP CodeRej id=0x3 0c 03 00 1e 2b 18 13 44 4d 53 52 41 53 2d 30 2d 4b 55 4b 4f 56 45 54 5a 4c 41 50 5 4 4f 50]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [LCP EchoRep id=0x0 magic=0x2b181344]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [CHAP Response id=0x4d <e44b95a139e3b942421acef7ffa1d896000000000000000012 86ea622c916e992f250b8c35d2dd c37fe5789491dd61bd00>, name = "testuser"]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [CHAP Success id=0x4d "S=9D88C8B64DE28835E6E90E18BCA03B19A1234A12 M=Access granted"]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [proto=0x8057] 01 04 00 0e 01 0a 4c 32 72 97 86 bc 29 91
Aug 1 15:35:03 sbs2003 pppd[9204]: Unsupported protocol 0x8057 received
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [LCP ProtRej id=0x4 80 57 01 04 00 0e 01 0a 4c 32 72 97 86 bc 29 91]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [CCP ConfReq id=0x5 <mppe +H -M +S -L -D -C>]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [CCP ConfAck id=0x5 <mppe +H -M +S -L -D -C>]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [IPCP ConfReq id=0x6 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0 .0.0>]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [IPCP TermAck id=0x6]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
Aug 1 15:35:03 sbs2003 pppd[9204]: MPPE 128-bit stateless compression enabled
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.168.0.1>]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
Aug 1 15:35:03 sbs2003 pppd[9204]: sent [IPCP ConfReq id=0x2 <addr 192.168.0.1>]
Aug 1 15:35:03 sbs2003 pppd[9204]: rcvd [IPCP ConfAck id=0x2 <addr 192.168.0.1>]
Aug 1 15:35:05 sbs2003 pppd[9204]: rcvd [IPCP ConfReq id=0x7 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0 .0.0>]
Aug 1 15:35:05 sbs2003 pppd[9204]: sent [IPCP ConfNak id=0x7 <addr 192.168.1.1> <ms-dns1 192.168.0.107> <ms-wins 192.168.0.107> <ms-dns3 192.1 68.0.107> <ms-wins 192.168.0.107>]
Aug 1 15:35:05 sbs2003 pppd[9204]: rcvd [IPCP ConfReq id=0x8 <addr 192.168.1.1> <ms-dns1 192.168.0.107> <ms-wins 192.168.0.107> <ms-dns3 192.1 68.0.107> <ms-wins 192.168.0.107>]
Aug 1 15:35:05 sbs2003 pppd[9204]: sent [IPCP ConfAck id=0x8 <addr 192.168.1.1> <ms-dns1 192.168.0.107> <ms-wins 192.168.0.107> <ms-dns3 192.1 68.0.107> <ms-wins 192.168.0.107>]
Aug 1 15:35:05 sbs2003 pppd[9204]: local IP address 192.168.0.1
Aug 1 15:35:05 sbs2003 pppd[9204]: remote IP address 192.168.1.1
Aug 1 15:35:05 sbs2003 pppd[9204]: pptpd-logwtmp.so ip-up ppp0 testuser 80.xxx.xx.x
Aug 1 15:35:05 sbs2003 pppd[9204]: Script /etc/ppp/ip-up started (pid 9208)
Aug 1 15:35:05 sbs2003 pppd[9204]: Script /etc/ppp/ip-up finished (pid 9208), status = 0x0
Aug 1 15:35:33 sbs2003 pppd[9204]: sent [LCP EchoReq id=0x1 magic=0xa2b361c8]
Aug 1 15:35:33 sbs2003 pppd[9204]: rcvd [LCP EchoRep id=0x1 magic=0x2b181344]
Aug 1 15:36:03 sbs2003 pppd[9204]: sent [LCP EchoReq id=0x2 magic=0xa2b361c8]
Aug 1 15:36:03 sbs2003 pppd[9204]: rcvd [LCP EchoRep id=0x2 magic=0x2b181344]

bla!zilla
01.08.07, 18:58
Der Host hat aber nicht zufällig die 192.168.0.234 an ein lokales Interface gebunden, oder?

Basti_litho
01.08.07, 19:08
Nee, der hat die "192.168.0.107" und "192.168.16.250" (obwohl die egal ist).
Die "192.168.0.234" wollte ich ihm für sein "ppp0" device geben.

Aber es sieht doch alles ganz gut aus - oder?

Basti_litho
01.08.07, 19:10
Hier mal die ganze Netzwerkeinstellung des VPN Server:


eth1 Protokoll:Ethernet Hardware Adresse 00:11:6B:36:33:FB
inet Adresse:192.168.0.107 Bcast:192.168.0.255 Maske:255.255.255.0
inet6 Adresse: fe80::211:6bff:fe36:33fb/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2544653 errors:0 dropped:0 overruns:0 frame:0
TX packets:3183946 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:1472762894 (1.3 GiB) TX bytes:1754618694 (1.6 GiB)
Interrupt:217 Basisadresse:0xa000

eth2 Protokoll:Ethernet Hardware Adresse 00:11:6B:36:36:A9
inet Adresse:192.168.16.250 Bcast:192.168.16.255 Maske:255.255.255.0
inet6 Adresse: fe80::211:6bff:fe36:36a9/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1039556 errors:0 dropped:0 overruns:0 frame:0
TX packets:108476 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:543531486 (518.3 MiB) TX bytes:7239558 (6.9 MiB)
Interrupt:201 Basisadresse:0xa400

lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:15909 errors:0 dropped:0 overruns:0 frame:0
TX packets:15909 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:1119204 (1.0 MiB) TX bytes:1119204 (1.0 MiB)

sbs2003:/var/log/samba# route -n
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.16.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth1

bla!zilla
01.08.07, 20:16
Mach mal bitte ein ifconfig -a und poste die Ausgabe.