Frage an Routing-Experten .. Routing mit 3 Devices auf einem Rechner
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Liste, ich konfiguriere/probiere/studiere schon eine Weile an einem Problem herum .. komm jetzt aber nicht weiter .. daher wende ich mich an euch. OS: Suse 9.1 Kernel: 2.6.15 Ich habe auch meinem "Gatewayrechner" drei Netzwerkdevices. eth0: 192.168.1.203 ..... internes LAN eth1: 192.168.2.1 ..... Da dran hängt mein ADSL-Modem -> Internet ippp0: 192.168.99.1 ..... Fritzkarte .. damit konfiguriere ich meine EUMEX Telefonanlage Von einem Client-Rechner (192.168.1.5) im Netz wil ich nun auf die http-Konfigurationsschnittstelle im ADSL-Modem (192.168.2.50) zugreifen. Lokal geht da vom Gatewayrechner auch : - ---schnipp--- newserver:/etc/ppp # lynx --dump http://192.168.2.50 Login Please log in to continue Login Name __________ Password __________ [1][login.jpg] References 1. JavaScript:DoLogin() newserver:/etc/ppp # - ---schnipp--- So, das will ich auch vom Client-Rechner aus. Ich habe das analog der Clientverbindung zur Telefonanlage (192.168.99.100) konfiguriert, dort geht das auch, mit dem ADSL-Modem aber nicht :o( Hier mal das Routing vom Gateway-Rechner ... incl. Internet-Verbindung - ---schnipp--- newserver:/backup/etc/ppp # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.26.136.41 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.2.50 0.0.0.0 255.255.255.255 UH 0 0 0 eth1 192.168.99.100 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 192.168.2.0 192.168.2.1 255.255.255.0 UG 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.99.0 192.168.99.1 255.255.255.0 UG 0 0 0 ippp0 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 62.26.136.41 0.0.0.0 UG 0 0 0 ppp0 newserver:/backup/etc/ppp # - ---schnipp--- So, man sieht, dass ippp0 (geht) und eth1 (geht nicht) nach dem gleichem Schema geroutet werden (bzw die Netze natürlich) Auf dem Client (W2K) sieht das Routing so aus: - ---schnipp--- =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl 0.0.0.0 0.0.0.0 192.168.1.203 192.168.1.5 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.1.0 255.255.255.0 192.168.1.5 192.168.1.5 1 192.168.1.5 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.1.255 255.255.255.255 192.168.1.5 192.168.1.5 1 192.168.50.0 255.255.255.0 192.168.1.203 192.168.1.5 1 192.168.99.0 255.255.255.0 192.168.1.203 192.168.1.5 1 224.0.0.0 224.0.0.0 192.168.1.5 192.168.1.5 1 255.255.255.255 255.255.255.255 192.168.1.5 192.168.1.5 1 Standardgateway: 192.168.1.203 =========================================================================== Ständige Routen: Netzwerkadresse Netzmaske Gatewayadresse Anzahl 192.168.99.0 255.255.255.0 192.168.1.203 1 192.168.50.0 255.255.255.0 192.168.1.203 1 - ---schnipp--- Sieht doch gut aus ... oder ? So, jetzt mal ein Ping vom Client (192.168.1.5) auf die Telefonanlage : - ---schnipp--- D:\Dokumente und Einstellungen\Harry>ping 192.168.99.100 Ping wird ausgeführt für 192.168.99.100 mit 32 Bytes Daten: Antwort von 192.168.99.100: Bytes=32 Zeit=30ms TTL=126 Antwort von 192.168.99.100: Bytes=32 Zeit=23ms TTL=126 Antwort von 192.168.99.100: Bytes=32 Zeit=28ms TTL=126 Antwort von 192.168.99.100: Bytes=32 Zeit=23ms TTL=126 Ping-Statistik für 192.168.99.100: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 23ms, Maximum = 30ms, Mittelwert = 26ms - ---schnipp--- Und dann auf das ADSL-Modem: - ---schnipp--- D:\Dokumente und Einstellungen\Harry>ping 192.168.2.50 Ping wird ausgeführt für 192.168.2.50 mit 32 Bytes Daten: Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Ping-Statistik für 192.168.2.50: Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms - ---schnipp--- Joo, und wenn kein Ping .. dann keine Verbindung, klar, oder ? Wo liegt denn jetzt der Hund begraben ? Bin dankbar für jede Idee .... Grüße Harry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEQqOW7ttRafA1ej8RAqepAKCnXpySQMy9JDvCkvpEk9ucAaNzzACbBe7U cXKiBrayoZQVv+zdN11vOYA= =8KPW -----END PGP SIGNATURE-----
Hallo. * Sonntag, 16. April 2006 um 22:05 (+0200) schrieb Harry Rüter:
Ich habe auch meinem "Gatewayrechner" drei Netzwerkdevices.
eth0: 192.168.1.203 ..... internes LAN eth1: 192.168.2.1 ..... Da dran h�ngt mein ADSL-Modem -> Internet ippp0: 192.168.99.1 ..... Fritzkarte .. damit konfiguriere ich meine EUMEX Telefonanlage
Von einem Client-Rechner (192.168.1.5) im Netz wil ich nun auf die http-Konfigurationsschnittstelle im ADSL-Modem (192.168.2.50) zugreifen. Lokal geht da vom Gatewayrechner auch :
[ ... ]
Und dann auf das ADSL-Modem:
---schnipp--- D:\Dokumente und Einstellungen\Harry>ping 192.168.2.50
Ping wird ausgef�hrt f�r 192.168.2.50 mit 32 Bytes Daten:
Zeit�berschreitung der Anforderung. Zeit�berschreitung der Anforderung. Zeit�berschreitung der Anforderung. Zeit�berschreitung der Anforderung.
Ping-Statistik f�r 192.168.2.50: Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms ---schnipp---
Vermutlich liegt das Problem im ADSL-Modem: Es kennt keine Route in das interne LAN. Wenn möglich, dann setze eine Route im ADSL-Modem, äquivalent zu 'route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1'. Falls das Modem keine Möglichkeit zum Setzen statischer Routen bietet, dann kannst du die Pakete zum Modem auf dem Gatewayrechner "S-NATten", in der Art 'iptables -t nat -I 1 POSTROUTING -o eth1 -s 192.168.2.50 -j MASQUERADE'. Wo und wie du allerdings die Masquerade-Regel in die SUSE-Firewall bekommst, kann ich dir mangels Kenntnis des SUSE-Skriptes nicht sagen... Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Liste, hi Andreas, was ich noch sagen sollte. Es hat mal funktioniert, allersdings auf einem anderen Rechner (an den ich nicht mehr rankomme :o( und damals gab es nur zwei Devices, eth0 und eth1 ..... Es liegt also nicht am ADSL-Modem .... Das macht die Sache ja so strange ... Ist evtl. die REihenfolge der Routingeinträge relevant ? Grüße Harry Andreas Koenecke schrieb:
Vermutlich liegt das Problem im ADSL-Modem: Es kennt keine Route in das interne LAN. Wenn möglich, dann setze eine Route im ADSL-Modem, äquivalent zu 'route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1'.
Falls das Modem keine Möglichkeit zum Setzen statischer Routen bietet, dann kannst du die Pakete zum Modem auf dem Gatewayrechner "S-NATten", in der Art 'iptables -t nat -I 1 POSTROUTING -o eth1 -s 192.168.2.50 -j MASQUERADE'.
Wo und wie du allerdings die Masquerade-Regel in die SUSE-Firewall bekommst, kann ich dir mangels Kenntnis des SUSE-Skriptes nicht sagen...
Gruß
Andreas
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEQ1237ttRafA1ej8RAqAtAJ4pEewZK7E+Lvjb2H42+SmdRqxRbwCfeW8p ibOgWYwGngMMxh7HkC6y5LQ= =4jkl -----END PGP SIGNATURE-----
Hallo. * Montag, 17. April 2006 um 11:19 (+0200) schrieb Harry Rüter:
(Bitte kein TOFU.)
Es hat mal funktioniert, allersdings auf einem anderen Rechner (an den ich nicht mehr rankomme :o( und damals gab es nur zwei Devices, eth0 und eth1 .....
Es liegt also nicht am ADSL-Modem ....
Seltsame Schlussfolgerung... Probiere es doch einfach mal mit der Masquerade-Regel aus. Allerdings ist die von gestern falsch (Es war wohl ein bisschen spät.). Richtig muss sie lauten: 'iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE'.
Das macht die Sache ja so strange ... Ist evtl. die REihenfolge der Routingeinträge relevant ?
Auf dem Linuxrechner AFAIK ja, aber ich sehe in der Routing-Tabelle nichts, was das Problem verursachen könnte. (Einige Einträge sind überflüssig, aber das sollte nicht stören.) Starte doch mal auf dem Gatewayrechner ein 'tcpdump -ne -i eth0 dst host 192.168.2.50', pinge das ADSL-Modem vom Client und poste die Ausgabe von 'tcpdump ...' zusammen mit der Ausgabe von 'arp -a'. ('arp -a' durchgeführt *nach* dem "Pingen".) Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi nochmal :o) Andreas Koenecke schrieb:
Hallo.
* Montag, 17. April 2006 um 11:19 (+0200) schrieb Harry Rüter:
(Bitte kein TOFU.) Ja, schon klar, ich wollte das ganze nicht aus dem Zusamenhang reißen ...
Es hat mal funktioniert, allersdings auf einem anderen Rechner (an den ich nicht mehr rankomme :o( und damals gab es nur zwei Devices, eth0 und eth1 .....
Es liegt also nicht am ADSL-Modem ....
Seltsame Schlussfolgerung... Warum, ich weiß doch damit, dass es funktioniert hat und wieder müßte ... die Hoffnung stirbt zuletzt ..
Probiere es doch einfach mal mit der Masquerade-Regel aus. Allerdings ist die von gestern falsch (Es war wohl ein bisschen spät.). Richtig muss sie lauten: 'iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE'. Mache ich später .. damals ging es sicher ohne iptables-Nachkonfiguration ..
Auf dem Linuxrechner AFAIK ja, aber ich sehe in der Routing-Tabelle nichts, was das Problem verursachen könnte. (Einige Einträge sind überflüssig, aber das sollte nicht stören.) Ich auch nicht, das ist es ja ...
Starte doch mal auf dem Gatewayrechner ein 'tcpdump -ne -i eth0 dst host 192.168.2.50', pinge das ADSL-Modem vom Client und poste die Ausgabe von 'tcpdump ...' zusammen mit der Ausgabe von 'arp -a'. ('arp -a' durchgeführt *nach* dem "Pingen".)
Hier der tcpdump : - ---schnipp--- newserver:/proc/sys/net/ipv4 # tcpdump -ne -i eth0 dst host 192.168.2.50 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 14:59:14.559691 00:50:bf:01:cc:ef > 00:40:95:43:1b:de, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 47369 14:59:15.800237 00:50:bf:01:cc:ef > 00:40:95:43:1b:de, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 47625 14:59:16.799959 00:50:bf:01:cc:ef > 00:40:95:43:1b:de, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 47881 14:59:17.804106 00:50:bf:01:cc:ef > 00:40:95:43:1b:de, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 48137 14:59:18.804833 00:50:bf:01:cc:ef > 00:40:95:43:1b:de, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 48393 14:59:19.807353 00:50:bf:01:cc:ef > 00:40:95:43:1b:de, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 48649 - ---schnipp--- Und hier der arp -a .. - ---schnipp--- newserver:/proc/sys/net/ipv4 # arp -a ? (192.168.1.5) at 00:50:BF:01:CC:EF [ether] on eth0 - ---schnipp--- Hilft dir/uns das weiter ? Grüße Harry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEQ5I/7ttRafA1ej8RAu0bAJ9VHN0AINKsNMe9aQUEsaqjTOPVigCeJYwh iiYpq2M/g1mL9HV8ktZEB1Q= =tDff -----END PGP SIGNATURE-----
Hallo. * Montag, 17. April 2006 um 15:03 (+0200) schrieb Harry Rüter:
Andreas Koenecke schrieb:
Starte doch mal auf dem Gatewayrechner ein 'tcpdump -ne -i eth0 dst host 192.168.2.50', pinge das ADSL-Modem vom Client und poste die Ausgabe von 'tcpdump ...' zusammen mit der Ausgabe von 'arp -a'. ('arp -a' durchgef�hrt *nach* dem "Pingen".)
Hier der tcpdump : ---schnipp--- newserver:/proc/sys/net/ipv4 # tcpdump -ne -i eth0 dst host 192.168.2.50 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 14:59:14.559691 00:50:bf:01:cc:ef > 00:40:95:43:1b:de, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 47369 [ ... ]
Die Pakete kommen ordnungsgemäß (vermutlich, s.u.) am Gatewayrechner rein, nun müssen sie nur noch raus: Führe den gleichen Vorgang noch einmal durch, diesmal mit 'tcpdump -ne -i eth1 dst host 192.168.2.50 or dst host 192.168.1.5' auf dem Gatewayrechner.
Und hier der arp -a ..
---schnipp--- newserver:/proc/sys/net/ipv4 # arp -a ? (192.168.1.5) at 00:50:BF:01:CC:EF [ether] on eth0 ---schnipp---
Leider fehlt der ARP-Eintrag (und damit die MAC-Adresse) des ADSL-Modems: Ping' mal das Modem vom Gatewayrechner und poste 'arp -a' dann noch einmal. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Liste, hi Andreas,
Die Pakete kommen ordnungsgemäß (vermutlich, s.u.) am Gatewayrechner rein, nun müssen sie nur noch raus: Ja, das sehe ich genauso ... :o)
Führe den gleichen Vorgang noch einmal durch, diesmal mit 'tcpdump -ne -i eth1 dst host 192.168.2.50 or dst host 192.168.1.5' auf dem Gatewayrechner. Da liegt offensichtlich der Hund begraben, es kommt nix an :
- ---schnipp--- newserver:/etc/ppp # tcpdump -ne -i eth1 dst host 192.168.2.50 or dst host 192.168.1.5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes - ---schnipp---
Leider fehlt der ARP-Eintrag (und damit die MAC-Adresse) des ADSL-Modems: Ping' mal das Modem vom Gatewayrechner und poste 'arp -a' dann noch einmal. Hier zur Vollständigkeit der arp-Aufruf :
- ---schnipp--- newserver:/etc/ppp # arp -a adslmodem.hrnet.priv (192.168.2.50) at 00:0F:3D:F1:F9:F7 [ether] on eth1 ? (192.168.1.5) at 00:50:BF:01:CC:EF [ether] on eth0 - ---schnipp--- Ich denke man sieht oben, dass einfach nix an eth1 weitergeleitet wird, aber warum ? IP-Weiterleitung ist aktiv : - ---schnipp--- newserver:/ # cat /proc/sys/net/ipv4/ip_forward 1 - ---schnipp--- Ich bin ratlos, du hoffentlich nicht .. Hier nochmal mein ifconfig : - ---schnipp--- eth0 Link encap:Ethernet HWaddr 00:40:95:43:1B:DE inet addr:192.168.1.203 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::240:95ff:fe43:1bde/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9580109 errors:0 dropped:0 overruns:0 frame:0 TX packets:16406037 errors:0 dropped:0 overruns:0 carrier:0 collisions:3711 txqueuelen:1000 RX bytes:957192917 (912.8 Mb) TX bytes:69629204 (66.4 Mb) Interrupt:15 Base address:0x2c00 eth1 Link encap:Ethernet HWaddr 00:08:C7:4C:B7:62 inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::208:c7ff:fe4c:b762/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15636504 errors:0 dropped:0 overruns:0 frame:0 TX packets:11894986 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4163030154 (3970.1 Mb) TX bytes:1083461646 (1033.2 Mb) Interrupt:11 Base address:0x2c60 ippp0 Link encap:Point-to-Point Protocol inet addr:192.168.99.1 P-t-P:192.168.99.100 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:5002 errors:0 dropped:0 overruns:0 frame:0 TX packets:6503 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:30 RX bytes:1509588 (1.4 Mb) TX bytes:1163433 (1.1 Mb) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2378264065 errors:0 dropped:0 overruns:0 frame:0 TX packets:2378264065 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:783889891 (747.5 Mb) TX bytes:783889891 (747.5 Mb) ppp0 Link encap:Point-to-Point Protocol inet addr:213.54.174.50 P-t-P:62.26.136.40 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:694472 errors:0 dropped:0 overruns:0 frame:0 TX packets:558540 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:976221895 (930.9 Mb) TX bytes:34215858 (32.6 Mb) - ---schnipp--- Grüße Harry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEQ6w67ttRafA1ej8RAgeDAJ0S6XkqXvB2mK3WItyD1mDBl8qDpACfTXl/ VZWG/XSF7+w/WxIdxkcVI8w= =EkQq -----END PGP SIGNATURE-----
Hallo Harry. * Montag, 17. April 2006 um 16:54 (+0200) schrieb Harry Rüter:
Da liegt offensichtlich der Hund begraben, es kommt nix an :
---schnipp--- newserver:/etc/ppp # tcpdump -ne -i eth1 dst host 192.168.2.50 or dst host 192.168.1.5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
---schnipp---
[...]
Ich denke man sieht oben, dass einfach nix an eth1 weitergeleitet wird, aber warum ? IP-Weiterleitung ist aktiv :
---schnipp--- newserver:/ # cat /proc/sys/net/ipv4/ip_forward 1 ---schnipp---
Hm, seltsam... Dann kann es eventuell noch die Firewall-Einstellung sein. Gib doch auf dem Gatewayrechner probeweise mal 'iptables -I FORWARD 1 -i eth0 -o eth1 -j ACCEPT' und 'iptables -I FORWARD 2 -i eth1 -o eth0 -j ACCEPT' ein und probiere es dann noch einmal. Falls das 'ping' immer noch nicht beantwortet wird, kontrolliere auf dem Gateway mit 'tcpdump -ne -i eth1 host 192.168.2.50 or host 192.168.1.5', ob immer noch kein Paket herausgeht. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, ich will dir erstmal für deine Hilfe danken, Andreas :o) Andreas Koenecke schrieb:
Hm, seltsam...
Dann kann es eventuell noch die Firewall-Einstellung sein. Gib doch auf dem Gatewayrechner probeweise mal 'iptables -I FORWARD 1 -i eth0 -o eth1 -j ACCEPT' und 'iptables -I FORWARD 2 -i eth1 -o eth0 -j ACCEPT' ein und probiere es dann noch einmal. Falls das 'ping' immer noch nicht beantwortet wird, kontrolliere auf dem Gateway mit 'tcpdump -ne -i eth1 host 192.168.2.50 or host 192.168.1.5', ob immer noch kein Paket herausgeht.
So, habe ich gemacht .. heraus kommt : - ---schnipp--- newserver:/proc/sys/net/ipv4 # iptables -I FORWARD 1 -i eth0 -o eth1 -j ACCEPT newserver:/proc/sys/net/ipv4 # iptables -I FORWARD 2 -i eth1 -o eth0 -j ACCEPT newserver:/proc/sys/net/ipv4 # tcpdump -ne -i eth1 host 192.168.2.50 or host 192.168.1.5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 18:43:24.120129 00:08:c7:4c:b7:62 > 00:0f:3d:f1:f9:f7, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 12042 18:43:25.436937 00:08:c7:4c:b7:62 > 00:0f:3d:f1:f9:f7, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 12298 18:43:26.439390 00:08:c7:4c:b7:62 > 00:0f:3d:f1:f9:f7, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 12554 - ---schnipp--- Der/das Ping geht immer noch nicht, aber es kommen schon mal Pakete an .. ein Fortschritt .. Grüße Harry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEQ8Zv7ttRafA1ej8RAhYKAJ0WHm9nBj9BZOFRlA3eXt/f7TbdQQCfdvcs 7SuOCBrKO2uROPlojnmjR70= =+PzS -----END PGP SIGNATURE-----
Hallo Harry. * Montag, 17. April 2006 um 18:46 (+0200) schrieb Harry Rüter:
So, habe ich gemacht .. heraus kommt :
---schnipp--- newserver:/proc/sys/net/ipv4 # iptables -I FORWARD 1 -i eth0 -o eth1 -j ACCEPT newserver:/proc/sys/net/ipv4 # iptables -I FORWARD 2 -i eth1 -o eth0 -j ACCEPT newserver:/proc/sys/net/ipv4 # tcpdump -ne -i eth1 host 192.168.2.50 or host 192.168.1.5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 18:43:24.120129 00:08:c7:4c:b7:62 > 00:0f:3d:f1:f9:f7, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 12042 18:43:25.436937 00:08:c7:4c:b7:62 > 00:0f:3d:f1:f9:f7, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 12298 18:43:26.439390 00:08:c7:4c:b7:62 > 00:0f:3d:f1:f9:f7, ethertype IPv4, length 74: IP 192.168.1.5 > 192.168.2.50: icmp 40: echo request seq 12554 ---schnipp---
Der/das Ping geht immer noch nicht, aber es kommen schon mal Pakete an .. ein Fortschritt ..
Ja, das sehe ich auch so... Jetzt kommt wieder Hypothese Nr. 1 (ADSL-Modem-Routing) ins Spiel: Lasse die beiden FORWARD-Regeln gesetzt und gib jetzt zusätzlich die MASQUERADE-Regel ein. ('iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE') Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi .. and the show goes on .. Andreas Koenecke schrieb:
Der/das Ping geht immer noch nicht, aber es kommen schon mal Pakete an .. ein Fortschritt ..
Ja, das sehe ich auch so... Jetzt kommt wieder Hypothese Nr. 1 (ADSL-Modem-Routing) ins Spiel: Lasse die beiden FORWARD-Regeln gesetzt und gib jetzt zusätzlich die MASQUERADE-Regel ein. ('iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE')
Ich bin leider kein iptables-Spezialist ... da stimmt was nicht : - ---schnipp--- newserver:/proc/sys/net/ipv4 # iptables -t nat -I 1 POSTROUTING -o eth1 - -d 192.168.2.50 -j MASQUERADE iptables v1.2.9: Invalid rule number `POSTROUTING' Try `iptables -h' or 'iptables --help' for more information. - ---schnipp--- Grüße Harry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEQ9SM7ttRafA1ej8RAlTEAJ9Kc1V3tPG8SDmkIX/6nnK4cK8sNgCgg29k 1MEkvlmVfmDZyfHVImoU7Qc= =bs1a -----END PGP SIGNATURE-----
Hallo Harry. * Montag, 17. April 2006 um 19:46 (+0200) schrieb Harry Rüter:
Andreas Koenecke schrieb:
('iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE')
Ich bin leider kein iptables-Spezialist ... da stimmt was nicht :
---schnipp--- newserver:/proc/sys/net/ipv4 # iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE iptables v1.2.9: Invalid rule number `POSTROUTING' Try `iptables -h' or 'iptables --help' for more information. ---schnipp---
Irgendwann lerne ich es auch noch... ;) 'iptables -t nat -I POSTROUTING 1 -o eth1 -d 192.168.2.50 -j MASQUERADE' Gruß Andreas -- XMMS spielt gerade "Black Sabbath - Rat Salad"... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Andreas, es funzt .. :o) Ich danke dir für die Hilfe, (und gebe dir hiermit ein Getränk deiner Wahl aus :o). Kannst du mir erklären warum ich den ganzen iptables-Hokuspokus machen muß ? Ich verstehe nicht, warum das beim ippp0-Device von sich aus funzt, bei eth1 nicht .. Wie kann ich diese Regeln am besten "permanent" machen, sodaß sie nach dem Booten wieder aktiv sind ? Ich verwende die SuseFirewal2 .. Danke nochmal .. Grüße Harry Andreas Koenecke schrieb:
Hallo Harry.
* Montag, 17. April 2006 um 19:46 (+0200) schrieb Harry Rüter:
Andreas Koenecke schrieb:
('iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE') Ich bin leider kein iptables-Spezialist ... da stimmt was nicht :
---schnipp--- newserver:/proc/sys/net/ipv4 # iptables -t nat -I 1 POSTROUTING -o eth1 -d 192.168.2.50 -j MASQUERADE iptables v1.2.9: Invalid rule number `POSTROUTING' Try `iptables -h' or 'iptables --help' for more information. ---schnipp---
Irgendwann lerne ich es auch noch... ;)
'iptables -t nat -I POSTROUTING 1 -o eth1 -d 192.168.2.50 -j MASQUERADE'
Gruß
Andreas
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEQ99o7ttRafA1ej8RAoaRAJ9gRn41Xwa3CUhxhpYlRc1Ab3pV8ACgi1cg 71l+P9MiqlSDCePaqdVmW9A= =gAHW -----END PGP SIGNATURE-----
Hallo Harry. * Montag, 17. April 2006 um 20:33 (+0200) schrieb Harry Rüter:
es funzt .. :o)
Schön!
Kannst du mir erkl�ren warum ich den ganzen iptables-Hokuspokus machen mu� ?
Die FORWARD-Regeln erlauben das Forwarding zwischen eth0 und eth1 und die MASQUERADE-Regel ist nötig, weil andernfalls -- wie schon geschrieben -- das ADSL-Modem nicht "weiss", wohin es die Antwort-Pakete zurücksenden soll.
Ich verstehe nicht, warum das beim ippp0-Device von sich aus funzt, bei eth1 nicht ..
Weil vermutlich der '(i)pppd' der Telefonanlage die Defaultroute auf seine "Gegenstelle" setzt (also auf die IP-Adresse des 'ipppd' des Gatewayrechners).
Wie kann ich diese Regeln am besten "permanent" machen, soda� sie nach dem Booten wieder aktiv sind ?
Ich verwende die SuseFirewal2 ..
Wie schon geschrieben kenne ich mit der SUSE-Firewall nicht aus, aber ich würde es wie folgt versuchen: - Trage in "FW_DEV_INT" (ggfs. zusätzlich) "eth0 eth1" ein. Ich würde erwarten, dass dann zwischen den beiden Devices das Forwarding erlaubt wird (Die beiden FORWARD-Regeln). - Trage in "FW_MASQ_DEV" _zusätzlich_ "eth1" ein. Damit wird vielleicht die POSTROUTING-Regel erzeugt. Gruß Andreas -- XMMS spielt gerade "Black Sabbath - Rat Salad"... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
participants (2)
-
Andreas Koenecke -
Harry Rüter