aldente-xp
22.01.10, 00:41
Ich habe folgendes Problem:
Bei einigen Programmen (auch Server-Software) lässt sich angeben, welches Netzwerk-Interface für (ausgehende) Verbindungen benutzt werden soll. In der Regel kann man den Interface-Namen ODER die IP-Adresse angeben.
Beispiel:
curl --interface eth0 -C - -O http://www.google.de/images/nav_logo7.png
curl --interface 192.168.1.59 -C - -O http://www.google.de/images/nav_logo7.png
Funktioniert BEIDES, so wie es sein soll.
ABER (und jetzt kommt das eigentliche Problem):
Bei meinem tap0-Device funktioniert das nicht! Dort funktioniert kurioserweise die Angabe des Interface-Namens, aber NICHT die Angabe der IP-Adresse:
curl -v --interface tap0 -C - -O http://www.google.de/images/nav_logo7.png
curl -v --interface 134.169.216.180 -C - -O http://www.google.de/images/nav_logo7.png
Die zweite Variante bleibt an folgender Stelle hängen:
* About to connect() to www.google.de port 80 (#0)
* Trying 209.85.135.104... Bind local address to 134.169.216.180
* Local port: 36021
Dann passiert nichts mehr.
Die erste Variante hingegen läuft problemlos durch:
* About to connect() to www.google.de port 80 (#0)
* Trying 209.85.135.104... Bind local address to 134.169.216.180
* Local port: 44642
* connected
* Connected to www.google.de (209.85.135.104) port 80 (#0)
> GET /images/nav_logo7.png HTTP/1.1
[...]
< HTTP/1.1 200 OK
[...]
142k* Connection #0 to host www.google.de left intact
* Closing connection #0
Wieso funktioniert die direkte Angabe der IP-Adresse nicht?
In beiden fällen sagt er doch, "Bind local address to 134.169.216.180", also müsste er doch eigentlich genau das gleiche machen?
Wenn ich curl mit dem Parameter "192.168.1.59" (= eth0) ausführe, dann geht das problemlos auch bei Angabe der IP-Adresse. Nur eben bei der IP des tap0-Interfaces nicht.
Genau das gleiche Problem zeigen auch diverse andere Netzwerk-Anwendungen: Es passiert einfach gar nichts mehr!
Systeminformationen:
Debian 5.0
tap0 wird vom Cisco-VPN-Client ("vpnc") automatisch beim Aufbau einer VPN-Verbindung angelegt (die VPN-Verbindung an sich funktioniert auch hervorragend).
"ifconfig"-Ausgabe:
eth0 Link encap:Ethernet Hardware Adresse 00:02:ff:02:39:27
inet Adresse:192.168.1.59 Bcast:192.168.1.255 Maske:255.255.255.0
inet6-Adresse: fe80::202:ffff:fe02:3927/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:267918607 errors:0 dropped:0 overruns:0 frame:0
TX packets:278963447 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:2032742977 (1.8 GiB) TX bytes:543154189 (517.9 MiB)
Interrupt:11 Basisadresse:0xd800
eth0:1 Link encap:Ethernet Hardware Adresse 00:02:ff:02:39:27
inet Adresse:192.168.1.58 Bcast:192.168.1.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
Interrupt:11 Basisadresse:0xd800
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metrik:1
RX packets:871042 errors:0 dropped:0 overruns:0 frame:0
TX packets:871042 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:114842941 (109.5 MiB) TX bytes:114842941 (109.5 MiB)
tap0 Link encap:Ethernet Hardware Adresse 00:ff:6e:fb:e7:3e
inet Adresse:134.169.216.180 Bcast:134.169.216.255 Maske:255.255.255.0
inet6-Adresse: fe80::2ff:6eff:fefb:e73e/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1412 Metrik:1
RX packets:57 errors:0 dropped:0 overruns:0 frame:0
TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:500
RX bytes:26583 (25.9 KiB) TX bytes:17367 (16.9 KiB)
Was läuft da schief, und wie kann ich das reparieren?
Ich muss leider die Variante mit der IP-Adresse verwenden, deshalb muss ich das irgnedwie zum Laufen kriegen.
Bei einigen Programmen (auch Server-Software) lässt sich angeben, welches Netzwerk-Interface für (ausgehende) Verbindungen benutzt werden soll. In der Regel kann man den Interface-Namen ODER die IP-Adresse angeben.
Beispiel:
curl --interface eth0 -C - -O http://www.google.de/images/nav_logo7.png
curl --interface 192.168.1.59 -C - -O http://www.google.de/images/nav_logo7.png
Funktioniert BEIDES, so wie es sein soll.
ABER (und jetzt kommt das eigentliche Problem):
Bei meinem tap0-Device funktioniert das nicht! Dort funktioniert kurioserweise die Angabe des Interface-Namens, aber NICHT die Angabe der IP-Adresse:
curl -v --interface tap0 -C - -O http://www.google.de/images/nav_logo7.png
curl -v --interface 134.169.216.180 -C - -O http://www.google.de/images/nav_logo7.png
Die zweite Variante bleibt an folgender Stelle hängen:
* About to connect() to www.google.de port 80 (#0)
* Trying 209.85.135.104... Bind local address to 134.169.216.180
* Local port: 36021
Dann passiert nichts mehr.
Die erste Variante hingegen läuft problemlos durch:
* About to connect() to www.google.de port 80 (#0)
* Trying 209.85.135.104... Bind local address to 134.169.216.180
* Local port: 44642
* connected
* Connected to www.google.de (209.85.135.104) port 80 (#0)
> GET /images/nav_logo7.png HTTP/1.1
[...]
< HTTP/1.1 200 OK
[...]
142k* Connection #0 to host www.google.de left intact
* Closing connection #0
Wieso funktioniert die direkte Angabe der IP-Adresse nicht?
In beiden fällen sagt er doch, "Bind local address to 134.169.216.180", also müsste er doch eigentlich genau das gleiche machen?
Wenn ich curl mit dem Parameter "192.168.1.59" (= eth0) ausführe, dann geht das problemlos auch bei Angabe der IP-Adresse. Nur eben bei der IP des tap0-Interfaces nicht.
Genau das gleiche Problem zeigen auch diverse andere Netzwerk-Anwendungen: Es passiert einfach gar nichts mehr!
Systeminformationen:
Debian 5.0
tap0 wird vom Cisco-VPN-Client ("vpnc") automatisch beim Aufbau einer VPN-Verbindung angelegt (die VPN-Verbindung an sich funktioniert auch hervorragend).
"ifconfig"-Ausgabe:
eth0 Link encap:Ethernet Hardware Adresse 00:02:ff:02:39:27
inet Adresse:192.168.1.59 Bcast:192.168.1.255 Maske:255.255.255.0
inet6-Adresse: fe80::202:ffff:fe02:3927/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:267918607 errors:0 dropped:0 overruns:0 frame:0
TX packets:278963447 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:2032742977 (1.8 GiB) TX bytes:543154189 (517.9 MiB)
Interrupt:11 Basisadresse:0xd800
eth0:1 Link encap:Ethernet Hardware Adresse 00:02:ff:02:39:27
inet Adresse:192.168.1.58 Bcast:192.168.1.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
Interrupt:11 Basisadresse:0xd800
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metrik:1
RX packets:871042 errors:0 dropped:0 overruns:0 frame:0
TX packets:871042 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:114842941 (109.5 MiB) TX bytes:114842941 (109.5 MiB)
tap0 Link encap:Ethernet Hardware Adresse 00:ff:6e:fb:e7:3e
inet Adresse:134.169.216.180 Bcast:134.169.216.255 Maske:255.255.255.0
inet6-Adresse: fe80::2ff:6eff:fefb:e73e/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1412 Metrik:1
RX packets:57 errors:0 dropped:0 overruns:0 frame:0
TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:500
RX bytes:26583 (25.9 KiB) TX bytes:17367 (16.9 KiB)
Was läuft da schief, und wie kann ich das reparieren?
Ich muss leider die Variante mit der IP-Adresse verwenden, deshalb muss ich das irgnedwie zum Laufen kriegen.