[Discuss] connection tracking? Problem!

[Bernd Petrovitsch]

On Fri, 2007-03-30 at 15:03 +0200, Alexander Stadler wrote:
> Hallo!
> 
> Ich habe da ein Problem mit dem Routing, bei dem ich nicht ganz weiß wie
> die optimale Lösung aussieht.

BTW selbiges ist ganz ganz unten auf
https://wiki.funkfeuer.at/index.php/Tunnel_Setup angedeutet und die
Ursache für den Eintrag am Wiki. datacops Kommentar hab ich BTW nicht
verstanden.

> Mein Hauptrouter (pgm22wlomni.funkfeuer.at) hat neben einem Uplink zum
> Internet mit öffentlicher IP noch den 0xFF Tunnel nach Wien.
> Im Normalfall verwendet der Router dann als Verbindung zum Internet die
> default-Route über den WAN Port.
> Versucht aber jemand den Router über die Adresse
> pgm22wlomni.funkfeuer.at zu erreichen, kommt er über den Tunnel vom
> sandwich.funkfeuer.at zu mir.
> Mein Router muß dann auch zurück über den Tunnel zum Sandwich (wegen/mit
> seiner Funkfeuer IP) antworten. (Seitdem der Router direkt mit dem WAN
> Port auf meinem Internet-Router hängt funktioniert das auch automatisch.
> Und/oder wegen den installierten conntrack Paketen.. .)
> Jedenfalls hängt nun seit einiger Zeit ein weiter Funkfeuer Router per
> Tunnel an meinem.
> Das Problem ist nun, das jeglicher Verkehr von diesem über meine WAN
> default-Route ins Internet geht.
> Wenn dieser (frh75omni.funkfeuer.at) also vom Internet aus gepingt wird,
> geht es zum Sandwich, von dort zu meinem router pgm22wlomni und dann zu
> frh75omni.funkfeuer.at. Von frh75omni zurück zu mir und dann anscheinend
> fälschlicherweise über meine WAN-Route raus, und nicht über den Tunnel
    ^^^^^^^^^^^^^^^^^
> zum Sandwich.

Auf welcher Ebene "fälschlicherweise"?
Auf Layer 3 funktioniert alles zu 100% korrekt - die IP-Pakete werden
gemäß Ziel korrekt geroutet (und die Source-IP-Adresse ist beim Routen
normalerweise irrelevant).

> Woran liegt das, bzw. wie kann ich das Problem umgehen/lösen?

Du willst eigentlich (ganz oben am Layer 8), daß IP-Pakete, die *von*
einer 0xFF-IP-Adresse kommen, u.U. über den Tunnel Richtung sandwich
geroutet werden.
Im Linux-Kernel (keine Ahnung seit wann, aber auf allen aktuellen
Distributionen sollte es gehen) kann man das lösen, indem man mehrere
Routing-Tabellen benützt (und nicht nur eine wie normal) und mit `ip
rule` dem IP-Stack sagt, daß IP-Pakete, die *von* 0xFF-IP-Adressen
kommen, gemäß einer eigenen/anderen Routing-Tabelle als "normal"
geroutet werden sollen. Nur muß das der OLSRD (bzw. der entsprechende
Routing-Daemon) auch unterstützen/machen und dieser anderen
Routingtabelle Routen verwalten. Mit dem implementierten ioctl(3) Ansatz
geht das nicht - da muß man den dort unten umschreiben, damit er netlink
Sockets verwendet.
Ich hab da mal rumgebastelt und einen Patch gebaut, der eigentlich
funktionieren sollte, es aber nicht tut. Tja, not enough time ATM for
such hack stuff .....

> Es sollte wie bei Anfragen an meinen Router sein, dass er die selbe
> Route zurück verwendet. (Und nur die direkten Anfragen ans Internet

Konzeptbug: Ein "IP-Route ist grundsätzlich *immer* etwas
unidirektionales und nichts bidirektionales[0] (wie denn auch anders am
IP-Layer: Da werden einzelne eher mehr als weniger unabhängige Pakete
von Rechner zu Rechner bugsiert).
D.h. daß die Route (bzw. Routen) von $HOST_A zu $HOST_B nicht
notwendigerweise etwas mit der Route (bzw. Routen) von $HOST_B "zurück "
zu $HOST_A zu tun haben muß (bzw. müssen).

> hinaus, ohne vorangehender eingehender Verbindung sollen direkt raus.)

Nächster Konzeptbug: Es gibt keine Verbindungen am IP-Layer.

[...]

	Bernd

[0]: Ja, im 95% aller Fälle schaut es anders aus und verhält es sich
anders. Aber
         deshalb sind die letzten 5% nicht falsch.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services