[WLANware] standard vs. olsr / vpn routing

[C. Gatzemeier]

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