Last change
on this file since 2347 was
1788,
checked in by mitchb, 13 years ago
|
Switch from "strict" to "loose" reverse-path filtering
Reverse-path filtering controls what happens when you receive
traffic on an interface directly claiming to be from an IP address
that your routing rules indicate shouldn't be part of the network(s)
directly attached to that interface. It's meant to help guard against
IP spoofing. There are three legal values:
0 - "off" - does not block anything
1 - "strict" - blocks any traffic that "shouldn't" have arrived on
this interface according to your routing rules
2 - "loose" - blocks any traffic that "shouldn't" have arrived on
any of your interfaces according to your routing rules
(but allows traffic from addresses that should be on
directly attached networks and arrive on the "wrong"
interface); recommended for sites with asymmetric
routing configurations where traffic to a given address
is expected to return through a different interface than
it leaves on
A normal non-multihomed machine should usually use "strict" mode,
and in fact this was a simple boolean between "off" and "strict"
in older kernels throguh somewhere in the 2.6.20s. Back then,
the kernel ANDed the value of net.ipv4.conf.all.rp_filter and
net.ipv4.conf.${iface}.rp_filter, so to enable it, you needed to
turn it on under both "all" and the interface hierarchy. When it
became a trinary value, this logic was overlooked, so the only
(undocumented) way to use "loose" mode on some interfaces and
"strict" mode on others was to set rp_filter in the "all" hierarchy
to the undocumented value "3". At some point in 2.6.31, the
rp_filter behavior was corrected to use the max() of the "all" and
interface value.
Until now, we've been setting net.ipv4.conf.default.rp_filter to "1",
which causes the interface values to be "1". The "all" value
defaults to "0" on Fedora. Since the last kernel in Fedora 11 was
2.6.30.10, this means that we never actually used reverse-path
filtering until we upgraded to Fedora 13, at which point we began
using strict filtering without intending to have changed anything.
This behavior is incorrect for us because we do have asymmetric
routing scenarious and intend to add more. The specific
example where we want this is to allow a Scripts LVS realserver
to also be an LVS client. It will send traffic to the Scripts
LVS-balanced IP addresses on the frontend network (eth0) because
those addresses only exist on the frontend, where LVS will assign
it to a given realserver to handle and forward it along. That
realserver will try to respond to the requesting realserver
on the backend network (eth1) because of the static routes we
have installed to prefer servers talking to each other over
the non-public segment. If rp_filter is in "strict" mode, this
traffic will be dropped, and the scripts servers on the backend
can never talk to the balanced addresses. We also want non-realserver
machines on our backend network (such as not-backward) to be able
to be LVS clients.
|
File size:
442 bytes
|
Rev | Line | |
---|
[39] | 1 | net.ipv4.ip_forward = 1 |
---|
[1788] | 2 | net.ipv4.conf.all.rp_filter = 2 |
---|
[39] | 3 | net.ipv4.conf.default.accept_source_route = 0 |
---|
[799] | 4 | kernel.panic = 5 |
---|
[421] | 5 | kernel.sysrq = 1 |
---|
[39] | 6 | kernel.core_uses_pid = 1 |
---|
[1006] | 7 | vm.panic_on_oom = 1 |
---|
[39] | 8 | net.ipv4.tcp_syncookies = 1 |
---|
| 9 | net.ipv4.conf.default.arp_ignore = 1 |
---|
| 10 | net.ipv4.conf.default.arp_announce = 2 |
---|
| 11 | net.ipv4.conf.all.arp_ignore = 1 |
---|
| 12 | net.ipv4.conf.all.arp_announce = 2 |
---|
[325] | 13 | net.ipv4.tcp_keepalive_time = 825 |
---|
[115] | 14 | afs.GCPAGs = 0 |
---|
[1688] | 15 | kernel.modprobe = /etc/scripts/modprobe |
---|
Note: See
TracBrowser
for help on using the repository browser.