[Wien] Heiligeneich - hle1

Do Jul 30 16:55:28 CEST 2009

> bin ja von nix ausgegangen hab nur fragen gestellt, und die hintergründe
> für diese erklärt,.. (auch für andere mitlesende)
> .
> und ack dieser thread ist eigntlich ein bißchen sinnlos,... (dient nur
> der weiterbildung der beteiligten) denn deine defaultroute der
> statsuseite matched eh nie,... *g
> .
> darum kann man nicht so wie du vorgeschlagen hast nachprüfen ob dein
> provider fremde source-ip routen würde weil nunmal eh jeglicher traffic
> deines funkfeuer routers über den tunnel zum tunnelserver geht *g (aber
> ich kanns gern mal nachts ausprobieren, muss dafür nur die roofnodes
> preparieren, oder du konfiguriest bei dir entsprechend)
> .
> hier z.b. ein ping -R vom subway
> RR: 78.41.115.65 (zwar eine 0xff ip, aber keine per oslr announcte, d.h.
> müsste laut deinem wunsch, und akkus befürchtung über deinen provider
> retour gehen *g)
>   78.41.113.119 (kryptaroof)
>   78.41.112.2 tunnel
>   193.238.158.61 pgm22
>   193.238.158.61pgm22
>   78.41.115.197 tunnel
>   78.41.115.65 subway
> .
> warum eh (so wie wir es idr gern hätten) über den tunnelserver retour
> routet will ich aber jetzt nicht breittreten *g
> .
> weiters sind ein paar der bei dir konfigurierten ips wohl nicht mehr
> deine,..
> .
>   inet 193.238.158.61/22 brd 193.238.159.255 scope global eth1
> pgm22wlomni.pgm22.wien.funkfeuer.at.
>   inet 193.238.158.60/32 brd 193.238.158.60 scope global eth1:0
> mq.mq.wien.funkfeuer.at
>   inet 193.238.158.58/32 brd 193.238.158.58 scope global eth1:1
> pgm22dmz.pgm22.wien.funkfeuer.at
>   inet 193.238.158.59/32 brd 193.238.158.59 scope global eth1:2
> pgm22wldhcp.pgm22.wien.funkfeuer.at.
>   inet 193.238.158.62/32 brd 193.238.158.62 scope global eth1:3
> pgm22lomni.pgm22.wien.funkfeuer.at
>   inet 193.238.158.63/32 brd 193.238.158.63 scope global eth1:4
> test2.mq.wien.funkfeuer.at
>   inet 193.238.158.57/22 brd 193.238.159.255 scope global tap0
> pgm22vomni.pgm22.wien.funkfeuer.at
>   inet 193.238.159.173/22 brd 193.238.159.255 scope global tap1
> frh75vremote.frh75.wien.funkfeuer.at
> .
> lg Markus
> 2009/7/30 Alexander <(spam-protected)>
>
>> > 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
>>
>>
>>
>> --
>> Wien mailing list
>> (spam-protected)
>> http://lists.funkfeuer.at/mailman/listinfo/wien

Hallo Markus!

Find deine Fragen eh voll okay, nicht falsch verstehen.
Es nervt halt nur etwas, da ich das Routing wie man sieht ganz bewusst so
und nach allen geltenden Wünschen bzw. Regeln gestaltet habe.
Und jeder glaubt gleich da passt irgendwas nicht weils weit entfernt von
standard ist.
Zu den einzig wichtigen Punkten (Montage) kommt keine einzige Antwort. Und
das ist der einzige Grund warum das ganze nicht in "Produktion" ist.
Ich hab schon mal welche bekommen, aber das war eben schweißen oder
irgendwelche Rohrklemmen, das war mir zu sehr Bastellösung.. .

Wenn die IP's wirklich nicht mehr bei mir eingetragen sind, ist euch da
wohl ein Fehler unterlaufen, denn wie wir alle wissen ist es sehr wichtig
dass dies auch an den der sie eingetragen hat geht.. . Machts mir jetzt
auch nicht unbedingt leichter bei stehender Antenne die 2 Router wieder
ans Netz zu bringen.

Zu deinem Test:

Das liegt daran weil ich
78.41.115.128/25 via 78.41.112.2 dev tap0  metric 1
193.238.157.0/25 via 78.41.112.2 dev tap0  metric 1
eingetragen habe, damit auch wirklich alle 0xFF IP's über den Tunnel gehen
wie es gewünscht ist, unabhängig vom OLSR.. .

Aber ansonsten kann aufgrund dessen, das aus dem Inet gesendete ICMP
Pakete (mit der FF IP) zurück kommen schon davon ausgegangen werden das
die Pakete mit der 0xFF Source IP akzeptiert werden (da sich das Routing
nur für die Destination interessiert, und die die selbe ist, ob jetzt ein
anderer Knoten ins INET will, oder das ICMP Paket zurück ins INET will).
(Ist zwar nicht ganz so ein zuverlässiger Test wie mit einem angehängten
Knoten, aber es hat ja ursprünglich nicht funktioniert, ich habs erst dazu
gebracht, deswegen bin ich mir da sicher.., und wie erwähnt läuft das
extra nicht über nen Home Anschluß, deswegen gehts ja.)

lg

Alexander