Re: [LARTC] policy routing problem

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tomas,

 : hello martin, i was sitting here and waiting for your answer, thank you
 : ;x

I hope you didn't sit there waiting for this answer!

 : (for ease in the migration i use table 'main' with all routes and table
 : 'test' with only routes to 192.168.1/24 and prohibit 0/0.)
 :
 : root@xxxxxxxxxxx:~# ip rule show
 : 0:      from all lookup local
 : 31000:  from 172.16.1.2 to 195.43.36.55 lookup main
 : 31100:  from 195.43.36.55 to 172.16.1.2 lookup main
 : 32000:  from 192.168.1.0/24 lookup main
 : 32100:  from 192.168.4.0/24 lookup main
 : 32200:  from 192.168.2.0/24 lookup main
 : 32300:  from all to 192.168.4.1 lookup main
 : 32400:  from all to 192.168.2.2 lookup main
 : 32500:  from all lookup test
 : 32766:  from all lookup main
 : 32767:  from all lookup default
 :
 : root@xxxxxxxxxxx:~# ip route show table main
 : 192.168.4.0/24 dev eth2  scope link
 : 192.168.2.0/24 dev eth0  scope link
 : 192.168.1.0/24 dev eth1  scope link
 : 10.47.17.0/24 via 192.168.2.1 dev eth0
 : 172.16.1.0/24 via 192.168.4.2 dev eth2
 : 10.46.23.0/24 via 192.168.2.1 dev eth0
 : 192.168.75.0/24 via 192.168.2.1 dev eth0
 : 10.100.0.0/16 via 192.168.2.1 dev eth0
 : 127.0.0.0/8 dev lo  scope link
 : default via 192.168.2.1 dev eth0
 :
 : root@xxxxxxxxxxx:~# ip route show table test
 : 192.168.1.0/24 dev eth1  scope link
 : 127.0.0.0/8 dev lo  scope link
 : prohibit default
 :
 : things i like to clarify:
 : 1. rules 31000 and 31100 is just so that one address on a defined network can reach an
 : 	address on the internet, and that works perfect.

Looks perfect.

 : 2. rules 32100-32400 is supposed to be so that the router can reach
 :    defined networks, this does not work.

This may be part of the "which comes first, the chicken or the egg"
scenario you alluded to in your previous mail.  I'm still trying to wrap
my mind around the intertwined relationship between source address
selection and route selection.  I can't answer your implied question about
why this doesn't work, nor can I answer your previous question about the
ARP queries which never have a following ethernet frame with IP payload.

Maybe one of the people more familiar with the kernel source code can help
out here.

 : 3. the reason of having so many routes in table main is just plain stupid
 :    when the default is the same as there "via..". i will change this in
 :    a near future but i added the networks so that it would be more
 :    clear what i was doing.

Clarity appreciated.

 : some ascii art over the network:

How about some modified ASCII art!  Everybody loves ASCII....

    0/0 internet -----+ +-------------+ +---- defined networks ipsec
                       \|      fw     |/       10.47.17.0/24
                        +-------------+        10.46.23.0/24
                        192.168.2.1/24         10.100.0.0/16
                                |              192.168.75.0/24
                                |
                        192.168.2.2/24
                        +-------------+
        192.168.4.1/24 /| linux router|\ 192.168.1.1/24
                      / +-------------+ +--- LAN
      192.168.4.2/24 /
          +------------+
          |   voip     |
          +------------+
               |
               +-- 172.16.1.0/24

This is what I'm able to gather from your routes and diagram, and you,
sir, have a garden of networks.

I think what you want to do on "linux router" is to try the following
(idiomatic) RPDB entry.

# ip rule add iif lo table all    # -- or table main in above case

I know it seems a very simple answer, to a complex question, but I hope it
will work for you.

By the way, Tomas, did you know that you can have rule types in the RPDB,
e.g.,

# ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8
# ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24
# ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24

OK, I know that tidbit doesn't help you in your current troubles, but I
was hoping that the "iif lo" trick might help.


-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux