![](https://seccdn.libravatar.org/avatar/8e9008345205e6ee86b2e3344b5dbdbc.jpg?s=120&d=mm&r=g)
Andre Tann schrieb:
Servus Fred,
Fred Ockert, Dienstag, 27. Mai 2008 20:30:
Ping ist schön ...traceroute wäre besser!
OK, here we go:
Vom Zielserver aus: ============ # traceroute -n 192.168.0.199 traceroute to 192.168.0.199 (192.168.0.199), 30 hops max, 40 byte packets 1 192.168.0.199 (192.168.0.199) 22.886 ms 21.902 ms 19.257 ms
Traceroute Zielserver => Road Warrior: # traceroute -n 10.8.0.5 traceroute to 10.8.0.5 (10.8.0.5), 30 hops max, 40 byte packets 1 * * * 2 * * *
nix gefunden... versackt..
Vom Road Warrior aus: ============= C:\>tracert 192.168.8.253 Routenverfolgung zu 192.168.8.253 [192.168.8.253] über maximal 30 Abschnitte: 1 42 ms 44 ms 9 ms 10.8.0.1 2 * * * Zeitüberschreitung der Anforderung.
C:\>tracert 192.168.0.200 Routenverfolgung zu 192.168.0.200 [192.168.0.200] über maximal 30 Abschnitte: 1 24 ms 19 ms 9 ms 10.8.0.1 2 12 ms 10 ms 11 ms 192.168.0.200 [192.168.0.200]
Ablaufverfolgung beendet.
das hat ihm einer verraten..
also wenn schon: dann die Routing-Tabellen von allen beteiligten Maschinen
OK, hier die Tabellen, ich hoffe, daß man sie lesen kann.
10.8.0.1
# route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
sehen gut aus ...
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.200 0.0.0.0 UG 0 0 0 eth0
192.168.0.200
Destination Network Subnet Mask Gateway Address Destination Link 0.0.0.0 0.0.0.0 83.236.133.105 WAN 10.8.0.0 255.255.255.0 192.168.0.199 LAN [...] 192.168.0.0 255.255.255.0 0.0.0.0 LAN 192.168.0.200 255.255.255.255 0.0.0.0 LAN [...] 255.255.255.255 255.255.255.255 0.0.0.0 LAN
der 162.168.0.200 muss aber den Weg zum 192.168.8.0/24 Netz nicht kennen ??? Ich denk die Pakete vom 10.8.0/24 laufen hiuer durch zu 192.168.8.0/24 ?? fehl also ein Eintrag in der Routing table
192.168.8.254
Destination Network Subnet Mask Gateway Address Destination Link 0.0.0.0 0.0.0.0 87.193.171.133 WAN 10.8.0.0 255.255.255.0 192.168.0.199 LAN
[...]
192.168.8.0 255.255.255.0 0.0.0.0 LAN
[...]
255.255.255.255 255.255.255.255 0.0.0.0 LAN
huch der muss den Weg zu 192.168.0.0/24 auch nicht kennen ?
192.168.8.253
# route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.8.254 0.0.0.0 UG 0 0 0 eth0
wohin soll der die Antwort auf Anfragen von 10.8.0.x schicken ??? da muss eine Zeile rein 10.8.0.0 vpn-Tunnel_eingang 255.255.255.0 gw ethx 10.8..0.0 192.168.8.254 255.255.255.0 eth0
wenn JEDE Maschine alle "Teilnehmer" kennt, klappt das. Ich vermute mal, dass der 192.168.8.253 (Zielserver) z.B. mit dem Netz 10.8.0.0/24 nix anfangen kann!?
Wieso sollte er das Netz auch kennen? Er merkt, daß er es nicht direkt erreichen kann, und wirft das Paket folglich auf das Standard-Gateway, also 192.168.8.254. Erst das Standard-Gateway muß doch wissen, wem es das Paket weiterzuleiten hat.
seitdem ich auf den Maschinen alle Netze explizit mit aufliste, geht es... traceroute sagte dir ja, dass in der Rückrichtung irgendein Problem ist... Seitdem ich mit nicht mehr darauf verlasse, das es der Router richten wird, klappt. War alles keine Problem bei einem einzigen Gateway... Habe natürlich die ASCII Grafik wieder mal nicht griffbereit..insofern hoffe ich, dass du die Maschinen in der Reihenfolge aufgelistet hattest
Vielen Dank für Deine Unterstützung!
Gruss Fred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org