Reverse Path Filter--reverse path filter
First, the principle
Introduce the concept of asymmetric routing first
Refer to "Understanding Linux Network Internals" Chapter 30,
30.2. Essential Elements of Routing
Symmetric routes and asymmetric routes
Usually, the route taken from host A to Host B are the same as the route used to get back from Host B to host A; The route is then called symmetric. In complex setups, the route's back is different; In this case, it is asymmetric.
About reverse path filtering, refer to "Understanding Linux Network Internals" chapter 31,
31.7. Reverse Path Filtering
We saw what an asymmetric route are in the section "Essential Elements of Routing in Chapter 30. Asymmetric routes are not common and but may is necessary in certain cases. The default behavior of Linux is to consider asymmetric routing suspicious and therefore to drop any packet whose source I P address isn't reachable through the device the packet was received from, according to the routing table.
However, this behavior can is tuned via/proc on a per-device basis, as we'll, in Chapter 36. Also the "Input Routing" in Chapter 35.
Second, the inspection process
If a host (or router) receives a package from interface A, its source and destination addresses are 10.3.0.2 and 10.2.0.2, respectively.
That is, <saddr=10.3.0.2, daddr=10.2.0.2, Iif=a>, if the reverse path filtering feature is enabled, it will find the routing table in <saddr=10.2.0.2, daddr=10.3.0.2> as the keyword. If the resulting output interface is not a, the reverse path filtering check fails and it discards the packet.
With regard to reverse path filtering, there is a parameter in the IPv4, which is described in Documentation/networking/ip-sysctl.txt.
Rp_filter-integer
0-no source Validation.
1-strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check'll fail.
By default failed packets are discarded.
2-loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet ' s source address is also tested against the FIB
And if the source is not reachable via any interface
The packet check would fail.
Current recommended practice in RFC3704 be to enable strict mode
To prevent IP spoofing from DDos attacks. If Using Asymmetric routing
or other complicated routing, then loose the mode is recommended.
The max value from Conf/{all,interface}/rp_filter is used
When doing source validation on the {interface}.
Default value is 0. Note that some distributions enable it
In startup scripts.
Third, source code analysis
git commit 373da0a2a33018d560afcb2c77f8842985d79594
Net/ipv4/fib_frontend.c
Fib_validate_source int (struct sk_buff *skb, __be32 src, __be32 DST, U8 tos,
193 int oif, struct net_device *dev, __be32 *spec_dst,
194 u32 *itag)
195 {
Whether reverse path filtering is enabled
216/* Ignore Rp_filter for packets protected by IPSEC. */
217 RPF = secpath_exists (SKB)? 0:in_dev_rpfilter (In_dev);
Check the routing table
Note that the source address here is the opposite of the destination address,
See how other functions Call Fib_validate_source ().
if (Fib_lookup (NET, &fl4, &res))
228 goto Last_resort;
Run here to show that the reverse route is up to
The following are divided into two situations to check whether the output device is an input device
237 #ifdef Config_ip_route_multipath
When multiple paths are enabled, any match is used.
238 for (ret = 0; ret < res.fi->fib_nhs; ret++) {
239 struct FIB_NH *nh = &res.fi->fib_nh[ret];
240
241 if (Nh->nh_dev = dev) {
242 Dev_match = true;
243 break;
244}
245}
246 #else
247 if (Fib_res_dev (RES) = DEV)
248 Dev_match = true;
249 #endif
if (Dev_match) {
Reverse path filter Check succeeded, return
251 ret = FIB_RES_NH (RES). Nh_scope >= Rt_scope_host;
252 return ret;
253}
254 if (NO_ADDR)
255 goto Last_resort;
Run here to show that the reverse path check is a failure,
If RPF is 1, it means that the reverse path check must succeed to return normally.
Otherwise, you have to return an error.
256 if (RPF = 1)
257 goto E_RPF;
278 E_RPF:
279 Return-exdev;
Iv. examples
The network has three machines, R1, R2 and PC, subnet mask is 255.255.0.0.
R2 (10.1.0.2)----(10.1.0.1) R1 (10.3.0.1)----(10.3.0.2) PC
R2 (10.2.0.2)----(10.2.0.1) R1
Note that setting the default route for R2 is 10.1.0.1
Now, you can ping the 10.1.0.2 from your PC, but the ping doesn't pass 10.2.0.2.
Tcpdump shows that R2 receives ICMP request, but does not send ICMP reply.
Pc
$ IP A
inet 10.3.0.2/16 BRD 10.3.255.255 Scope Global eth0
$ IP R
10.3.0.0/16 Dev eth0 proto kernel scope link src 10.3.0.2
Default via 10.3.0.1 Dev eth0
R1
$ IP A
inet 10.1.0.1/16 BRD 10.1.255.255 Scope Global eth1
inet 10.2.0.1/16 BRD 10.2.255.255 Scope Global eth2
inet 10.3.0.1/16 BRD 10.3.255.255 Scope Global ETH3
$ IP R
10.1.0.0/16 Dev eth1 proto kernel scope link src 10.1.0.1
10.2.0.0/16 Dev eth2 proto kernel scope link src 10.2.0.1
10.3.0.0/16 Dev eth3 proto kernel scope link src 10.3.0.1
R2
$ IP A
inet 10.1.0.2/16 BRD 10.1.255.255 Scope Global eth1
inet 10.2.0.2/16 BRD 10.2.255.255 Scope Global eth2
$ IP R
10.1.0.0/16 Dev eth1 proto kernel scope link src 10.1.0.2
10.2.0.0/16 Dev eth2 proto kernel scope link src 10.2.0.2
Default via 10.1.0.1 Dev eth1
Excuse me, what is the reason.
You can go back and think about it for 5 minutes ...
My answer is:
Assume that the R2 two interfaces are a (10.1.0.2), B (10.2.0.2) respectively.
When you ping 10.2.0.2 from a PC, the path to the package is pc-->10.3.0.1-->10.2.0.2,
At this time the package of <saddr=10.3.0.2, daddr=10.2.0.2, Iif=b>
With <saddr=10.2.0.2, daddr=10.3.0.2> the reverse path check, the output device is a,
Because the destination address is 10.3.0.2, you can only use the default route. A!=b, the reverse path check failed,
Discard the package.
V. How to Solve
Two ways:
1 on R2:
IP route add 10.3.0.0/16 via 10.2.0.2
Add a route about the 10.3.0.0/16 subnet.
2 on R2:
/etc/sysctl.conf
Net.ipv4.conf.default.rp_filter = 0
Disables reverse path checking.
The original text is http://blog.chinaunix.net/uid-20417916-id-3050031.html
