[WLANware] standard vs. olsr / vpn routing

[Sven-Ola Tuecke]

Hi,

mmh. Mann kann's beliebig kompliziert machen. Wenn ich's richtig verstehe, 
willst du eine dritte Default-Routen-Domain:

eine fuer alle anderen
eine fuer VPN-Tunnel-Nutznieszer
eine fuer den VPN-Daemon selbst?

das wird wuest - einen einfachen Vorschlag hab' ich da erstmal nicht.

// Sven-Ola

""C. Gatzemeier"" <c.gatzemeier at tu-bs.de> schrieb im Newsbeitrag 
news:200712021912.10756.c.gatzemeier at tu-bs.de...

Hallo liebe Freifunker,

beim Routing komme ich mit meinem derzeitgem Wissen nicht weiter.

Woran ich bastele:
In einem x.x.x.x Freifunk Netz möchte ich einem Knoten K (x.x.x.K) eine
default route geben, die über ein vpn zu einem Gateway G (x.x.x.G) im
Freifunk Netz führt. So das K über das vpn die default route des G nutzen
kann.

Ich habe gelesen, dass, damit die default route nicht als "HNA"(heist was?)
über OLSR bekannt gegeben wird, in der OLSR Einstellung von x.x.x.G "policy
routing" zu aktivieren ist. Also hatte ich das aktiviert um nicht evtl.
andere zu stören, wenn ich das forwarding von nicht-vpn traffic per iptables
später auf reject leite.

Ohne "OLSR-HNA" Bekanntgabe bekommt ein Knoten x.x.x.K natürlich nichts von
der default route mit, also dachte ich mir leg ich zum Testen ohne vpn eine
default route per hand an (route add default gw x.x.x.G). Habe aber
festgestellt das das nicht geht.
Per tcpdump ist zu sehen wie x.x.x.K bei einem ping der geroutet werden muss
selbst per arp auf dem wlan device who-is-x.x.x.G nachfragt, anstatt den
echo-request an den nächsten olsr-hop zu routen. Ein ping auf x.x.x.G
funktioniert problemlos.

Na gut, olsr nutzt offensichtlich eine eigene routing tabelle. Das hat sich
auch bestätigt als mir auffiel das mit deaktiviertem policy-routing die 
Sache
funktioniert, ohne das vom OLSRD in die mir bekannte "normale" routing
Tabelle eine default route eingetragen wird.


Nun habe ich aber scheinbar eine ganz ähnliche routing Aufgabe zu lösen, 
wenn
ich auf K eine default route via G eintragen möchte die durch den vpn tunnel
(v.p.n.K <---> v.p.n.G) geht.

Das vpn (tinc) ist eingerichtet und läuft, die vpn-IPs sind untereinander
pingbar. Die DNS-Namensauflösung funktioniert über das vpn.

Aber sobalt die Zieladresse eines pings (oder anderer IP Traffic) nicht eine
Adresse aus dem vpn Bereich ist (FF-Router oder PCs im Lan hinter den
FF-Routern), sondern an x.x.x.G gehen müssten, um von dort z.B. an foo.bar
geforwardet zu werden, funktioniert es nicht mehr. :-(

Auf x.x.x.G kommt auser der DNS Abfrage und Antwort nichts durch den Tunnel
an.
Auf x.x.x.K sind per tcpdump -i vpn nach den echo-request Paketen 
"destination
net unreachable" Paktete zu sehen, angeblich von "foo.bar" an x.x.x.k.
Der Ping Befehl endet mit 100% package loss.

Ist es evtl. meine routing Methode die hier, wie bei olsr, nicht hinreicht?

Um laufende dyn-gw plugins nicht durcheinander zu bringen hab ich zuerst 
zwei
Routen verwendet die einen evtl. default gateway vom WAN "überdecken":
route add -net 0.0.0.0 netmask 128.0.0.0 gw v.p.n.G
route add -net 128.0.0.0 netmask 128.0.0.0 gw v.p.n.G

Aber auch eine "normale"? default route stattdessen brachte keine Besserung:
route add default gw v.p.n.G

In den /etc/local.fw hab ich für in/out und forwarding der vpn devices 
ACCEPT
rules. Per iptables -L -vv [-t nat] sind keine drop/reject packages
auszumachen. Ich hab auch schon probeweise bei K und
G /etc/init.d/S45firewall stop probiert.

Das Routing will einfach nicht, während DNS Abfragen oder auch Verbindungen
per ssh -L 8008:foo.bar:80 root at x.x.x.G (und auch v.p.n.G) gehen.

Auf G besteht eine default route die per dhcp vom WAN interface stammt, 
pings
und nslookups laufen.

Mir fehlen jetzt leider weitere Diagnose Ideen.

Christian
_______________________________________________
WLANware mailing list
WLANware at freifunk.net
Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware

Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung 
unter http://freifunk.net/mailinglisten