[Wien] Heiligeneich - hle1

[Alexander]

> On Thu, Jul 30, 2009 at 09:37:28AM +0200, Alexander wrote:
>> >> und außerdem ist tunnel falsch konfiguriert
>> > der tunnel nicht, aber vermutlich das routing, allerdings kann man
>> das imho mit einem blick auf die statuspage allein nicht zu 100%
>> beurteilen, ...
>> >
>> >
>> >>
>> >> > default via 85.126.197.233 dev vlan1 anstatt unser tunnel server
>> >> >
>> >> Ich meine nicht dass das falsch konfiguriert ist, sondern das
>> bietet den Vorteil jeglichen non 0xFF Traffic direkt ins INet zu
>> schicken und somit weniger unnötige Last über den Tunnel geht.
>> >
>> > hast du routing policy rules konfiguriert?
>> > wenn nein ist es leider doch falsch gedacht, denn du würdest mit
>> deiner default route auch jeden traffic von anderen funkfeuer usern
>> (wenn diese über deinen knoten routen würden) über deinen provider
>> ins inet schicken, was einige recht unerwünschte konsequezen hat.
>> > lg Markus
>>
>> Wie gesagt passiert dass nur wenn jemand eine nicht Funkfeuer IP
>> erreichen will, da OLSR für jede FF IP sowieso eine Route setzt, bzw.
>> ja ganze Ranges eigene Routes (über Tunnel) bekommen können.
>> -> Ich würde sagen das ganze Netz profitiert nur wenn der Internet
>> Traffic der User möglichst schnell die privaten Leitungen nimmt, und
>> nicht zuerst mal quer durchs 0xFF Netz muß. (Abgesehen natürlich von
>> 0xFF Zielen..) Wieso geht man davon aus das wäre eine falsche
>> Konfiguration. Es wurde doch sogar schon ein Gateway? Plugin für diese
>> Funktionalität geschrieben, und wenn olsrd mehrere Routing Tables
>> verstehen würde könnte man es noch schöner machen selbst wenn der INet
>> Zugang über NAT geht (was ich glücklicherweise nicht mehr brauche,
>> führt dann nämlich zu dem Problem das der Traffic von Inet zu FF IP
>> nicht zurück findet, aber eben nur bei NAT ein Problem weil NAT Router
>> die FF IP als Absender am internen
>> Netzwerkinterface nicht mögen..).
> es ergibt sich folgendes problem:
> mal davon ausgegangen das dein provider dir nicht zulaesst beliebige
> ip's ins netzt zu routen/announcen, wovon ja normalerweise ausgegangen
> werden kann bei privat anschluessen, musst du beim rausrouten NAT
> fahren, d.h. die connections gehen mit deiner ip ins netz.
> so:
> * der traffic schaut fuer alle anderen aus als ob er von dir kommt, das
> kann
> 	rechtliche probleme bringen
> * evtl will das der betreffende nicht weil aus dem einen oder anderen
> grund
> 	die source ip wichtig sein koennte
> * wenn sich die route aendert, d.h. die daten nicht mehr ueber deinen
> knoten
> 	groutet werden, aendert sich fuer die andere seite der verbindung dann
> ploetzlich die source ip -> die verbindung ist weg.
>
> ja es gibt ein gateway plugin fuer olsr, da es einige netze gibt die
> nicht mit oeffentlichen ip's arbeiten, das ist aber meines wissens in
> wien eine gezielte entscheidung das jeder eine oeffentliche ip bekommt
> und so indentifizierbar ist, mit allen vor und nachteilen die das nach
> sich zieht.
>
> mfg
> albert

Um das endlich mal abzuschließen.
Geht nicht einfach von etwas aus das nicht ist!
Wenn ich schreibe da ist kein NAT, dann ist da kein NAT.
Man kanns auch an der default Gatewayadresse ablesen, denn das ist eine
öffentliche IP. Plus nochmal eine eigene öffentliche Inet IP für den 0xFF
Router.

Was sich auch alles leicht verifizieren lässt!
Ping aus dem Internet (non 0xFF IP) auf eine meiner FF IP's und die
Antwort kommt zurück obwohl der default Gateway eben nicht 0xFF ist.
Und dann kann man ja schauen wie die Source IP von der was zurück kommt
ist.. . Da es zurück kommt ist sie logischerweise die 0xFF IP und wird
nicht geblockt. (Genau, es ist kein einfacher Privatanschluß, also nix
gegen Akkus schnelldiagnose. Aber bevor man meine Antwort im vornhinein
anzweifelt könnte man ja auch einfach nachsehen.)

Und wenn ihr aus dem FF Netz pingt gehts aufgrund der Source IP die eine
extra Route vom OLSR hat sowieso übers VPN zurück.
Das ich nicht so gewandt in der Montage bin heißt nicht das ich mit dem
Routing ein Problem hab.. . Damit hab ich mich weitaus mehr beschäftigt.
Ich denke die Uptime sollte für sich sprechen. Die ganzen Configs sind
sehr gut ausgearbeitet.

Bezüglich wenn die alternative Funkstrecke ähnlich hohe kosten hat wie der
Tunnel und sie dann hin und her schalten - das selbe Problem gibts ja am
Funk. Und durch statische Kosten wirds auf jeden fall besser, und gerade
in einem Netz dessen Protokoll für genau diese Fälle gebaut ist wird das
ja nicht wirklich ein Problem werden. (Und sollte der Funk bis nach Wien
jemals besser gehn wie das VPN habe ich noch jemand anderer sicher kein
Problem damit.)

Aber danke für das ausführliche beschäftigen damit.., jedoch ists nicht
das Gebiet auf dem ich Hilfe brauche.

Alexander