🚀 go-pugleaf

On 09.12.2007, Daniel Rejmer <eekkaannss@ggoo22.ppll> wrote:
> Witam,
> mam taki oto problem i nie bardzo wiem jak go rozwiazac:
>
> Do witch wpiete sa 3 maszyny i maja takie adresy:
> --------------------------------
>|            Switch            |
> --------------------------------
>      |           |           |
> serwerwww     router       host
> 1.1.1.1/24  1.1.1.2/24  1.1.1.3/24
  ^^^^^^^^^^
> 2.2.2.1/24  2.2.2.2/24
>   MAC1        MAC2        MAC3
>
> Host ma brame domyslna ustawiona na 1.1.1.2
> Z hosta do 1.1.1.1 komunikacja jest ok.
> Ale z hosta do 2.2.2.1 jest problem, bo pakiety wygladaja tak:
>
> 1.1.1.3[MAC3] -> 2.2.2.1[MAC2]
> 1.1.1.3[MAC2] -> 2.2.2.1[MAC1]
>    dotad jest ok, ale w druga strone:
> 2.2.2.1[MAC1] -> 1.1.1.3[MAC3]
>
>   a host nie oczekuje odpowiedzi od MAC1, tylko od swojej bramy.

Podkreśliłem problem. serwerwww (1.1.1.1) zna dobrą trasę do host
(1.1.1.3). Dobrą, to znaczy wie, że host jest jego sąsiadem, dlatego
odpowiedź nie idzie przez default gw, tylko bezpośrednio.

> Nie chcialbym za bardzo ruszac ustawien hosta(za duzo jest hostow), ale 
> swobodnie moge manewrowac i routerem i serwerem.

Przeciętny Linux czy przeciętny Windows bez problemu sobie powinien
poradzić z taką sytuacją. A jak jeszcze włączysz ICMP redirects na
routerze, to nawet router nie będzie musiał przerzucać transmisji
z interfejsu na ten sam interfejs.

> Pytanie jak przekonac 
> serwer aby odsylal odpowiedzi tam, skad przybyly a nie tam gdzie mu 
> najblizej?

Jeśli już chcesz sobie wkładać pogrzebacz w ucho, to zrób na serwerwww
tak[*]:
#v+
ip rule add from 1.1.1.0/24 table jeden
ip rule add from 2.2.2.0/24 table dwa
ip route add 1.1.1.0/24 dev lan1 table jeden
ip route add default via 1.1.1.2 table jeden
ip route add 2.2.2.0/24 dev lan1 table dwa
ip route add default via 2.2.2.2 table dwa
#v-
Zagadka: dlaczego to zadziała?

[*] Nie testowane, ale to tak prosta konstrukcja, że nie ma prawa
*nie działać*.

-- 
Secunia non olet.
Stanislaw Klekot