Ich Glaube es jetzt verstanden zu haben.
Es handelt sich um ein Netz mit mehreren "Ausgängen".
Wenn dem so ist... 1. das DHCP-Interface deaktivieren (eth1) 2. das Defaultgateway des Netzes auf das verbleibende (eth0 mit fester IP) Interfaces legen.
3. route add .. für das andere Subnetz legen
zB.: echo "IP_ZIELHOST via IP_AUSGANG_aus_dem_Netz dev eth0">/etc/sysconfig/network-scripts/route_eth0
z.B.: echo "10.1.1.1 via 192.168.1.22 dev eth0">/etc/sysconfig/network-scripts/route_eth0
4. route add -host 10.1.1.1 192.168.1.22
5. fertig
Wolfgang
Subject: Re: [CentOS-de] Wie bringe ich meinen Rechner dazu, den default Gateway ueber ein bestimmtes Interface anzusprechen? To: centos-de@centos.org Message-ID: 1313600861.4415.31.camel@hex.schule.local Content-Type: text/plain; charset=UTF-8
So richtig verstanden habe ich Dein Ziel noch nicht.
Frage: eth0 und eth1 liegen im gleichen Netz? Wenn kein HA/Bonding/Failover/etc. konfiguriert wird, ist das sehr sehr ungewöhnlich und ich keine Anwendung die mit dieser Konfiguration gut läuft. Auch NFS nicht.
Eine Lösung für Deine Konfiguration ist: Bash-Script welches über ein cron gesteuert wird.
Aufgabe des Scripts:
Überprüfe das DHCP-Interface/Karte eine neue IP erhalten hat. Wenn JA -> lösche das erhaltene GW von dem Interface. Wenn Nein -> mach nichts.
Wie gesagt: Deine Konfiguration ist sehr seltsam, aber evtl. kann mir einer weitere Anwendungen nennen, die so eine Konfiguration benötigen.
Nun ja, ich weiss auch nicht alles und lerne gern was neues hinzu.
Noch ein Tip:
- yum -y install arpwatch
- jetzt kannst erkennen wieviel IP wirklich gebraucht werden.
- Jetzt könntest Du dir eine freie IP "schnappen"...
- Die freie IP nun fest auf das DHCP-Interface konfigurieren.
Die beste Lösung ist aber, das Du Deine Admins nochmal um Unterstützung bittest. Der Vorteil der Zusammenarbeit ist, die Abwendung von Maßnahmen gegen Deine Person. Wer trägt die Verantwortung, wenn das Netz blockiert wird?
Sag dem Admin, das die Einrichtung einer festen DHCP-IP ohne GW (egal ob Windows NT4-2008, oder Linux) nicht länger als 5min dauert, wenn man die richtige MAC besitzt.
Wenn Dein Chef Dich unterstützt sollte er evtl. mit den Admins reden.
Gruss Wolfgang
Message: 2 Date: Wed, 17 Aug 2011 20:41:16 +0200 From: Frank Thommen frank.thommen@embl-heidelberg.de Subject: Re: [CentOS-de] Wie bringe ich meinen Rechner dazu, den default Gateway ueber ein bestimmtes Interface anzusprechen? To: German mailing list for CentOS centos-de@centos.org Message-ID: 4E4C0B4C.3040003@embl-heidelberg.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Wolfgang wrote:
So richtig verstanden habe ich Dein Ziel noch nicht.
Mein Rechner meldet sich ueber den default-GW beim NFS-Server (der in einem anderen Subnetz liegt) und will einen Share mounten. Da die Anfrage aber ueber das falsche Interface (eth1 statt eth0) verschickt wird, kommt sie mit einem IP-Absender an, an den nicht exportiert wird und der Server schickt ein "Permission Denied" zurueck. Dieses Problem will ich loesen.
Frage: eth0 und eth1 liegen im gleichen Netz? Wenn kein HA/Bonding/Failover/etc. konfiguriert wird, ist das sehr sehr ungewöhnlich und ich keine Anwendung die mit dieser Konfiguration gut läuft. Auch NFS nicht.
Doch doch, es laeuft alles bestens (ausser NFS). Die Interfaces haben schliesslich verschiedene MAC-Adressen und verschiedene IP-Nummern. Genauso wie es zwei Aliase waeren. Es gibt m.E. keinen Grund, warum irgendetwas nicht laufen sollte (ausser NFS). Ich habe verschiedene virtuelle Webserver mit SSL auf dem Host laufen, und dafuer brauche ich verschiedene IP-Nummern, weil name-based virtual hosting mit SSL nicht funktioniert.
Eine Lösung für Deine Konfiguration ist: Bash-Script welches über ein cron gesteuert wird.
Aufgabe des Scripts:
Überprüfe das DHCP-Interface/Karte eine neue IP erhalten hat. Wenn JA -> lösche das erhaltene GW von dem Interface. Wenn Nein -> mach nichts.
Das macht nicht unbedingt Sinn, denn der Rechner erhaelt nur genau einmal seine IP-Nummern beim Start. Danach aendern sie sich - hoffentlich - nicht mehr.
[...]
Noch ein Tip:
- yum -y install arpwatch
- jetzt kannst erkennen wieviel IP wirklich gebraucht werden.
- Jetzt könntest Du dir eine freie IP "schnappen"...
- Die freie IP nun fest auf das DHCP-Interface konfigurieren.
Das funktioniert absolut nicht. IPs sind hier per MAC reserviert. Wenn man sich einfach freie IPs "schnappt" riskiert man einen IP-Konflikt im Netz. Und das bei einem Subnetz, in dem fast nur Server laufen! Das geht mit Garantie nicht gut aus ;-)
Die beste Lösung ist aber, das Du Deine Admins nochmal um Unterstützung bittest. [...]
Keine Angst. Ich mache den Job auch schon ein paar Jaehrchen und rede natuerlich mit den Netzwerk-Admins ;-). Das hier ist ein Host-Problem, nicht ein generelles Netzwerk-Problem, und muss m.E. als Solches auf dem Host geloest werden.
Gruss
frank
CentOS-de mailing list CentOS-de@centos.org http://lists.centos.org/mailman/listinfo/centos-de
Ende CentOS-de Nachrichtensammlung, Band 53, Eintrag 9
Hallo Wolfgang,
Wolfgang wrote:
Ich Glaube es jetzt verstanden zu haben.
Es handelt sich um ein Netz mit mehreren "Ausgängen".
Wenn dem so ist...
- das DHCP-Interface deaktivieren (eth1)
- das Defaultgateway des Netzes auf das verbleibende
(eth0 mit fester IP) Interfaces legen.
Ich habe mich fuer den umgekehrten Weg entschieden: eth0 per DHCP (mit Default-GW von DHCP), eth1 statisch ohne GW.
- route add .. für das andere Subnetz legen
zB.: echo "IP_ZIELHOST via IP_AUSGANG_aus_dem_Netz dev eth0">/etc/sysconfig/network-scripts/route_eth0
z.B.: echo "10.1.1.1 via 192.168.1.22 dev eth0">/etc/sysconfig/network-scripts/route_eth0
- route add -host 10.1.1.1 192.168.1.22
Das funktioniert leider nicht oder ist nicht noetig: Wenn der default GW-Eintrag auf das "falsche" Interface konfiguriert ist, hilft eine statische Host-Route auch nichts. Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface. Andererseits wenn der default GW schon auf dem richtigen Interface konfiguriert ist, ist die Host-Route nicht mehr noetig ;-)
frank
Am 20.08.2011 13:11, schrieb Frank Thommen:
Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface.
Das ist falsch. Überlege mal, was das in Konsequenz bedeuten würde.
Alexander
Alexander Dalloz wrote:
Am 20.08.2011 13:11, schrieb Frank Thommen:
Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface.
Das ist falsch. Überlege mal, was das in Konsequenz bedeuten würde.
Die praktische Erfahrung im beschriebenen Fall zeigt leider, dass es richtig ist:
* default GW via eth1 * statische host-route fuer den GW via eth0
NFS-Server in fremdem Subnetz wird via eth1 (nicht eth0) angefragt. Das waere vielleicht anders, wenn ich direkt den GW ansprechen wuerde (ssh etc.), aber Anfragen in andere *Subnetze* werden definitiv ueber eth1 getaetigt und nicht ueber eth0.
Ich koennte natuerlich fuer jeden einzelnen NFS-Server eine statische Route einrichten, aber das ist in diesem Fall nicht praktikabel.
frank
Frank Thommen wrote:
Alexander Dalloz wrote:
Am 20.08.2011 13:11, schrieb Frank Thommen:
Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface.
Das ist falsch. Überlege mal, was das in Konsequenz bedeuten würde.
Die praktische Erfahrung im beschriebenen Fall zeigt leider, dass es richtig ist:
- default GW via eth1
- statische host-route fuer den GW via eth0
NFS-Server in fremdem Subnetz wird via eth1 (nicht eth0) angefragt. Das waere vielleicht anders, wenn ich direkt den GW ansprechen wuerde (ssh etc.), aber Anfragen in andere *Subnetze* werden definitiv ueber eth1 getaetigt und nicht ueber eth0.
Anbei noch der "Tatbeweis" :-):
# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4E inet addr:10.11.8.63 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.64 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1:0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.65 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
[...]
# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.11.8.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1 0.0.0.0 10.11.8.1 0.0.0.0 UG 0 0 0 eth1 # ssh fthommen@10.1.108.59 fthommen@10.1.108.59's password: Last login: Sat Aug 20 14:36:37 2011 from svn.structures.embl.de $ who am i fthommen pts/2 2011-08-20 14:39 (svn.structures.embl.de) $ host svn.structures.embl.de svn.structures.embl.de has address 10.11.8.64 $
Verbindung in fremdes Subnetz ging also via eth1 und nicht ueber das Interface, welches als Host-route fuer den GW gesetzt worden ist (eth1).
frank
Frank Thommen wrote:
Frank Thommen wrote:
Alexander Dalloz wrote:
Am 20.08.2011 13:11, schrieb Frank Thommen:
Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface.
Das ist falsch. Überlege mal, was das in Konsequenz bedeuten würde.
Die praktische Erfahrung im beschriebenen Fall zeigt leider, dass es richtig ist:
- default GW via eth1
- statische host-route fuer den GW via eth0
NFS-Server in fremdem Subnetz wird via eth1 (nicht eth0) angefragt. Das waere vielleicht anders, wenn ich direkt den GW ansprechen wuerde (ssh etc.), aber Anfragen in andere *Subnetze* werden definitiv ueber eth1 getaetigt und nicht ueber eth0.
Anbei noch der "Tatbeweis" :-):
# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4E inet addr:10.11.8.63 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.64 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1:0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.65 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
[...]
# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.11.8.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1 0.0.0.0 10.11.8.1 0.0.0.0 UG 0 0 0 eth1 # ssh fthommen@10.1.108.59 fthommen@10.1.108.59's password: Last login: Sat Aug 20 14:36:37 2011 from svn.structures.embl.de $ who am i fthommen pts/2 2011-08-20 14:39 (svn.structures.embl.de) $ host svn.structures.embl.de svn.structures.embl.de has address 10.11.8.64 $
Verbindung in fremdes Subnetz ging also via eth1 und nicht ueber das Interface, welches als Host-route fuer den GW gesetzt worden ist (eth1).
^^^^ Korrektur eth0
f
Am 20.08.2011 14:44, schrieb Frank Thommen:
Frank Thommen wrote:
Frank Thommen wrote:
Alexander Dalloz wrote:
Am 20.08.2011 13:11, schrieb Frank Thommen:
Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface.
Das ist falsch. Überlege mal, was das in Konsequenz bedeuten würde.
Die praktische Erfahrung im beschriebenen Fall zeigt leider, dass es richtig ist:
- default GW via eth1
- statische host-route fuer den GW via eth0
NFS-Server in fremdem Subnetz wird via eth1 (nicht eth0) angefragt. Das waere vielleicht anders, wenn ich direkt den GW ansprechen wuerde (ssh etc.), aber Anfragen in andere *Subnetze* werden definitiv ueber eth1 getaetigt und nicht ueber eth0.
Anbei noch der "Tatbeweis" :-):
# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4E inet addr:10.11.8.63 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.64 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1:0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.65 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
[...]
# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.11.8.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1 0.0.0.0 10.11.8.1 0.0.0.0 UG 0 0 0 eth1 # ssh fthommen@10.1.108.59 fthommen@10.1.108.59's password: Last login: Sat Aug 20 14:36:37 2011 from svn.structures.embl.de $ who am i fthommen pts/2 2011-08-20 14:39 (svn.structures.embl.de) $ host svn.structures.embl.de svn.structures.embl.de has address 10.11.8.64 $
Verbindung in fremdes Subnetz ging also via eth1 und nicht ueber das Interface, welches als Host-route fuer den GW gesetzt worden ist (eth1).
^^^^
Korrektur eth0
f
10.11.8.1 ist das Ziel der Hostroute über eth0, *nicht* irgendwas außerhalb Deines 10.11.8.0/24 Netzes. Daher geht die Verbindung auch über die default route, die weisungsgemäß eth1 als Device benutzt.
Alexander
Alexander Dalloz wrote:
Am 20.08.2011 14:44, schrieb Frank Thommen:
Frank Thommen wrote:
Frank Thommen wrote:
Alexander Dalloz wrote:
Am 20.08.2011 13:11, schrieb Frank Thommen:
Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface.
Das ist falsch. Überlege mal, was das in Konsequenz bedeuten würde.
Die praktische Erfahrung im beschriebenen Fall zeigt leider, dass es richtig ist:
- default GW via eth1
- statische host-route fuer den GW via eth0
NFS-Server in fremdem Subnetz wird via eth1 (nicht eth0) angefragt. Das waere vielleicht anders, wenn ich direkt den GW ansprechen wuerde (ssh etc.), aber Anfragen in andere *Subnetze* werden definitiv ueber eth1 getaetigt und nicht ueber eth0.
Anbei noch der "Tatbeweis" :-):
# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4E inet addr:10.11.8.63 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.64 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
eth1:0 Link encap:Ethernet HWaddr 00:14:5E:0B:19:4F inet addr:10.11.8.65 Bcast:10.11.11.255 Mask:255.255.252.0 [...]
[...]
# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.11.8.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 10.11.8.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1 0.0.0.0 10.11.8.1 0.0.0.0 UG 0 0 0 eth1 # ssh fthommen@10.1.108.59 fthommen@10.1.108.59's password: Last login: Sat Aug 20 14:36:37 2011 from svn.structures.embl.de $ who am i fthommen pts/2 2011-08-20 14:39 (svn.structures.embl.de) $ host svn.structures.embl.de svn.structures.embl.de has address 10.11.8.64 $
Verbindung in fremdes Subnetz ging also via eth1 und nicht ueber das Interface, welches als Host-route fuer den GW gesetzt worden ist (eth1).
^^^^
Korrektur eth0
f
10.11.8.1 ist das Ziel der Hostroute über eth0, *nicht* irgendwas außerhalb Deines 10.11.8.0/24 Netzes. Daher geht die Verbindung auch über die default route, die weisungsgemäß eth1 als Device benutzt.
Das ist die Wiederholung dessen, was ich oben (und schon mal frueher im Thread) gesagt habe in Antwort an Wolfgang, der diesen Setup als Loesung fuer mein Problem vorgeschlagen hatte.
frank
Am 20.08.2011 14:13, schrieb Frank Thommen:
Alexander Dalloz wrote:
Am 20.08.2011 13:11, schrieb Frank Thommen:
Der GW-Eintrag hat eine hoehere Prioritaet und Anfragen zu anderen Subnetzen gehen *immer* ueber dieses Interface.
Das ist falsch. Überlege mal, was das in Konsequenz bedeuten würde.
Die praktische Erfahrung im beschriebenen Fall zeigt leider, dass es richtig ist:
- default GW via eth1
- statische host-route fuer den GW via eth0
NFS-Server in fremdem Subnetz wird via eth1 (nicht eth0) angefragt. Das waere vielleicht anders, wenn ich direkt den GW ansprechen wuerde (ssh etc.), aber Anfragen in andere *Subnetze* werden definitiv ueber eth1 getaetigt und nicht ueber eth0.
Ich koennte natuerlich fuer jeden einzelnen NFS-Server eine statische Route einrichten, aber das ist in diesem Fall nicht praktikabel.
frank
Egal was Du da fummelst, Dein Statement über die default route ist trotzdem falsch.
Die default route hat einfach die Funktion, dass Pakete, die nicht innerhalb desselben Netzes des Senders ihr Ziel finden können, einen Router haben und so das Ziel erreichen können.
Typischerweise[1] ist die default route eine Netzroute mit der größtmöglichen Maske. Die Route für eines der Interfaces ist auch eine Netzroute. Diese ist aber spezifischer, weil sie mehr Bits der Maske abdeckt. Daher hat sie Vorrang vor der default route.
Wenn Du nun eine andere präzisere Netzroute oder gar eine Hostroute definierst, haben diese natürlich auch Vorrang vor der default route.
([1] Ich rede hier der Vereinfachung halber vom Standardsetup, wie man es unter CentOS mit einem oder mehreren Devices vorfindet.)
Wenn Du mehrere Devices innerhalb desselben Netzes auf Deinem Host betreibst, dann musst Du auch dafür sorgen, dass eine Applikation ein bestimmtes Interface rausgehend benutzt. Sonst bestimmt das der Kernel selbst.
Gruß
Alexander
Alexander Dalloz wrote:
[...]
Wenn Du mehrere Devices innerhalb desselben Netzes auf Deinem Host betreibst, dann musst Du auch dafür sorgen, dass eine Applikation ein bestimmtes Interface rausgehend benutzt. Sonst bestimmt das der Kernel selbst.
...und genau das war meine urspuengliche Frage: Wie sorge ich dafuer, dass mein Rechner eth0 rausgehend benutzt statt eth1, wenn der Kernel von sich aus eth1 nehmen wuerde.
frank