Under normal circumstances, as long as there is a route to a machine, no matter which network card address the service listens to, or from which network card the request enters, as long as the target IP address of the request is an IP address of the machine, the connection will be successful, of course, you can set a policy route or the destination address blocked by the multi-Table route table item is not configured when the data enters the NIC.
Instance:
R has two NICs, each of which is configured as follows:
Eth0: 172.16.0.1
Eth1: 192.168.0.1
Lo: 127.0.0.1
Lo: 0: 1.2.3.4
To hide the IP address on the lo port, configure the following:
Sysctl-W net. ipv4.conf. Lo. arp_ignore = 2
The PC has a network card and is directly connected to the R's eth0:
Eth0: 172.16.0.3
Ping 1.2.3.4 on the PC. Then add a route entry on the PC:
1.2.3.4 GW 192.168.0.1
Then ping 1.2.3.4.
Role of arp_ignore:
1. The value is 0. As long as the ARP request can be received, all ARP requests are returned. The MAC address is the MAC address of the NIC that receives the ARP request.
2. The value is 1. Only the IP address is configured on the NIC that the ARP request enters.
3. If the value is 2-2, it must be met, and the source IP address of the ARP request and the request IP address must belong to the same subnet before replying.
4. Value: 3 -- if the IP address of the ARP request is the IP address of the scope host, no reply will be made.
5. value 7 -- no reply
Note:
1. scope: Scope indicates a range. It is an attribute of an IP address. That is to say, the IP address is available and addressable in this range. The kernel is well arranged, enumeration rt_scope_t actually indicates a "distance" from the destination. The greater the value, the smaller the range. For example, an IP address starting with 127 can only be used by the local machine, so its scope is the host. This scope can be set when configuring an IP address for the NIC, if you set the scope of the IP address to host, this means that you may only need this IP address in your machine. You can easily set arp_ignore to 4 to hide this IP address. The host address can be used for Server Load balancer and virtual Nic or multi-nic binding. The link address is used for direct connection to the host, and can be used by global. Not only does the IP address have the scope attribute, but also routes have the scope attribute.
2. Which network port does the ARP request enter? ARP replies must be sent from the network adapter. For more information, see the arp_process function. Because the entry Dev is also part of the route lookup key
Source code level:
1. The value is 0. -- The system directly returns "Mac that can reply to the ARP request entry"
2. The value is 1 -- use DST = 0; Scope = rt_scope_host; call inet_confirm_addr.
3. The value is 2 -- inet_confirm_addr is called only by using scope as the host.
4. Value: 3 -- call inet_confirm_addr using scope as Link
No matter the value is a few, if the ARP request is to be replied, the reply is the MAC address of the ARP request entry. This arp_ignore function only determines whether the request can be replied, it has different constraints with Different kernel parameters. The following describes the implementation of the inet_confirm_addr function:
U32 inet_confirm_addr (const struct net_device * Dev, u32 DST, u32 local, int scope)
{
...
If (Dev) {// For the host that receives the ARP broadcast and will send the ARP unicast response, Dev is strictly the dev of the ARP request, therefore, when Dev is set, you cannot expect non-ARP requests to access the IP address response on the NIC.
If (in_dev = _ in_dev_get_rcu (Dev )))
ADDR = confirm_addr_indev (in_dev, DST, local, scope );
Return ADDR;
}
For (Dev = dev_base; Dev = Dev-> next) {// if Dev is not specified, all Dev are traversed, however, you still cannot expect a response from an IP address configured on the loopback, because loopback does not have a MAC address at all, and since it will never receive ARP requests, it will never reply to it, see Experiment 0.
If (in_dev = _ in_dev_get_rcu (Dev ))){
ADDR = confirm_addr_indev (in_dev, DST, local, scope );
If (ADDR)
Break;
}
}
Return ADDR;
}
Experiment 0 (Note: Clear the ARP cache when Ping is performed next ):
Eth0 of pC1: 192.168.1.3 up
Eth1 of pC1: 172.16.1.3 no network cable inserted
Eth1: 1: 1.2.3.4 scope link of pC1
Lo: 1: 4.3.2.1 scope link of pC1
Direct Connection Between eth0 of Pc2: 192.168.1.4 up and eth0 of pC1
1. Set arp_ignore of eth0 of pC1 to 3.
Ping 1.2.3.4 on PC2. Ping 4.3.2.1.
Add a route entry to 1.2.3.4 and 4.3.2.1 on PC2, ping the route entry, and access the route entry, and set the MAC address of eth0 in pC1 as the IP address of the second IP address in ARP.
2. Set arp_ignore of eth0 of pC1 to 0.
Ping again according to 1, because ARP requests are replied as long as they are received.
3. Set the arp_ignore of eth0 of pC1 to 1 and 2.
Ping again according to 1. The destination IP address is not configured on the NIC that receives the ARP request. the IP address of the other sender and the destination IP address of the ping are not in the same subnet.
4. Set arp_ignore of eth0 of pC1 to 3, but re-configure the following:
Eth1: 1: 1.2.3.4 scope host of pC1
Ping 1.2.3.4 on PC2. The connection fails. If arp_ignore is set to 3, the IP address of the scope is not allowed to be returned even if the connection between the NIC device and the IP address is not checked.
Finally, the scope attribute of the route is analyzed based on the so_dontroute option. The scope attribute of a route indicates the distance between the destination address and the local address. Like the IP address scope, it can be divided into host, link, and global. When you add a route through the IP route command, if a gateway is added to a route (via the via Parameter), you cannot use the scope Link parameter. That is to say, you can only use one route (VIA) or direct connection route through the gateway, therefore, when a route is added, this constraint makes the scope not messy. The essence of the so_dontroute parameter is that it does not use the gateway for routing. Therefore, only the table items whose scope is link will be found before the connection with this option sends data, if you do not believe that the behavior of dontroute is true, you may try to set a route, and then force the dontroute data packet to go to the route you set, that is to say, if you give it a "Next Hop" instead of letting it directly reach the destination, can you add this route? If you set the via nexthop parameter, the scope cannot be the link, so the query route fails, and then the transfer is sent directly. If you add a direct connection route, it is very good, route lookup will not fail, and the protocol stack will use the lookup results. Because dontroute's policy is to find the route and send it according to the route. If no route is found, it will be sent directly, provided that an egress Nic device is set, A data packet sent with the dontroute flag may find a route and use it if it is a directly connected route.