Use linux for route forwarding and linux for route forwarding

Use linux for route forwarding and linux for route forwarding

Use a linux system (PC) for route forwarding

Keywords: linux, Fedora, route, iptables, ip_forward

　　I recently conducted a network experiment and used the linux forwarding function during the experiment. However, I encountered some problems and finally solved the problem after I consulted some netizens about linux network technology, after the problem is solved, I start to summarize the cause of the previous failure and write the course into a blog post for your reference in the future.

1. Network Topology

　　The network topology is as follows. Here we use three machines for experiment, namely machine ①, machine ④, and machine 7th. Machine ① is used to ping machine 7th and machine ④ is used as route forwarding.

　　

2. incorrect route Configuration

　　First, we use the following configuration method to configure the route tables of the three hosts:

1) configure the following in HOST 1 to allow the destination CIDR Block 10.0.4.0/24 to exit from Port eth1.

route  add -net 10.0.4.0/24 dev eth1

Run the following command to view the route table of host ①:

route -n

The route table of machine ① is as follows:

 

2) configure the route using the same method on host 7. The result is as follows:

 

3) configure the route forwarding function on host 4. Set the value of net. ipv4.ip _ forward in the/etc/sysctl. conf file to 1:

 

4) All configurations have been completed. We can ping host ④ on host ①.

ping  10.0.4.3

The result is as follows:

PING 10.0.4.3 (10.0.4.3) 56(84) bytes of data.From 10.0.1.3 icmp_seq=2 Destination Host UnreachableFrom 10.0.1.3 icmp_seq=3 Destination Host UnreachableFrom 10.0.1.3 icmp_seq=4 Destination Host UnreachableFrom 10.0.1.3 icmp_seq=6 Destination Host UnreachableFrom 10.0.1.3 icmp_seq=7 Destination Host UnreachableFrom 10.0.1.3 icmp_seq=8 Destination Host Unreachable

For the convenience of research, the eth1 configuration of machine ① is released.

eth1      Link encap:Ethernet  HWaddr 00:16:EC:AF:CB:CB            inet addr:10.0.1.3  Bcast:10.255.255.255  Mask:255.255.255.0          inet6 addr: fe80::216:ecff:feaf:cbcb/64 Scope:Link          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:4564 errors:0 dropped:0 overruns:0 frame:0          TX packets:6688 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000           RX bytes:459463 (448.6 KiB)  TX bytes:546633 (533.8 KiB)          Interrupt:23 Base address:0x6000 

When I ping machine ①, I capture the eth1 package on machine ④. The result is as follows:

[Root @ h4 ~] # Tcpdump-I eth1-enn
Tcpdump: verbose output suppressed, use-v or-vv for full protocol decode
Listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:26:44. 388614 00: 16: ec: af: cb> ff: ff, ethertype ARP (0x0806), length 60: request who-has 10.0.4.3 tell 10.0.1.3, length 46
15:26:45. 391014 00: 16: ec: af: cb> ff: ff, ethertype ARP (0x0806), length 60: request who-has 10.0.4.3 tell 10.0.1.3, length 46
15:26:47. 387821 00: 16: ec: af: cb> ff: ff, ethertype ARP (0x0806), length 60: request who-has 10.0.4.3 tell 10.0.1.3, length 46
15:26:48. 391220 00: 16: ec: af: cb> ff: ff, ethertype ARP (0x0806), length 60: request who-has 10.0.4.3 tell 10.0.1.3, length 46
15:26:49. 392621 00: 16: ec: af: cb> ff: ff, ethertype ARP (0x0806), length 60: request who-has 10.0.4.3 tell 10.0.1.3, length 46

It can be seen that the mac address of the host with the 10.0.4.3 IP address is always in the search for arp packets. However, routers (machines ④) do not forward arp packets by default. All machines ① can never be pinged.

 

3,Correct Configuration

　　Configure the route in HOST 1 with the following command:

route add -net 10.0.4.0/24 gw 10.0.1.2

At this time, the route table of machine ①:

[root@h1 ~]# [root@h1 ~]# route -nKernel IP routing tableDestination     Gateway         Genmask         Flags Metric Ref    Use Iface10.0.4.0        10.0.1.2        255.255.255.0   UG    0      0        0 eth110.0.5.0        0.0.0.0         255.255.255.0   U     0      0        0 eth210.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1192.168.99.0    0.0.0.0         255.255.255.0   U     1      0        0 eth00.0.0.0         192.168.99.1    0.0.0.0         UG    0      0        0 eth0

 

Configure the route table of Machine 7 in the same way

　　

Root @ h7 :~ # Route-n kernel IP route table destination gateway subnet mask flag hop reference using interface 0.0.0.0 192.168.99.1 0.0.0.0 UG 0 0 0 255.10.0.4.2 255.255.255.0 UG 0 0 0 eth110.0.4.0 0.0.0.0 255.255.255.0 U 1 0 255.0.0.0.0 255.255.255.0 U 1 0 0 eth2192.168.99.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0

 

Next, ping the machine. ping the machine on machine ①. The ping is successful. Here we asked for a convenient analysis. First, we listed the MAC addresses of each Nic.

Eth1: HWaddr 00: 16: EC: AF: CB ④ eth1: HWaddr 40: 61: 86: 32: 8F: 0B ④ eth4: HWaddr 40: 61: 86: 32: 8F: 0E 7th machine eth1: HWaddr 00: 25: 90: 93: 40: 79

 

The packet captured by eth1 is as follows:

[root@h4 ~]# tcpdump -i eth1 -enntcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes16:02:26.809445 00:16:ec:af:cb:cb > 40:61:86:32:8f:0b, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 1, length 6416:02:26.810723 40:61:86:32:8f:0b > 00:16:ec:af:cb:cb, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 1, length 6416:02:27.811847 00:16:ec:af:cb:cb > 40:61:86:32:8f:0b, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 2, length 6416:02:27.813136 40:61:86:32:8f:0b > 00:16:ec:af:cb:cb, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 2, length 6416:02:28.813248 00:16:ec:af:cb:cb > 40:61:86:32:8f:0b, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 3, length 6416:02:28.814551 40:61:86:32:8f:0b > 00:16:ec:af:cb:cb, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 3, length 6416:02:29.814648 00:16:ec:af:cb:cb > 40:61:86:32:8f:0b, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 4, length 64

The eth4 packet capture on machine ④ is as follows:

root@h4 ~]# tcpdump -i eth4 -enntcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth4, link-type EN10MB (Ethernet), capture size 65535 bytes16:02:26.809460 40:61:86:32:8f:0e > 00:25:90:93:40:79, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 1, length 6416:02:26.810715 00:25:90:93:40:79 > 40:61:86:32:8f:0e, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 1, length 6416:02:27.811853 40:61:86:32:8f:0e > 00:25:90:93:40:79, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 2, length 6416:02:27.813130 00:25:90:93:40:79 > 40:61:86:32:8f:0e, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 2, length 6416:02:28.813255 40:61:86:32:8f:0e > 00:25:90:93:40:79, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 3, length 6416:02:28.814545 00:25:90:93:40:79 > 40:61:86:32:8f:0e, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 3, length 64

The packet capture function of eth1 is as follows:

root@h7:~# tcpdump -i eth1 -enntcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes16:02:27.222853 40:61:86:32:8f:0e > 00:25:90:93:40:79, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 1, length 6416:02:27.222867 00:25:90:93:40:79 > 40:61:86:32:8f:0e, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 1, length 6416:02:28.225226 40:61:86:32:8f:0e > 00:25:90:93:40:79, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 2, length 6416:02:28.225237 00:25:90:93:40:79 > 40:61:86:32:8f:0e, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 2, length 6416:02:29.226638 40:61:86:32:8f:0e > 00:25:90:93:40:79, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 3, length 6416:02:29.226649 00:25:90:93:40:79 > 40:61:86:32:8f:0e, ethertype IPv4 (0x0800), length 98: 10.0.4.3 > 10.0.1.3: ICMP echo reply, id 8079, seq 3, length 6416:02:30.228059 40:61:86:32:8f:0e > 00:25:90:93:40:79, ethertype IPv4 (0x0800), length 98: 10.0.1.3 > 10.0.4.3: ICMP echo request, id 8079, seq 4, length 64

From the captured packets, we can easily see that when machine 1 is pinged to Machine 7, because the route table is configured with the eth1 (10.0.1.2) Address of machine 4, the mac host ① corresponding to this address has been cached, and all ICMP packets are sent directly without arp broadcast, and the destination ip address is host 7th, the destination MAC is eth1 of machine ④, and then the destination MAC is changed to eth4 of machine ④ in the route of machine ④. The destination ip address remains unchanged, and the return process is similar.

 

　4. Conclusion

Because the linux Router does not forward arp packets by default, all route configurations are as follows, machine ① has been in the stage of querying the target MAC and cannot forward data packets to machine ④, we can configure the route through "correct configuration" so that machine ① can use the MAC address of machine ④ eth1 and then forward it step by step. You can also configure the route using "Incorrect configuration", and then use the arp proxy in host ④, so that host ① can obtain the MAC address of host 7, from arp packet sending to ICMP packet sending.

　　

 

Ping failure after route forwarding in linux

Are all gateways configured?

Server should also change the gateway, pointing to 202.100.100.2

Does Linux itself support wireless routing?

Jingyan.baidu.com/...9.html
I found this in Baidu experience just now and it should be able to meet your needs. WiFi hotspot in Linux
Li Wenqiang [authoritative expert]