A set of network configurations to access the Internet anytime, anywhere

A set of network configurations can be used to access the internet at home anytime, anywhere, including company seats, company meeting rooms, company corners, customer sites, hotels... you have to configure your network card to ensure that it is consistent with the configuration of the location. This is too annoying! Is there a way to avoid this tedious configuration? In this backward and self-sufficient DIY age, the answer is no doubt certain for the tillers in the male and female workshops! The sggw module DIY solution OpenVPN and the implementation of complete link layer processing for other IP layer VPNs introduces a method for automatically returning packets to the initiators, in fact, it is "from where the packet is automatically sent to the same place when it receives the response packet". This patch module, together with the ARP proxy, can instantly access the internet! That is to say, when DHCP is not enabled, you no longer need to configure an IP address in another place. Although the Macbook can map the IP address to the "location" configuration, however, it is not very good to keep a "location" for some areas that are not often used. Note: what I am talking about here is the implementation of the router, not the implementation of the notebook. How can this problem be solved? 1. the router started the ARP proxy (I tried it at home over the weekend and started to fail the proxy. I didn't find any reason, so I made some effort on the arp_process function to simplify the process ). 2. the router installs the sggw module. 3. The vro performs MASQUERADE address translation on the WAN port. Assume that the LAN port of the vro is 1.1.1.1/24, the WAN port is 2.2.2.2/24, and the laptop IP address connected to the LAN port of the vro is 192.168.1.34/24. The default gateway is 192.168.1.254, it wants to access the WAN. For example, if the IP address is 128.129.1.1, it is addressing the default gateway. Because the router has an ARP proxy, it replies to the ARP request and sends the packet to the router, at this time, the sggw module records the connection. When the reply packet arrives at the router, The sggw module sends it to the notebook! That is to say, even if the LAN of your laptop and router is not in the same network segment, you can access the Internet normally! If you deploy the above router wherever you go, you can keep only one "location". My Macbook is set as the "location" of the company. Based on the above implementation, I can access the internet at home using my company's location configuration! However, there is a problem. For example, what if the laptop IP address and the router LAN are in the same CIDR block due to coincidence? If the real gateway is not in the same CIDR block, or the real gateway is closer to the laptop, so that the router's ARP reply can overwrite the real ARP reply. In fact, this problem is a good solution and the solution is non-technical, set the LAN port address of the route to some strange addresses, such as 12.32.45.54! Note that it never exists as the target address, but is just a whistle! Finally, let's talk about what I have done to arp_process. In any case, when a laptop or PC initiates a network access request, it must send an ARP request. We know that it is broadcast, and it will certainly arrive at the router, you can get enough information from this ARP request, such as the IP address of the notebook and the MAC address. Since my BOX is only used for this purpose, my arp_process process becomes: 1. parse the ARP request packet to obtain the initiator IP address. 2. check whether the IP address is your direct IP address, that is, whether it is in a network segment with your LAN Nic; 3. if not, directly reply to the MAC address of your LAN port. If not, jump to; 4. (This step is after I add and delete it) Add a force-onlink route based on the initiator's IP address, that is, the gateway address; 5. return; 6. I have removed step 4th of the standard arp_process process because it is inconvenient to add routes to and delete routes in the kernel. It is too easy to use panic! It is better to pass the event to the user State through netlink! Other solutions actually want to achieve this. There are two other DIY solutions and a conventional but not commonly used solution. One of the DIY solutions is the ROUTE module that modifies the kernel protocol stack, the other is event monitoring based on the conntrack tool. Let's talk one by one. Kernel code modification solution: we know that there is a force-onlink route that can be set even if the next hop is not a direct connection segment, so it is logically not directly connected on the Layer 3, physical connections are directly connected. If no device enables ARP proxy, ARP can only be transmitted in the physical direct connection segment, the so-called force-onlink route directly sends ARP requests for the next hop! The solution is to set a force-onlink route for each connected notebook or PC. For example, if the IP address of the notebook is 4.4.4.4/24, set the following one: ip route add 4.4.4.4/32 via 4.4.4.4.4 dev LAN onlink; however, the router does not know how many machines need to be connected in advance, but does not know what their IP addresses are, therefore, you must use the wildcard method to set the preceding route, for example, ip route add autolink via link dev LAN onlink. Note that the autolink and link mentioned above need to be supported, that is to say, when you look up a route for incoming packets from the WAN, check whether the LAN is bound with an autolink route. If so, the next hop is directly set to the target address. Solution based on existing tools: as long as the laptop wants to send a packet, ARP proxy will make it come to the router. The router's ip_conntrack will record the packet's source IP address, this can be monitored through the following command line: conntrack-E-e NEW; since it is monitored, you can set A route for it, for example, monitoring that the source IP address is, execute the following command: ip route add A/32 via A dev LAN onlink; Use the conntrack tool may cause unpredictable errors due to latency, so you can use A better solution, that is, NFQUEUE target. Because QUEUEU is synchronous, you can control that the data packet INJECT from the QUEUE is not returned before the force-onlink route is added. Note that it is the same as the conntrack event monitoring, you only need to perform the NEW package QUEUE. Since it is a dynamic addition, it involves the problem of dynamic deletion. You can use the least frequently used algorithm recently and add the GC mechanism. Conventional solution: lagging behind will bring about DIY, and so on, there will be no DIY, and most people will use what they get, rather than tossing. If spending money can bring simplicity, I will never DIY, a lot of supply items, you will not spend a lot of money, I know, limited LIFE, should be to toss about THE LIFE itself, THE so-called DEBUG THE LIFE, rather than get lost! IPv6 automatically configures terminals targeting leaf roles! However, for IPv4, its automatic configuration, although the RFC also has clear recommendations, such as Router Advertisement, Router Solicitation, Address XXX, and so on, is available, however, many mainstream system kernel protocol stacks are not implemented. Maybe DHCP can be used to control the allocation process and security policies more flexibly.