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

At home, company seats, company meeting room, company corner, customer site, hotel... 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!

Sggw module DIY Solution

Openvpn and other IP-layer VPN full link layer processing implementation describes a method for automatically returning packets to the initiator, 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. Install the preceding vroSggw 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 a direct IP address, that is, whether it is in a network segment with its LAN Nic;
3. If not, directly reply to the MAC address of your LAN port. If not, skip;
4. (In this step, I started to add and delete the route.) Add a force-onlink route based on the initiator's IP address, that is, the gateway address;
5. return;
6. Follow the standard arp_process Process
I removed Step 1 because it is inconvenient to add routes to the kernel to delete routes. It is too easy for TM to panic! It is better to pass the event to the user State through Netlink!

Other solutions

In fact, 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.
How to modify the kernel code:
We know that there is a force-onlink route that can be configured even if the next hop is not a direct connection CIDR block. Therefore, it is logically connected to three layers without direct connection and physically, 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 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 routes. For example:
IP Route add autolink via link Dev LAN onlink;
Note: The autolink and link mentioned above require new support, that is to say, when looking for a route for incoming packets from the WAN, check whether the LAN is bound to an autolink route. If yes, the next hop is directly set to the target address.
Solutions based on existing tools:
As long as the laptop wants to send a packet, ARP proxy will inevitably bring it to the router. The router's ip_conntrack will record the packet's source IP address, which can be monitored through the following command line:
Conntrack-e new;
Now that the IP address is monitored, you can set a route for it. For example, if the source IP address is a, run the following command:
IP Route Add a/32 via a Dev LAN onlink;
The use of the conntrack tool may cause unpredictable errors due to latency, so we 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, like the conntrack event monitoring, you only need to perform the new packet 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.
General Solution:
Lagging behind will bring about DIY, and so on will be able to run smoothly, so no one will do it. Most people will use what they get, instead of making a hard move. If spending money can make it easy, 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.