内核rp_filter参数

内核文档：https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt 搜其关键字，可见rp_filter定义如下：

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 will 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 address is not reachable via any interface
	    the packet check will fail.

	Current recommended practice in RFC3704 is to enable strict mode
	to prevent IP spoofing from DDos attacks. If using asymmetric routing
	or other complicated routing, then loose 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.

在RFC3704文档https://tools.ietf.org/html/rfc3704#page-5 中可见Strict Reverse Path Forwarding定义如下：

Strict Reverse Path Forwarding (Strict RPF) is a simple way to
   implement an ingress filter.  It is conceptually identical to using
   access lists for ingress filtering, with the exception that the
   access list is dynamic.  This may also be used to avoid duplicate
   configuration (e.g., maintaining both static routes or BGP prefix-
   list filters and interface access-lists).  The procedure is that the
   source address is looked up in the Forwarding Information Base (FIB)
   - and if the packet is received on the interface which would be used
   to forward the traffic to the source of the packet, it passes the
   check.

   Strict Reverse Path Forwarding is a very reasonable approach in front
   of any kind of edge network; in particular, it is far superior to
   Ingress Access Lists when the network edge is advertising multiple
   prefixes using BGP.  It makes for a simple, cheap, fast, and dynamic
   filter.

   But Strict Reverse Path Forwarding has some problems of its own.
   First, the test is only applicable in places where routing is
   symmetrical - where IP datagrams in one direction and responses from
   the other deterministically follow the same path.  While this is
   common at edge network interfaces to their ISP, it is in no sense
   common between ISPs, which normally use asymmetrical "hot potato"
   routing.  Also, if BGP is carrying prefixes and some legitimate
   prefixes are not being advertised or not being accepted by the ISP
   under its policy, the effect is the same as ingress filtering using
   an incomplete access list: some legitimate traffic is filtered for
   lack of a route in the filtering router's Forwarding Information
   Base.

   There are operational techniques, especially with BGP but somewhat
   applicable to other routing protocols as well, to make strict RPF
   work better in the case of asymmetric or multihomed traffic.  The ISP
   assigns a better metric which is not propagated outside of the
   router, either a vendor-specific "weight" or a protocol distance to
   prefer the directly received routes.  With BGP and sufficient
   machinery in place, setting the preferences could even be automated,
   using BGP Communities [2].  That way, the route will always be the
   best one in the FIB, even in the scenarios where only the primary
   connectivity would be used and typically no packets would pass