[fli4l] DNS in einem Subnetz

[Christoph Schulz]

Hallo!

Hans Bachner schrieb:

> Ich dachte, genau darum ging es hier - fli4l1 hat eine Route ins Netz
> 192.168.3.0/24 definiert
>>>>> IP_ROUTE_1='192.168.3.0/24 192.168.1.21'

OK.

> und du meintest darauf
>>>> Das geht aber nur, wenn Fli4l2 eine Route für die Rückrichtung
> [...] hat
> 
> Ich denke, dass er die aufgrund seines Interfaces 192.168.1.21
> automatisch hat
> (jedenfalls für IPV4).

Ja, nein, doch ;-) Es kommt halt immer auf den zusätzlichen Kontext an. In 
deinem Szenario ist -- wie ich im letzten Beitrag schrieb -- alles im grünen 
Bereich. Wenn du allerdings am Fli4l1 noch ein weiteres Netz hängen hast, 
etwa 192.168.2.0/24, dann weiß der Fli4l2 eben nicht mehr, wie er dorthin 
kommt, es sei denn

a) er hat eine explizite Route dorthin:
   ip route add 192.168.2.0/24 via 192.168.1.1
b) Fli4l1 ist sein expliziter Default-Gateway:
   IP_ROUTE_x='0.0.0.0/0 192.168.1.1'
c) Fli4l1 ist sein Default-Gateway via DHCP.

Das 192.168.1.0/24er Netz kann dein Fli4l2 in der Tat immer direkt 
erreichen, also auch ohne den Router Fli4l1 zu involvieren. Das ist übrigens 
bei IPv6 anders, dort kann ein Host eine Netzadresse haben und dennoch 
gezwungen werden, seinen Default-Gateway zu kontaktieren, denn bei IPv6 kann 
man für jedes verteilte Netzpräfix bestimmen, ob es "on link" ist oder 
nicht.

> Auf einem meiner fli4ls hab ich drei Interfaces für drei interne Netze
> mit
> fest definierten Adressen. Ohne mein Zutun finde ich dort
> 
> fli4l 3.9.0-r30971-testing # ip route
> default via iii.jjj.kkk.145 dev eth4
> 10.10.0.0/23 dev eth1  proto kernel  scope link  src 10.10.0.254
> 10.10.2.0/24 dev eth2  proto kernel  scope link  src 10.10.2.254
> 10.10.3.0/24 dev eth3  proto kernel  scope link  src 10.10.3.254
> [...]
> 
> Es wird also für jedes Interface automatisch eine Route auf Basis der
> Adresse
> und Netzwerkmaske des Interfaces erzeugt.

Ja, das sind die "magischen" Routen, Linux erstellt sie mit Hilfe der 
Funktion "fib_magic" ;-)

> Anders sieht es natürlich aus, wenn der Router auf zwei Interfaces
> Adressen hat, die eigentlich zum gleichen CIDR-Subnetz gehören, die aber
> zu zwei physisch getrennten Netzen führen. So etwas würde ich allerdings
> wenn irgendmöglich vermeiden, da es zu großer Komplexität führt und sehr
> fehleranfällig (in der Konfiguration) ist.

Das ergibt in meinen Augen auch nur Sinn, wenn diese Interfaces auf die eine 
oder andere Weise überbrückt werden. Schließlich müssen ja die ARP-Anfragen 
ordentlich weitergeleitet werden.


Viele Grüße,
-- 
Christoph Schulz
[fli4l-Team]