An die Netzwerk-Spezi's: Hilfe bei VPN über ISDN und Satellit
Moin Moin, ich habe ein Problem beim Aufbau eines VPN-Tunnels, bei dem die Datenpakete aus dem Internet über Satellit zurückgeschickt werden sollen. Es hat AFAIK nichts mit dem Satellit zu tun sondern dreht sich eher um ein - vielleicht banales - Netzwerk-Problem, was auch mit "normalen" Netzwerk-Devices auftauchen könnte?! Kurzbeschreibung, wie die Verbindung funktionieren soll: - Über ISDN-Karte wird über einen handelsüblichen Internet-Provider die Verbindung in's Internet aufgebaut (Device ippp0). - Mit dem pptp-client wird dann ein VPN-Tunnel zum VPN-Server des Satelliten-Providers aufgebaut (Device ppp0). - Über die DVB-Karte (Device dvb0_0) sollen anschließend die Datenpakete aus dem Internet empfangen werden. Damit das funktioniert, muß das Routing etwas umgebogen werden, indem ich die Default-Route vom ippp0 wegnehme und dem ppp0 zuordne. Dadurch werden also alle ausgehenden Pakete über den Tunnel an den VPN-Server geschickt, der die Daten dann an dvb0_0 zurückrouten soll. route -n zeigt nach Verbindungsaufbau und Routingänderung folgendes: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 212.56.224.34 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 212.56.224.34 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 ^^^ IP-Adresse des VPN-Servers 62.180.158.16 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 ^^^ dynamische IP-Adresse vom Internet-Provider 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 dvb0_0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 Und das zeigt ifconfig für die drei beteiligten Interfaces: dvb0_0 Link encap:Ethernet HWaddr 00:D0:5C:02:1C:78 inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::2d0:5cff:fe02:1c78/10 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:4096 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ippp0 Link encap:Point-to-Point Protocol inet addr:62.180.160.103 P-t-P:62.180.158.16 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP DYNAMIC MTU:1500 Metric:1 RX packets:51 errors:0 dropped:0 overruns:0 frame:0 TX packets:56 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:30 RX bytes:2420 (2.3 Kb) TX bytes:2872 (2.8 Kb) ppp0 Link encap:Point-to-Point Protocol inet addr:172.24.3.129 P-t-P:212.56.224.34 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:72 (72.0 b) TX bytes:78 (78.0 b) Die IP-Adresse von ppp0 wird dabei fix vom SAT-Provider vergeben und ist irgendwie aus der MAC-Adresse meiner DVB-Karte berechnet worden, die ich bei der Registrierung angeben mußte. Die IP-Adresse für ippp0 wird dynamisch vom ISP vergeben und die Adresse von dvb0_0 habe ich selbst mit ifconfig vergeben. Bis hierhin sieht doch eigentlich alles ganz sauber aus, oder? Gut, zum Test der Verbindung schicke ich jetzt einfach mal einen ping an einen externen Rechner (IP-Adresse 195.29.225.8). Und hier wird's jetzt problematisch: - Auf der Konsole mit dem ping tut sich nichts, d.h. es kommen keine Pakete zurück. - Mit "tcpdump -ni ppp0" sehe ich, wie die ICMP echo requests von der Adresse 172.24.3.129 (mein ppp0-Device) an die 195.29.225.8 geschickt werden. Die Pakete gehen also durch den Tunnel. - Mit "tcpdump -ni dvb0_0" sehe ich, wie die ICMP echo replies von 195.29.225.8 an 172.24.3.129 zurückgeschickt werden. Das Routing der Pakete über den VPN-Server scheint also so zu klappen wie es sollte. Wieso kommen die Pakete aber nicht wieder zum ping zurück? Ein Blick in /var/log/messages zeigt mir dann die kleinen grünen Männchen - Mars attacks ;-) martian source 172.24.3.129 from 195.20.225.8, on dev dvb0_0 ll header: 00:d0:5c:02:1c:78:00:00:00:00:00:00:08:00 Daran scheint es also zu liegen, daß der ping nicht zurückkommt. Ich hab' mal nach "martian source" gegoogelt und dort einen etwas älteren Beitrag dazu aus der Liste gefunden, wo diese Meldung damit erklärt wird, daß auf dem Device Pakete von einer IP-Adresse ankommen, die da gar nicht drüber kommen dürfte. Leider stand keine Lösungsmöglichkeit für das Problem dabei und ich bin daher nun etwas mit meinem Latein am Ende. Langer Vorrede, kurzer Sinn: Hat jemand eine Idee, wie ich die Marsianer vertreiben kann? Stimmt vielleicht irgendwas mit der Netmask oder Broadcast-Adresse des dvb0_0 nicht? Braucht Ihr noch mehr Informationen? Bin für jeden Hinweis dankbar. Viele Grüße Wolfgang
Am Mittwoch 24 April 2002 22:41 schrieben Sie:
dynamische IP-Adresse vom Internet-Provider 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 dvb0_0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Und das zeigt ifconfig für die drei beteiligten Interfaces:
dvb0_0 Link encap:Ethernet HWaddr 00:D0:5C:02:1C:78 inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::2d0:5cff:fe02:1c78/10 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:4096 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Hier könnte schonmal en Problem sein, wenn Du über das Internet geroutete Pakete mit ner privaten IP bekommst.
- Mit "tcpdump -ni ppp0" sehe ich, wie die ICMP echo requests von der Adresse 172.24.3.129 (mein ppp0-Device) an die 195.29.225.8 geschickt werden. Die Pakete gehen also durch den Tunnel. - Mit "tcpdump -ni dvb0_0" sehe ich, wie die ICMP echo replies von 195.29.225.8 an 172.24.3.129 zurückgeschickt werden. Das Routing der Pakete über den VPN-Server scheint also so zu klappen wie es sollte.
Wieso kommen die Pakete aber nicht wieder zum ping zurück? Ein Blick in /var/log/messages zeigt mir dann die kleinen grünen Männchen - Mars attacks ;-) Daran scheint es also zu liegen, daß der ping nicht zurückkommt. kann sein ..
Ich hab' mal nach "martian source" gegoogelt und dort einen etwas älteren Beitrag dazu aus der Liste gefunden, wo diese Meldung damit erklärt wird, daß auf dem Device Pakete von einer IP-Adresse ankommen, die da gar nicht drüber kommen dürfte. Leider stand keine Lösungsmöglichkeit für das Problem dabei und ich bin daher nun etwas mit meinem Latein am Ende.
Man kann die Prüfung auf Martian Sources auch deaktivieren. Irgendwo in /proc/sys/net/.. war das glaube ich... Vielleicht solltest Du das Roting innerhalb deiner Interfaces aktivieren. ;üsste eigentlich standardmä?ig funtkionieren, aber man weiß ja nie so recht.. -- --------------------------------------------------------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Martin Köster Voice: +49-208/3084-745 HÖFER Vorsorge-Management Fax: +49-208/3084-8117 Obere Saarlandstr. 2 Email: koe@hoefer-muelheim.de D-45470 Mülheim http://www.hoefer-muelheim.de +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hallo Martin, erstmal danke für Deine Antwort. Am Donnerstag, 25. April 2002 um 09:45 schrieb Martin Koester:
Am Mittwoch 24 April 2002 22:41 schrieben Sie:
dvb0_0 Link encap:Ethernet HWaddr 00:D0:5C:02:1C:78 inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0 [...] Hier könnte schonmal en Problem sein, wenn Du über das Internet geroutete Pakete mit ner privaten IP bekommst.
Habe ich mir auch schon gedacht, aber auch wenn ich die inet addr auf einen anderen Wert setze, ändert sich nichts. Auch mit der Netmask- und Broadcast-Adresse habe ich ein paar Änderungen durchgespielt - ohne Ergebnis.
Man kann die Prüfung auf Martian Sources auch deaktivieren. Irgendwo in /proc/sys/net/.. war das glaube ich...
Unter /proc/sys/net/ipv4/<interface>/log_martians kann man das Logging der Martians ausschalten, aber nicht die Tatsache an sich.
Vielleicht solltest Du das Roting innerhalb deiner Interfaces aktivieren. ;üsste eigentlich standardmä?ig funtkionieren, aber man weiß ja nie so recht..
Hm, den Vorschlag verstehe ich nicht so ganz. Was meinst Du mit Routing innerhalb der Interfaces? Nochmals danke. Viele Grüße Wolfgang
Am Donnerstag 25 April 2002 22:27 schrieb Wolfgang Wershofen:
Man kann die Prüfung auf Martian Sources auch deaktivieren. Irgendwo in /proc/sys/net/.. war das glaube ich...
Unter /proc/sys/net/ipv4/<interface>/log_martians kann man das Logging der Martians ausschalten, aber nicht die Tatsache an sich. Naja stimmt. Aber es dient ja AFAIK dazu, das Private Adressen und kaputte Header im IP-Stack geloggt werden. Es gibt da noch einen Parameter mit ignore_bogus und so weiter. Vielleicht hilft der Dir weiter.
Vielleicht solltest Du das Routing innerhalb deiner Interfaces aktivieren. ;üsste eigentlich standardmä?ig funtkionieren, aber man weiß ja nie so recht..
Hm, den Vorschlag verstehe ich nicht so ganz. Was meinst Du mit Routing innerhalb der Interfaces? Das Routing generell. Also momentan können zwischen deinen Interfaces keine Pakete geroutet werden. (d.h. wenn routing deaktiviert ist. Ich kenne die defaults nicht könnte also schon aktiviert sein dann ist mein Vorschlag leider nichts wert). Also mit echo "1" > /proc/sys/net/ipv4/irgendwas_mit_ip_forward Dann einfach mal testen ob Du über ein Device an das nächste kommst.
-- --------------------------------------------------------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Martin Köster Voice: +49-208/3084-745 HÖFER Vorsorge-Management Fax: +49-208/3084-8117 Obere Saarlandstr. 2 Email: koe@hoefer-muelheim.de D-45470 Mülheim http://www.hoefer-muelheim.de +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
participants (2)
-
Martin Koester -
Wolfgang Wershofen