[Wien] Heiligeneich - hle1

Do Jul 30 16:22:31 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
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20090730/1a5772e6/attachment.htm>