[Discuss] alternatives NAT Package fuer die freifunkfirmware

[Harald Geyer]

> > Also ich hab' solche Setups seit Monaten laufen, ist ansich kein
> > Problem, linux schafft das, solang man ein paar Sachen einhält:
> >
> > a) Wirklich nur gleiche Adresse konfigurieren aber nicht gleiche
> > Subnetze (also überall außer auf einem Interface /32) weil arp lookups
> > gehen nur bei einem Interface raus - den Rest muss man mit host routen
> > machen. Da kommt uns OLSR ja sehr entgegen.
> >
> > b) Aufpassen, das in einem Ethernetsegment die Zuordnung IP->MAC
> > eindeutig ist - eh klar warum ... Also bei WIFI/WAN kein Problem,
> > aber bei zwei WIFI Interfaces oder wenn eine Bridge dazu kommt, dann
> > sollte man aufpassen, bzw. doch eine IP opfern.
> OLSR ist ein Layer-3 Netz... 

Das wird aber je nach Thema unterschiedlich streng gehandhabt. Wenn es
um Metriken geht, dann ist das auf einmal anders ...

> und die verschiedenen Interfaces eines Knoten 
> werden direkt von OLSR genutzt... 

Weswegen der olsrd derzeit auch in der Lage ist, mit den gleichen
IPs auf mehreren Interfaces was sinnvolles zu machen.

> dazu kommt noch das der OLSR Standard unter 
> der Prämisse geschrieben wurde das jedes einzelnes Interface eine eigene 
> eindeutige IP hat,

Jein. Wie schon im letzten Mail geschrieben, halte ich das für ein
Misfeature vom RFC...

... daneben ist das RFC in dieser Hinsicht aber auch nicht ganz eindeutig,
weil es im Endeffekt offen lässt, welche Einheit nun ein OLSR-Node ist
und welche Interfaces des OLSR-Node nun OLSR-Interfaces sind. Siehe
dazu zum Beispiel den Thread der auf
http://lists.olsr.org/pipermail/olsr-dev/2008-August/002378.html
folgt - insbesondere deine eigenen Kommentare.

Überhaupt finde ich, dass es eines der strukturellen Probleme in 
unserem Netz ist, dass in den Köpfen vieler Leute 
olsr router == olsrd instanz <=> irgendein linksys router
gilt.

> ansonsten läuft man in Probleme. Diese sind zwar nicht 
> immer offensichtlich, aber sie existieren.

Ja, ich weiß: Z.B. dass der tunnelserver MID-Messages ausschickt, wo
40 Mal die selbe IP drinnen steht.

> > Also solang man sich an das hält, was ich oben beschrieben habe, sind
> > keine Verrenkungen notwendig. Für die meisten Applikationen wird die
> > Sache dadurch einfacher, weil sie eher die Annahme IP=host als sonst
> Du Verwechselst die Interface-IPs mit der Main-IP der Routers. Die IPs der 
> Interfaces sind nur für den Routing-Daemon von Belang, die Anwendung muß
> die eigentlich nie wissen.

Du verwechselst OLSR routing und Linux routing. Die Anwendung weiß nichts
von OLSR und außerhalb vom OLSR gibt es AFAIK keine Main-IP, d.h. die
Interface IPs tauchen immer wieder irgendwo auf, je nachdem über welches
Interface die route gerade geht. -> Deswegen ja auch das Paket, das
Markus am Anfang dieses Threads vorgestellt hat.

Aber dieses Paket löst nur einen Teil des Problems (nämlich NAT),
aber nicht das Problem für den Traffic, der vom Device selbst kommt.
(Dazu könnte der olsrd natürlich überall seine Main-IP als src IP
eintragen, aber ob das als "sauberes setup" durchgeht ist dann
wieder Ansichtssache.)

> > irgendwas haben. Einzige Ausnahme, die ich kenne, ist eigentlich der
> > OLSRd, aber IMO ist das ein Misfeature des RFC.
> OLSR Überträgt in seinen Paketen nur IP-Adressen, weil es eben ein Layer-3 
> Protokoll ist. Was zu nicht auflösbaren Mehrdeutigkeiten führt.

Ich denke, solang man die Regeln einhält, die ich oben beschrieben habe,
sind die Mehrdeutigkeiten sehr wohl auflösbar ... ob das auch so
implementiert ist, ist natürlich wieder eine andere Sache.

Kennst du da irgendein Gegenbeispiel an das ich nicht gedacht habe?
 
> Ich würde keinem Empfehlen eine IP mehrfach zu nutzen... und denen die es 
> machen würde ich empfehlen es durch eine saubere Konfiguration zu ersetzen, 
> damit man nicht irgendwann mal in Schwierigkeiten steckt.
 
Wenn die olsrd Entwickler beschließen, dass das "keine saubere Konfiguration"
ist und sie das künftig verhindern, dann wird uns eh nix anderes übrig
bleiben...

> Wenn es technische Gründe gibt warum man eine solche Konfiguration 
> unbedingt braucht würde ich sie gerne hören um diese Probleme nach
> und nach zu beseitigen.

Naja, die Gründe sind vielseitig, nicht alle technisch und erfüllen
nicht "unbedingt braucht", aber hier einmal ein paar Beispiele, warum
das manche gern haben:

a) $lieblingswebsite vergisst mich, wenn sich meine IP ändert
b) Übersichtlichkeit, wenn DNS wieder nicht erreichbar ist und ich
   debuggen muss - die IP vom Tunnelserver kenn' ich auswendig, aber 
   wenn der 40 IPs hat, dann werd' ich mir die nicht alle merken.
c) Es gibt nur ca. 3*10^9 verschiedene IPs und Funkfeuer ist nicht
   allein auf der Welt. Ein typischer Knoten hat zwei devices, das
   macht dann 4 IPs/User! - Es wurde schon vorgeschlagen, das Problem
   durch die Verwendung von IPs aus 10.0.0.0/8 zu lösen, aber da
   waren auch viele Leute dagegen, eben weil die IPs immer wieder
   wo auftauchen.
d) Der olsrd hat bugs, die bei Knoten mit verschiedenen IPs auftreten.
   Ironischerweise wurde der Fix von Markus mit der Begründung
   "nicht RFC konform" auf die lange Bank geschoben. (Hab' das dann
   nicht mehr weiter verfolgt, also sorry, falls der Punkt inzwischen
   aufgelöst ist...)

Liebe Grüße,
Harald