kaktux
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
Moin, ich habe Probleme eine VPN Verbindung zum laufen zu bekommen.
Es handelt sich um VPN per pptp.
Betriebssystem ist Netrunner 14 Frontier (basiert auf Kubuntu 14.04). Paralell habe ich das ganze auf einem Windows Rechner (Netbook) versucht - sprich selbe Daten, selbes Netzwerk/Ort - dort geht alles ohne Probleme. Die Verbindung scheint auch problemlos zu funktionieren: Jan 6 11:28:07 rechnerxy NetworkManager[1057]: <info> Starting VPN service 'pptp'...
Jan 6 11:28:07 rechnerxy NetworkManager[1057]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 5400
Jan 6 11:28:07 rechnerxy NetworkManager[1057]: <info> VPN service 'pptp' appeared; activating connections
Jan 6 11:28:07 rechnerxy NetworkManager[1057]: <info> VPN plugin state changed: starting (3)
Jan 6 11:28:07 rechnerxy NetworkManager[1057]: <info> VPN connection 'blabla' (Connect) reply received.
Jan 6 11:28:07 rechnerxy pppd[5401]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded.
Jan 6 11:28:07 rechnerxy pppd[5401]: pppd 2.4.5 started by root, uid 0
Jan 6 11:28:07 rechnerxy pptp[5406]: nm-pptp-service-5400 log314: The synchronous pptp option is NOT activated
Jan 6 11:28:07 rechnerxy pppd[5401]: Using interface ppp0
Jan 6 11:28:07 rechnerxy pppd[5401]: Connect: ppp0 <--> /dev/pts/2
Jan 6 11:28:07 rechnerxy NetworkManager[1057]: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
Jan 6 11:28:07 rechnerxy NetworkManager[1057]: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
Jan 6 11:28:07 rechnerxy NetworkManager[1057]: <warn> /sys/devices/virtual/net/ppp0: couldn't determine device driver; ignoring...
Jan 6 11:28:08 rechnerxy pptp[5421]: nm-pptp-service-5400 log251: Sent control packet type is 1 'Start-Control-Connection-Request'
Jan 6 11:28:08 rechnerxy pptp[5421]: nm-pptp-service-5400 log739: Received Start Control Connection Reply
Jan 6 11:28:08 rechnerxy pptp[5421]: nm-pptp-service-5400 log773: Client connection established.
Jan 6 11:28:09 rechnerxy pptp[5421]: nm-pptp-service-5400 log251: Sent control packet type is 7 'Outgoing-Call-Request'
Jan 6 11:28:09 rechnerxy pptp[5421]: nm-pptp-service-5400 log858: Received Outgoing Call Reply.
Jan 6 11:28:09 rechnerxy pptp[5421]: nm-pptp-service-5400 log897: Outgoing call established (call ID 0, peer's call ID 63214).
Jan 6 11:28:12 rechnerxy pppd[5401]: CHAP authentication succeeded
Jan 6 11:28:12 rechnerxy kernel: [ 7290.165826] PPP MPPE Compression module registered
Jan 6 11:28:12 rechnerxy pppd[5401]: MPPE 128-bit stateless compression enabled
Jan 6 11:28:12 rechnerxy pppd[5401]: local IP address 10.23.23.52
Jan 6 11:28:12 rechnerxy pppd[5401]: remote IP address 10.23.23.50
Jan 6 11:28:12 rechnerxy pppd[5401]: primary DNS address 8.8.8.8
Jan 6 11:28:12 rechnerxy pppd[5401]: secondary DNS address 8.8.4.4
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> VPN connection 'blabla' (IP4 Config Get) reply received from old-style plugin.
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> VPN Gateway: 46.59.169.149
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Tunnel Device: ppp0
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> IPv4 configuration:
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Internal Address: 10.23.23.52
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Internal Prefix: 32
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Internal Point-to-Point Address: 10.23.23.50
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Maximum Segment Size (MSS): 0
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Forbid Default Route: no
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Internal DNS: 8.8.8.8
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> Internal DNS: 8.8.4.4
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> DNS Domain: '(none)'
Jan 6 11:28:12 rechnerxy NetworkManager[1057]: <info> No IPv6 configuration
Jan 6 11:28:13 rechnerxy NetworkManager[1057]: <info> VPN connection 'blabla' (IP Config Get) complete.
Jan 6 11:28:13 rechnerxy NetworkManager[1057]: <info> Policy set 'blabla' (ppp0) as default for IPv4 routing and DNS.
Jan 6 11:28:13 rechnerxy NetworkManager[1057]: <info> Writing DNS information to /sbin/resolvconf
Jan 6 11:28:13 rechnerxy dnsmasq[1547]: setting upstream servers from DBus
Jan 6 11:28:13 rechnerxy dnsmasq[1547]: using nameserver 8.8.4.4#53
Jan 6 11:28:13 rechnerxy dnsmasq[1547]: using nameserver 8.8.8.8#53
Jan 6 11:28:13 rechnerxy NetworkManager[1057]: <info> VPN plugin state changed: started (4)
Jan 6 11:28:13 rechnerxy dbus[776]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jan 6 11:28:13 rechnerxy dbus[776]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jan 6 11:28:19 rechnerxy ntpdate[5487]: adjust time server 91.189.94.4 offset -0.052041 sec Ein Aufruf z.b. von einer owncloud Installation auf dem Server im Browser (Firefox, Chromium oder Web Browser) funktioniert nicht (Firefox: unable to connect, Web Browser: Connection to Server Refused, Chromium : This webpage is not available). Ebenso führt ein ping serverip zu "Destination Host Unreachable". Beides (Browser und ping) funktioniert wenn ich den Windows Rechner ans Netzwerkkabel hänge ohne Murren. Ich bin VPN-Neuling - aber da es auf anderen Rechnern problemlos funktioniert und auch die Verbindung scheinbar steht - aber halt wie gesagt sich keine Inhalte aufrufen lassen, die auf dem Server sind, konnte ich bisher keine Lösung für das Problem finden. Bin für jeden Tip dankbar.
Bearbeitet von tomtomtom: Codeblock auf Wunsch des TEs korrigiert.
|
Lidux
Anmeldungsdatum: 18. April 2007
Beiträge: 15844
|
Hallo kaktux, Zeige bitte mal die Ausgabe von: lsmod Gruss Lidux
|
kaktux
(Themenstarter)
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
lsmod liefert: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85 | Module Size Used by
arc4 12608 2
ppp_mppe 13002 2
ppp_async 17413 1
crc_ccitt 12707 1 ppp_async
nls_iso8859_1 12713 1
usb_storage 62209 1
pci_stub 12622 1
vboxpci 23194 0
vboxnetadp 25670 0
vboxnetflt 27613 0
vboxdrv 339502 3 vboxnetadp,vboxnetflt,vboxpci
deflate 12617 0
ctr 13049 0
twofish_generic 16635 0
twofish_x86_64_3way 27146 0
twofish_x86_64 12907 1 twofish_x86_64_3way
twofish_common 21113 3 twofish_generic,twofish_x86_64_3way,twofish_x86_64
camellia_generic 29348 0
camellia_x86_64 52986 0
serpent_sse2_x86_64 50408 0
xts 12914 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
serpent_generic 29823 1 serpent_sse2_x86_64
lrw 13286 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
gf128mul 14951 2 lrw,xts
glue_helper 13990 3 camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
bnep 19624 2
blowfish_generic 12530 0
blowfish_x86_64 21312 0
blowfish_common 16739 2 blowfish_generic,blowfish_x86_64
cast5_generic 21429 0
cast_common 12983 1 cast5_generic
ablk_helper 13597 1 serpent_sse2_x86_64
des_generic 21379 0
cmac 12788 0
xcbc 12815 0
rmd160 16744 0
crypto_null 12840 0
af_key 36043 2
xfrm_algo 15394 1 af_key
rfcomm 69160 0
bluetooth 391136 10 bnep,rfcomm
binfmt_misc 17468 1
snd_hda_codec_hdmi 46368 1
snd_hda_codec_realtek 65580 1
intel_rapl 18773 0
snd_hda_intel 56451 3
coretemp 13435 0
snd_hda_codec 192906 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
snd_hwdep 13602 1 snd_hda_codec
kvm_intel 143187 0
kvm 455835 1 kvm_intel
crct10dif_pclmul 14289 0
snd_pcm 102099 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
crc32_pclmul 13113 0
snd_page_alloc 18710 2 snd_pcm,snd_hda_intel
ghash_clmulni_intel 13216 0
cryptd 20359 2 ghash_clmulni_intel,ablk_helper
snd_seq_midi 13324 0
snd_seq_midi_event 14899 1 snd_seq_midi
snd_rawmidi 30144 1 snd_seq_midi
snd_seq 61560 2 snd_seq_midi_event,snd_seq_midi
snd_seq_device 14497 3 snd_seq,snd_rawmidi,snd_seq_midi
serio_raw 13462 0
snd_timer 29482 2 snd_pcm,snd_seq
snd 69322 17 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_seq_midi
soundcore 12680 1 snd
parport_pc 32701 1
ppdev 17671 0
mac_hid 13205 0
lp 17759 0
parport 42348 3 lp,ppdev,parport_pc
hid_generic 12548 0
usbhid 52659 0
hid 106148 2 hid_generic,usbhid
i915 784207 4
psmouse 106714 0
i2c_algo_bit 13413 1 i915
r8169 67581 0
drm_kms_helper 55071 1 i915
mii 13934 1 r8169
drm 303102 5 i915,drm_kms_helper
ahci 25819 2
libahci 32716 1 ahci
video 19476 1 i915
|
gruss
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
Denkbare Fehlerquellen: 1. Routing defekt 2. Namensauflösung (DNS) defekt 3. Netfilter (iptables) blockiert Diagnose zu 1: Zeig mal die Ausgabe von
vor und nach dem Aufbau des Tunnels. zu 2: Zeig bitte die Ausgabe von:
zu 3: Zeig bitte die Ausgabe von:
|
kaktux
(Themenstarter)
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
ip route: nicht verbunden | default via 192.168.178.1 dev eth0 proto static
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.32 metric 1
|
verbunden
| default dev ppp0 proto static
10.23.23.50 dev ppp0 proto kernel scope link src 10.23.23.51
46.59.169.149 via 192.168.178.1 dev eth0 proto static
46.59.169.149 via 192.168.178.1 dev eth0 src 192.168.178.32
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.32 metric 1
|
dig ubuntuusers.de: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 | ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> ubuntuusers.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 422
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ubuntuusers.de. IN A
;; ANSWER SECTION:
ubuntuusers.de. 3374 IN A 213.95.41.4
;; Query time: 48 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Tue Jan 06 18:38:02 CET 2015
;; MSG SIZE rcvd: 59
|
sudo iptables -S
| -P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
|
gruß
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
Das sieht alles gut aus. Ist 46.59.169.149 die IP-Adresse des PPTP-Servers? Ungewöhnlich erscheint mir nur, dass die Route zum Server in Zeile 3 und 4 auftaucht; eigentlich erwarte ich eine Zeile, etwa in der Art: 46.59.169.149 via 192.168.178.1 dev eth0 src 192.168.178.32 proto static Ich vermute hier nicht die Ursache, aber vielleicht hilft es, die Route zum Server manuell schon vor dem Aufbau des Tunnels zu setzen:
sudo ip route add 46.59.169.149 via 192.168.178.1 dev eth0 Gibt es einen Unterschied beim Befehl
dig ubuntuusers.de
vor bzw. nach dem Aufbau des Tunnels?
|
kaktux
(Themenstarter)
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
wenn ich wüßte wie ich die IP des pptp Servers rausfinde 😉 - jedenfalls nutzen wir dafür spdns.de - einen dyn-dns anbieter. | sudo ip route add 46.59.169.149 via 192.168.178.1 dev eth0
|
vor dem Aufbau hilft leider nicht. dig ubuntuusers.de - Unterschiede habe ich fett markiert. davor 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 | ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> ubuntuusers.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2382
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ubuntuusers.de. IN A
;; ANSWER SECTION:
ubuntuusers.de. 75816 IN A 213.95.41.4
;; Query time: 53 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Jan 06 19:44:47 CET 2015
;; MSG SIZE rcvd: 59
|
danach
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 | ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> ubuntuusers.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16935
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ubuntuusers.de. IN A
;; ANSWER SECTION:
ubuntuusers.de. 12555 IN A 213.95.41.4
;; Query time: 47 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Tue Jan 06 19:45:25 CET 2015
;; MSG SIZE rcvd: 59
|
Unterschiede dabei sind:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2382 gegen
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16935
; EDNS: version: 0, flags:; udp: 4096 gegen
; EDNS: version: 0, flags:; udp: 512
ubuntuusers.de. 75816 IN A 213.95.41.4 gegen
ubuntuusers.de. 12555 IN A 213.95.41.4
;; SERVER: 208.67.222.222#53(208.67.222.222) gegen
;; SERVER: 127.0.1.1#53(127.0.1.1)
|
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
Die IP-Adresse zu einem DNS-Namen liefert der Befehl dig, der eben die DNS-Server befragt. Beispiel:
dig ubuntuusers.de
liefert 213.95.41.4:
…
;; ANSWER SECTION:
ubuntuusers.de. 75816 IN A '''213.95.41.4'''
…
Alternativ kann man auch das Programm host benutzen; es liefert gegenüber dig eine übersichtlichere, aber weniger ausführlichere Antwort. Die Situation ist nun so, dass bei aktivem Tunnel ein vom Network-Manager gestarteter DNS-Cache (dnsmasq) unter der lokalen IP 127.0.1.1 befragt wird. Um ganz sicher zu sein, versuche mal den DNS-Server von Google direkt zu befragen:
dig ubuntuusers.de @8.8.8.8
|
kaktux
(Themenstarter)
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
dig ubuntuusers.de @8.8.8.8: nicht verbunden:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 |
; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> ubuntuusers.de @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54236
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ubuntuusers.de. IN A
;; ANSWER SECTION:
ubuntuusers.de. 17197 IN A 213.95.41.4
;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jan 06 20:22:17 CET 2015
;; MSG SIZE rcvd: 59
|
verbunden: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 | ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> ubuntuusers.de @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11595
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ubuntuusers.de. IN A
;; ANSWER SECTION:
ubuntuusers.de. 16315 IN A 213.95.41.4
;; Query time: 51 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jan 06 20:23:12 CET 2015
;; MSG SIZE rcvd: 59
|
die IP 46.59.169.149 gehört scheinbar zu dem Anschluss wo der Server steht - das kommt von den Daten hin. Unverbunden habe ich eine andre.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
OK. Damit haben wir jetzt im verbundenen Zustand: default Route geht in den Tunnel, d.h. i.d.F. jeder Verkehr geht durch den Tunnel. Namensauflösung funktioniert durch den Tunnel. Netfilter ist komplett durchlässig.
Die von mir genannten 3 möglichen Fehlerquellen sind damit alle ausgeschlossen. Obwohl wir nichts verändert haben, vermute ich, dass jetzt alles funktioniert. Bitte prüfe das erneut (ping, Browser). Neuer Ansatz zur Fehlersuche: Du benutzt MS Windows und Linux.
Unter Linux erfährst Du die eigenen Netzwerk-Adressen so:
| ip addr
ip addr show dev eth0
ip -4 addr show dev eth0
|
Der erste Befehl zeigt alle Adressen für den Rechner, der zweite alle für das Interface eth0, und der dritte zeigt nur die IP-Adressen (IP Version 4) für das Interface eth0.
|
kaktux
(Themenstarter)
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
Es sind zwei verschiedene Rechner - der eine ist für unterwegs (Netbook, momentan Windows drauf), mit dem andren arbeite ich von zu Haus (Netrunner/Kubuntu).
Ips sind eigentlich keine festen - DHCP. Damit sollten die IPs eigentlich unterschiedlich sein oder? Beide am selben, unterschiedlichen Kabeln bzw. das Netbook per WLan getestet. Linux (vpn verbunden):
ip addr
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether d0:50:99:35:6e:66 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.32/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::d250:99ff:fe35:6e66/64 scope link
valid_lft forever preferred_lft forever
3: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN group default qlen 3
link/ppp
inet 10.23.23.52 peer 10.23.23.50/32 brd 10.23.23.52 scope global ppp0
valid_lft forever preferred_lft forever
|
ip addr show dev eth0
| 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether d0:50:99:35:6e:66 brd ff:ff:ff:ff:ff:ff
inet 192.168.178.32/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::d250:99ff:fe35:6e66/64 scope link
valid_lft forever preferred_lft forever
|
ip -4 addr show dev eth0
| 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.178.32/24 brd 192.168.178.255 scope global eth0
valid_lft forever preferred_lft forever
|
Der Windows Rechner hat paralell dazu die IP 192.168.178.24
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8554
Wohnort: Münster
|
Ich vermute, die Fehlfunktion entsteht durch den Umstand, dass zwei Geräte im Netz hinter einem NAT-Router PPTP nutzen wollen. Bezüglich dieser Situation - PPTP durch NAT-Router - gilt jedoch die Regel: „Es kann nur Einen geben!“ Das hat nichts mit MS Windows und auch nichts mit Linux zu tun, sondern beruht auf der Funktionsweise der beiden Verfahren NAT und PPTP, die nur mit Einschränkung miteinander funktionieren: Der NAT-Router (v.B. Fritzbox) setzt die im lokalen Netz verwendeten IP-Adressen bei ausgehenden IP-Paketen um auf die einzige extern sichtbare, vom Provider zugewiesene IP-Adresse und bei eingehenden IP-Paketen diese externe Adresse um auf die jeweils richtige interne Adresse. Damit das funktioniert, muss sich der Router merken, welche interne IP-Adresse mit welcher Zieladresse kommunziert. Er benutzt dazu bei einem internen Rechner das Verfahren NAT, bei mehreren internen Rechnern für Port-nutzende Protokolle wie z.B. TCP/IP oder UDP/IP das Verfahren NAPT, bei dem zusätzlich der Quellport vom Router umgeschrieben wird. PPTP verpackt die PPP-Pakete in GRE/IP (GRE Version 1 nach RFC-2637). GRE kennt jedoch keine Ports wie TCP oder UDP, womit nur NAT, aber kein NAPT technisch möglich ist. Damit kann nur ein Rechner durch den NAT-Router einen PPTP-Tunnel nutzen. (Das ist etwas vereinfacht, ein besserer Router könnte die Call-ID im GRE-Header in ähnlicher Weise wie einen Quellport umschreiben und somit mehrere PPTP-Verbindungen ermöglichen. Meine Fritzbox macht das aber jedenfalls nicht.) Vorschlag für das weitere Vorgehen:
PPTP über MS Windows nicht nutzen. Abwarten, bis der NAT-Router eine frühere PPTP-Verbindung vergißt. Ich habe keine Vorstellung, wie lange das bei einer Fritzbox dauert. PPTP über Linux aufbauen. Ich vermute nach den bisherigen Experimenten, dass es dann funktioniert. Zukünftig in Deinem privaten LAN immer nur einen Rechner mit immer derselben IP-Adresse für PPTP nutzen.
|
kaktux
(Themenstarter)
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
Erstmal: vielen Dank für deine Hilfe!! Aber das es daran liegen könnte ist eigentlich unlogisch. Den unter Linux habe ich es zuerst versucht - und von vornerein diese Probleme gehabt. Erst dann habe ich es auch auf dem Windows Rechner probiert - und da ging es dann halt direkt ohne Probleme.
Seitdem schaue ich auf beiden Rechnern abwechselnd - das stimmt - aber wie gesagt hat sich beim Linux Rechner nichts verändert und das Problem bestand von vornerein.
Dementsprechend dürfte man mit der Erklärung dann ja auch von einer externen Filiale in der z.b. 3-4 Rechner stehen, die alle den Server nutzen wollen nicht arbeiten können oder? Das wäre in meinen Augen auch nicht unbedingt logisch - dann wäre das Verfahren für jede Firma mit einem externen Hauptrechner und mehr als einem Mitarbeiter pro Filiale ja unbrauchbar. Es sei den das hängt auch vom Router ab - den da hängt vor dem Server auch keine Fritz-Box. Aber ich lasse Windows jetzt auch erstmal weg - und starte die Fritz-Box mal neu (vielleicht sind dann ja alte Verbindungen schon gelöscht). Was ich allerdings gerade probieren will - mein Kollege nutzt nicht Netrunner (was auf Kubuntu 14.04 aufbaut) sondern Kubuntu direkt - und hat es da auch schon erfolgreich zum laufen gebracht (mobil sowie über WLan von Ort xy eingewählt). Vielleicht kann man das ja von einem Live-USB Stick testen - daher lade auch gerade ein Kubuntu Iso-Image runter - das ich dann auf beiden Rechnern testen werde (sowie Netrunner per Live-USB auf dem Netbook). Wobei ich da nicht weiß, ob pptp überhaupt von vornerein installiert ist. Versuch macht kluch 😉 Prinzipiell will ich ja auch nur den einen Rechner (und nicht den mobilen) im Haus nutzen.
|
praseodym
Supporter
Anmeldungsdatum: 9. Februar 2009
Beiträge: 22096
Wohnort: ~
|
Ist die LZO-Komprimierung auf dem Server aktiv? Falls ja, diese auch im Netzwerkmanager aktivieren.
|
kaktux
(Themenstarter)
Anmeldungsdatum: 16. Januar 2006
Beiträge: 223
|
BSD, Deflate und TCP Header Komprimierung habe ich in den Einstellungen zur Verfügung (im Connection Editor, Tab VPN pptp → Advanced) - aber LZO nicht.
|