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