[Discuss] alternatives NAT Package fuer die freifunkfirmware

[Henning Rogge]

2009/2/3 Harald Geyer <(spam-protected)>:
>> 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...
Was nichts an dem Fakt ändert...

Es ist beispielsweise nicht möglich in TCs zwischen zwei Links zu
unterscheiden die zu Nodes gleicher IPs gehen. Genau so wenig ist es
möglich die Hellos dieser beiden Links zu unterscheiden, was zu
Fehlern in der LQ-Berechnung führen kann.

> ... 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.
Also die Sache mit den Interfaces ist ganz eindeutig...

RFC Sektion 1.1:
OLSR interface

A network device participating in a MANET running OLSR.  A node
may have several OLSR interfaces, each interface assigned an
unique IP address.

> Ü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.
Ich würde mittelfristig gerne zu einer Lösung kommen das ein Standort
(evt. mit mehreren verbundenen Linksys-Boxen) sich im Netz wie ein
einheitlicher OLSR-Knoten verhält, d.h. die Verbindungen per Ethernet
werden unsichtbar und die X Geräte tuen so als wären sie eine Box mit
vielen Interfaces (die jedes eine eigene IP drin haben).

>> 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.
Was im Falle von MIDs zum Glück zu nicht so vielen direkten Fehlern im
Code führt. Im Falle von TCs gehen wir beispielsweise von einer
sortierten Liste aus und ich bin nicht sicher was der Code aktuell mit
Duplikaten machen würde.

> 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.
Soweit ich verstanden habe sorgt das Paket von Markus dafür das nur
noch der vom "lokalen Ethernet Interface" kommende Traffic durch das
NAT geht und dann auch noch auf eine gemeinsame IP gesetzt wird.

> 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.)
Die Main-IP ist sogar eigentlich die einzige IP die dann eine (wenn
überhaupt) öffentliche IP braucht.

>> > 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?
Wie schon in einer anderen Mail erwähnt habe verbaut uns das einige
Sachen in Hinsicht der Linkmetriken die ich momentan teste.

>> 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...
Wir wollen mittel- bis langfristig definitv weg von solchen
Doppel-IPs, weil sie im Code immer wieder an unvorhergesehenen Stellen
Ärger machen und Zusatzaufwand bedeuten. Was zu Bugs führt...

>> 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
Wieso sollte sich deine IP ändern wenn du öffentliche IPs hast ?

> 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.
Du braucht die Main-IP des Tunnelservers, mehr sollte dich erstmal
nicht interessieren.

Andererseits könnte man bei wichtigen Servern vielleicht ein
modifiziertes Nameservice-Plugin einsetzen was alle Interfaces in der
Form

vpn0.<name der OLSR Node>
eth0.<name der OLSR Node>

jeweils in die DNS-Tabelle einfügt.

Wäre beim Debuggen eines solchen Servers bestimmt nützlich.

> 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.
Das Problem wird sich mit IPv6 lösen... außerdem muß ja nur eine
öffentliche IP pro Standort (weder pro Interface noch pro Router)
sein, der Rest... nunja, der wird sowieso nur für die "next Hops"
genutzt.

> d) Der olsrd hat bugs, die bei Knoten mit verschiedenen IPs auftreten.
Kannst du das nähere Erklären ?

Im Normalfall haben alle Knoten verschiedene IPs.

>   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...)
Solltest du auf den Wechsel der Main-IP anspielen (wenn das 1.
Interface des OLSR down geht), das kann im TIP einfach dadurch gelöst
werden das du deine Router-ID (und nichts anderes ist die Main-IP)
einfach im Config-File angibst.

Henning

-- 
"Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand
ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt
Marti)