[Discuss] connection tracking? Problem!

[datacop (Clemens Hopfer)]

bei mir und bei bernhard in perchtoldsdorf funktioniert meine Lösung 
recht gut.

der Trick ist das source-netz bei der iptables NAT Regel anzugeben, 
somit kann nur mehr traffic aus diesem Subnetz (LAN) direkt gehen und 
der Rest muss über die default route vom sandwich.

cu,
datacop
> 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.
>