Etwas verzwicktes Routing-Problem
Hallo zusammen, hier besteht ein Routing-Problem, von dem ich nicht weiß, woran es liegt und wie ich es eingrenzen kann. Hier eine Zeichnung: Road-Warrior | | 10.8.0.6 | | (OpenVPN-Endpunkt) (Routing-Tabelle*) | | | | | | 10.8.0.1 / -------------------- | | OpenVPN-Router | | -------------------- |LAN1 | 192.168.0.199 | | Standardgateway: 192.168.0.200 | Client----\ | | 192.168.0.20 | | | | | 192.168.0.200 | -------------------- \ | VPN-Gateway1 | -------------------- | | \ | | \-->Internet | |VPN | | /-->Internet | | / / -------------------- | | VPN-Gateway2 | | -------------------- | | 192.168.8.254 | | |LAN2 | | | 192.168.8.253 | | Standard-Gateway: 192.168.8.254 | -------------------- | | Ziel-Server | \ -------------------- Ziel ist, daß der Road Warrior sich mit dem Ziel-Server unterhalten kann, was nicht funktioniert. Derzeit sieht es so aus: Pings von oben nach unten: Ping Road Warrior => VPN-Gateway1 (klappt) Ping Road Warrior => Client (klappt) Ping OpenVPN-Rout.=> Ziel-Server (klappt) Ping Road Warrior => Ziel-Server (klappt nicht) Pings von unten nach oben: Ping Ziel-Server => 192.168.0.199 (klappt) Ping Ziel-Server => 10.8.0.1 (klappt nicht, obwohl kommt: # ping 10.8.0.1 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. From 192.168.8.254: icmp_seq=1 Redirect Host(New nexthop: 192.168.0.199) Trotzdem kriege ich 100% Paket loss. Wieso ist diese Adresse nicht pingbar? Ping Client => 192.168.0.199 (klappt, klar) Ping Client => 10.8.0.1 (klappt, fast klar, liegt an der Routingtabelle von VPN-Gateway1, denn es kommt: PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data. From 192.168.0.200: icmp_seq=1 Redirect Host(New nexthop: 192.168.0.199) 64 bytes from 10.8.0.6: icmp_seq=1... Ping Client => 10.8.0.6 (klappt, wow, OpenVPN-Router schafft es, die Pakete in den Tunnel zum Road Warrior zu schaufeln!) Also kurz gesagt: LAN1 kann LAN2 pingen und umgekehrt, und das 10.8.0.0er Netz kann LAN1 pingen und umgekehrt. Aber LAN2 sieht das 10.8.0.0er Netz nicht und umgekehrt. Tja, ich hoffe, es liest jemand bis hierher, und kann mir sagen, wo es hakt, bzw. wie ich es herausfinden kann. Im Moment steh ich jedenfalls auf dem Schlauch und weiß nicht, wie ich rauskriegen könnte, wo die Pakete hängenbleiben. Danke und Gruß. (*) Routing-Tabelle von Road Warrior: Netzwerkziel Netzwerkmaske Gateway Schnittstelle 192.168.0.0 255.255.255.0 10.8.0.5 10.8.0.6 192.168.8.0 255.255.255.0 10.8.0.5 10.8.0.6 -- Andre Tann -- 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
Am Dienstag 27 Mai 2008 14:52:05 schrieb Andre Tann:
Hallo zusammen,
hier besteht ein Routing-Problem, von dem ich nicht weiß, woran es liegt und wie ich es eingrenzen kann. Hier eine Zeichnung:
Road-Warrior
| | 10.8.0.6 | | (OpenVPN-Endpunkt) (Routing-Tabelle*) | | | | | | 10.8.0.1
/ --------------------
| | OpenVPN-Router | | | -------------------- |LAN1 | 192.168.0.199 | | | Standardgateway: 192.168.0.200 | | Client----\ | | 192.168.0.20 | | | | | | 192.168.0.200 | | --------------------
\ | VPN-Gateway1 | --------------------
| | \ | | \-->Internet | |VPN | | /-->Internet | | /
/ --------------------
| | VPN-Gateway2 | | | -------------------- | | | 192.168.8.254 | |LAN2 | | | | 192.168.8.253 | | Standard-Gateway: 192.168.8.254 | | -------------------- | | | Ziel-Server |
\ --------------------
Ziel ist, daß der Road Warrior sich mit dem Ziel-Server unterhalten kann, was nicht funktioniert.
Derzeit sieht es so aus:
Pings von oben nach unten: Ping Road Warrior => VPN-Gateway1 (klappt) Ping Road Warrior => Client (klappt) Ping OpenVPN-Rout.=> Ziel-Server (klappt) Ping Road Warrior => Ziel-Server (klappt nicht)
Pings von unten nach oben: Ping Ziel-Server => 192.168.0.199 (klappt) Ping Ziel-Server => 10.8.0.1 (klappt nicht, obwohl kommt: # ping 10.8.0.1 PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. From 192.168.8.254: icmp_seq=1 Redirect Host(New nexthop: 192.168.0.199) Trotzdem kriege ich 100% Paket loss. Wieso ist diese Adresse nicht pingbar?
Ping Client => 192.168.0.199 (klappt, klar) Ping Client => 10.8.0.1 (klappt, fast klar, liegt an der Routingtabelle von VPN-Gateway1, denn es kommt:
PING 10.8.0.6 (10.8.0.6) 56(84) bytes of data. From 192.168.0.200: icmp_seq=1 Redirect Host(New nexthop: 192.168.0.199) 64 bytes from 10.8.0.6: icmp_seq=1...
Ping Client => 10.8.0.6 (klappt, wow, OpenVPN-Router schafft es, die Pakete in den Tunnel zum Road Warrior zu schaufeln!)
Also kurz gesagt: LAN1 kann LAN2 pingen und umgekehrt, und das 10.8.0.0er Netz kann LAN1 pingen und umgekehrt. Aber LAN2 sieht das 10.8.0.0er Netz nicht und umgekehrt.
Tja, ich hoffe, es liest jemand bis hierher, und kann mir sagen, wo es hakt, bzw. wie ich es herausfinden kann. Im Moment steh ich jedenfalls auf dem Schlauch und weiß nicht, wie ich rauskriegen könnte, wo die Pakete hängenbleiben.
Danke und Gruß.
(*) Routing-Tabelle von Road Warrior: Netzwerkziel Netzwerkmaske Gateway Schnittstelle 192.168.0.0 255.255.255.0 10.8.0.5 10.8.0.6 192.168.8.0 255.255.255.0 10.8.0.5 10.8.0.6
-- Andre Tann
Hallo Andre Gateway 10.8.0.5 wie in der Routingtabelle oder 10.8.0.1, wie im Bild für den OpenVPN-Router abgegeben ? Wer ist 10.8.0.5? Kann es daran liegen? Vielleicht auch nur im Eintrag für 192.168.8.0. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- 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
Emil Stephan, Dienstag, 27. Mai 2008 17:27:
Gateway 10.8.0.5 wie in der Routingtabelle oder 10.8.0.1, wie im Bild für den OpenVPN-Router abgegeben ? Wer ist 10.8.0.5?
Tja, gute Frage. Beim Road Warrior: c:\ipconfig /all [...] Ethernetadapter LAN-Verbindung 2: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V8 Physikalische Adresse . . . . . . : 00-FF-B5-2F-79-06 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse. . . . . . . . . . . . : 10.8.0.6 Subnetzmaske. . . . . . . . . . . : 255.255.255.252 Standardgateway . . . . . . . . . : DHCP-Server . . . . . . . . . . . : 10.8.0.5 DNS-Server. . . . . . . . . . . . : 192.168.0.201 [...] Andererseits auf dem OpenVPN-Gateway: # ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:01:03:48:3B:F6 inet Adresse:192.168.0.199 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::201:3ff:fe48:3bf6/64 Gültigkeitsbereich:Verbindung [...] lo Protokoll:Lokale Schleife [...] tun0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255 [...] Das bedeutet, daß das OpenVPN-Gateway die 10.8.0.6 nicht kennt. Keine Ahnung, wo die herkommt. Das mag ja irgend eine Besonderheit von OpenVPN sein. Danke+Gruß. -- Andre Tann -- 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
Hallo Andre, siehe Kommentare unten. Tschö, Emil Am Mittwoch 28 Mai 2008 16:10:13 schrieb Andre Tann:
Emil Stephan, Dienstag, 27. Mai 2008 17:27:
Gateway 10.8.0.5 wie in der Routingtabelle oder 10.8.0.1, wie im Bild für den OpenVPN-Router abgegeben ? Wer ist 10.8.0.5?
Tja, gute Frage. Beim Road Warrior:
c:\ipconfig /all [...] Ethernetadapter LAN-Verbindung 2:
Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V8 Physikalische Adresse . . . . . . : 00-FF-B5-2F-79-06 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse. . . . . . . . . . . . : 10.8.0.6 Subnetzmaske. . . . . . . . . . . : 255.255.255.252 Standardgateway . . . . . . . . . : DHCP-Server . . . . . . . . . . . : 10.8.0.5 DNS-Server. . . . . . . . . . . . : 192.168.0.201 [...] an dem Subnetz sind nur 4 Adressen möglich, 2 davon gehen für Broadcast drauf, also bleiben 2 nutzbare Adressen. hier die 5 und die 6, 4 und 7 sind Broadcast-Adressen. Entweder Subnetzmaske auf 255.255.255.248 ändern oder dem VPN-Router die 10.8.0.5 verpassen. Im ersteren Fall sind die Adressen 1 bis 6 nutzbar.
Andererseits auf dem OpenVPN-Gateway:
# ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:01:03:48:3B:F6 inet Adresse:192.168.0.199 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::201:3ff:fe48:3bf6/64 Gültigkeitsbereich:Verbindung [...]
lo Protokoll:Lokale Schleife [...]
tun0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255 [...] mit tun's und tap's habe ich noch nichts gemacht, daher weiss ich auch nicht, wie eine Hardware-Adresse davon aussieht und woher man sie bekommt. Und P-z-P heisst wohl Punkt zu Punkt; und die 10.8.0.2 wäre dann die Adresse am anderen Punkt.
Das bedeutet, daß das OpenVPN-Gateway die 10.8.0.6 nicht kennt. Keine Ahnung, wo die herkommt. Das mag ja irgend eine Besonderheit von OpenVPN sein.
Danke+Gruß.
-- Andre Tann
-- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- 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
Emil Stephan schrieb:
Hallo Andre, siehe Kommentare unten. Tschö, Emil
Am Mittwoch 28 Mai 2008 16:10:13 schrieb Andre Tann:
Emil Stephan, Dienstag, 27. Mai 2008 17:27:
Gateway 10.8.0.5 wie in der Routingtabelle oder 10.8.0.1, wie im Bild für den OpenVPN-Router abgegeben ? Wer ist 10.8.0.5?
Tja, gute Frage. Beim Road Warrior:
erst mal ...das ist keine (win)Routing Tabelle ! daztu verwendet man route print!
c:\ipconfig /all [...] Ethernetadapter LAN-Verbindung 2:
Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V8 Physikalische Adresse . . . . . . : 00-FF-B5-2F-79-06 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse. . . . . . . . . . . . : 10.8.0.6 Subnetzmaske. . . . . . . . . . . : 255.255.255.252 Standardgateway . . . . . . . . . : DHCP-Server . . . . . . . . . . . : 10.8.0.5 DNS-Server. . . . . . . . . . . . : 192.168.0.201 [...]
an dem Subnetz sind nur 4 Adressen möglich, 2 davon gehen für Broadcast drauf, also bleiben 2 nutzbare Adressen. hier die 5 und die 6, 4 und 7 sind Broadcast-Adressen. Entweder Subnetzmaske auf 255.255.255.248 ändern oder dem VPN-Router die 10.8.0.5 verpassen. Im ersteren Fall sind die Adressen 1 bis 6 nutzbar.
nee nee ... dann wirst du deinem VPN-Server ein Push route bebringen müssen - siónst verwendet er für alles ausser 10.8.0.0/24 eben das 192.168er Standardgateway ! aber: route # standardgateway
Andererseits auf dem OpenVPN-Gateway:
# ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:01:03:48:3B:F6 inet Adresse:192.168.0.199 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::201:3ff:fe48:3bf6/64 Gültigkeitsbereich:Verbindung [...]
lo Protokoll:Lokale Schleife [...]
tun0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255 [...]
sieht bei mir auch so ähnlich aus... mit tun's und tap's habe ich noch nichts gemacht, daher weiss ich auch nicht, wie eine Hardware-Adresse davon aussieht und woher man sie bekommt. Und P-z-P heisst wohl Punkt zu Punkt; und die 10.8.0.2 wäre dann die Adresse am anderen Punkt.
Das bedeutet, daß das OpenVPN-Gateway die 10.8.0.6 nicht kennt. Keine Ahnung, wo die herkommt. Das mag ja irgend eine Besonderheit von OpenVPN sein.
Danke+Gruß.
-- Andre Tann
Ehmm du darfst natürlich auf dem Roadwarrior allen Anfrage direkt ins INet gehen ... und nur das VPN-Zeugs durch den Tunnel jagen... ..aber eigentlich kann man dann die Firewalls auch gleich weglassen... 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
Hallo Fred, die 10.8.0.5 war als IP-Adresse gemeint, nich in Form einer Route. Tschö, Emil Am Mittwoch 28 Mai 2008 19:41:54 schrieb Fred Ockert:
Emil Stephan schrieb:
Hallo Andre, siehe Kommentare unten. Tschö, Emil
Am Mittwoch 28 Mai 2008 16:10:13 schrieb Andre Tann:
Emil Stephan, Dienstag, 27. Mai 2008 17:27:
Gateway 10.8.0.5 wie in der Routingtabelle oder 10.8.0.1, wie im Bild für den OpenVPN-Router abgegeben ? Wer ist 10.8.0.5?
Tja, gute Frage. Beim Road Warrior:
erst mal ...das ist keine (win)Routing Tabelle ! daztu verwendet man route print!
c:\ipconfig /all [...] Ethernetadapter LAN-Verbindung 2:
Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V8 Physikalische Adresse . . . . . . : 00-FF-B5-2F-79-06 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja IP-Adresse. . . . . . . . . . . . : 10.8.0.6 Subnetzmaske. . . . . . . . . . . : 255.255.255.252 Standardgateway . . . . . . . . . : DHCP-Server . . . . . . . . . . . : 10.8.0.5 DNS-Server. . . . . . . . . . . . : 192.168.0.201 [...]
an dem Subnetz sind nur 4 Adressen möglich, 2 davon gehen für Broadcast drauf, also bleiben 2 nutzbare Adressen. hier die 5 und die 6, 4 und 7 sind Broadcast-Adressen. Entweder Subnetzmaske auf 255.255.255.248 ändern oder dem VPN-Router die 10.8.0.5 verpassen. Im ersteren Fall sind die Adressen 1 bis 6 nutzbar.
nee nee ... dann wirst du deinem VPN-Server ein Push route bebringen müssen - siónst verwendet er für alles ausser
10.8.0.0/24 eben das 192.168er Standardgateway ! aber: route # standardgateway
Andererseits auf dem OpenVPN-Gateway:
# ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:01:03:48:3B:F6 inet Adresse:192.168.0.199 Bcast:192.168.0.255 Maske:255.255.255.0 inet6 Adresse: fe80::201:3ff:fe48:3bf6/64 Gültigkeitsbereich:Verbindung [...]
lo Protokoll:Lokale Schleife [...]
tun0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255 [...]
sieht bei mir auch so ähnlich aus...
mit tun's und tap's habe ich noch nichts gemacht, daher weiss ich auch nicht, wie eine Hardware-Adresse davon aussieht und woher man sie bekommt. Und P-z-P heisst wohl Punkt zu Punkt; und die 10.8.0.2 wäre dann die Adresse am anderen Punkt.
Das bedeutet, daß das OpenVPN-Gateway die 10.8.0.6 nicht kennt. Keine Ahnung, wo die herkommt. Das mag ja irgend eine Besonderheit von OpenVPN sein.
Danke+Gruß.
-- Andre Tann
Ehmm du darfst natürlich auf dem Roadwarrior allen Anfrage direkt ins INet gehen ... und nur das VPN-Zeugs durch den Tunnel jagen... ..aber eigentlich kann man dann die Firewalls auch gleich weglassen...
Fred
-- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- 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
Andre Tann schrieb:
Hallo zusammen,
hier besteht ein Routing-Problem, von dem ich nicht weiß, woran es liegt und wie ich es eingrenzen kann. Hier eine Zeichnung:
schööön,
Road-Warrior | | 10.8.0.6 | | (OpenVPN-Endpunkt) (Routing-Tabelle*) | | | | | | 10.8.0.1 / -------------------- | | OpenVPN-Router | | -------------------- |LAN1 | 192.168.0.199 | | Standardgateway: 192.168.0.200 | Client----\ | | 192.168.0.20 | | | | | 192.168.0.200 | -------------------- \ | VPN-Gateway1 | -------------------- | | \ | | \-->Internet | |VPN | | /-->Internet | | / / -------------------- | | VPN-Gateway2 | | -------------------- | | 192.168.8.254 | | |LAN2 | | | 192.168.8.253 | | Standard-Gateway: 192.168.8.254 | -------------------- | | Ziel-Server | \ --------------------
Ziel ist, daß der Road Warrior sich mit dem Ziel-Server unterhalten kann, was nicht funktioniert.
Derzeit sieht es so aus:
Pings von oben nach unten: Ping Road Warrior => VPN-Gateway1 (klappt) Ping Road Warrior => Client (klappt) Ping OpenVPN-Rout.=> Ziel-Server (klappt) Ping Road Warrior => Ziel-Server (klappt nicht)
Pings von unten nach oben:
Ping ist schön ...traceroute wäre besser!
Ping Ziel-Server => 192.168.0.199 (klappt) Ping Ziel-Server => 10.8.0.1 (klappt nicht, obwohl kommt: .............
Also kurz gesagt: LAN1 kann LAN2 pingen und umgekehrt, und das 10.8.0.0er Netz kann LAN1 pingen und umgekehrt. Aber LAN2 sieht das 10.8.0.0er Netz nicht und umgekehrt.
Tja, ich hoffe, es liest jemand bis hierher, und kann mir sagen, wo es hakt, bzw. wie ich es herausfinden kann. Im Moment steh ich jedenfalls auf dem Schlauch und weiß nicht, wie ich rauskriegen könnte, wo die Pakete hängenbleiben.
Danke und Gruß.
(*) Routing-Tabelle von Road Warrior: Netzwerkziel Netzwerkmaske Gateway Schnittstelle 192.168.0.0 255.255.255.0 10.8.0.5 10.8.0.6 192.168.8.0 255.255.255.0 10.8.0.5 10.8.0.6
also wenn schon: dann die Routing-Tabellen von allen beteiligten Maschinen 10.8.0.1 192.168.0.200 192.168.8.254 192.168.8.253 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!? auch die Beiden Gateways sollten die Route kennen.... Ich hoffe erst mal, dass das keine dyndns- adressen sind .. das wird nur fummeliger... Fred ach .. bin morgen + übermogen wohl zum Linuxtag ......es dauert also... -- 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
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 * * * 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.
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 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
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 192.168.8.254 255.255.255.255 0.0.0.0 LAN [...] 255.255.255.255 255.255.255.255 0.0.0.0 LAN
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
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.
auch die Beiden Gateways sollten die Route kennen.... Ich hoffe erst mal, dass das keine dyndns- adressen sind .. das wird nur fummeliger...
Nö, alles fix. Alles entweder LAN oder 6-MBit-Standleitungen. Bis auf die Road Warrior natürlich. Die dürften meistens UMTS-mäßig am Flughafen sitzen... Vielen Dank für Deine Unterstützung! -- Andre Tann -- 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
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
participants (3)
-
Andre Tann -
Emil Stephan -
Fred Ockert