Contents
Preface
I officially started playing with the router, which should be Netgear's R7000:
But it seemed that it was still the era of ADSL 8M, and the upstream was only 512K, so I didn't bother much at first, and just used the official firmware. And I remember that the blockade at that time was far less than it is now, and the impact was not that big, so I didn't think of spending time tossing.
After a few years, the blockade became more and more strict, which had affected my daily work (technical engineers in foreign companies needed to visit foreign websites too often). I had to consider scientific issues, so I flashed the R7000 with the Merlin system and installed shadowsocks using the software center and continued to use it (to be honest, the performance of the R7000 is still good, but the wifi is a bit weak).
The bloody incident caused by multiple rounds of calls-begins to toss
I don't know when I saw an article about multiple dialing. Wow, it's actually possible to do this. I saw that Merlin also supports dual-line single dialing, so I tried it immediately. Luckily, I found that my home telecom broadband really works. . However, Merlin's dual-line dual-dialing function is too simple. It can only be used as the primary or the backup, or both can be used for load balancing. The playability is too poor (after all, I am also a professional seller of link load balancing equipment, so it's reasonable to have a high requirement~~), so I considered other solutions that support multiple dialing, and then I saw lede and iQuick.
lede (a branch of openwrt) is also OK, but firstly, I am not used to the configuration logic of lede, such as the concepts of iptables such as input chain, output chain, and forward chain (compared with the habits I developed after configuring a large number of cisoc, Huawei three-layer switches, routers, and various types of firewalls). I can't react immediately and need to translate it with my brain, which is very awkward for someone like me who relies on instinct to troubleshoot configuration. Secondly, after trying iQuick, I found that in addition to the perfect support for multi-dial, iQuick's various other functions are also closely integrated with the multi-dial function (see my other article:iKuai Soft Router Series The most powerful multi-dial soft router: iKuai), and it is also in line with the configuration habits of Chinese people, so I finally chose Aikuai as the main router and R7000 as the secondary router, so the first change of the network structure became as follows:
In this structure, I directly point the default gateway of all devices to the LAN port address of R7000, and the WAN port of R7000 adopts static IP mode, directly points the default route to the LAN port address of iQIYI, and here you can turn off the NAT function of R7000:
This is because they are all connected in the network, just used as a three-layer switch, and NAT is not needed at all. In addition, another advantage of turning off NAT is that when AiKuai does port mapping, it can directly point to the real intranet address of the host in the intranet 192.168.1.x network segment (of course, the return route of the 192.168.1.x network segment must be written on AiKuai and point to the wan port address of Merlin), otherwise it will need to be mapped twice on R7000. Two NATs from inside to outside, and two mappings from outside to inside are redundant and have no benefit, so just turn off NAT.
Maybe you may have a question here: Why doesn't R7000 use bypass mode? In fact, from a professional perspective, there is no such concept as bypass. The correct term should be supporting single IP promiscuous mode packet reception, forwarding and NAT at the same time.
Generally speaking, the network card of a normal host device will only receive packets whose destination address is the network card's own IP when in normal mode. Other packets will be discarded directly. If you want to receive packets whose destination IP is not your own, you need to set the network card to promiscuous mode (I remember that there was a prompt when installing Wireshark on Windows before).
In order to realize the bypass routing function, the device must support at least two functions:
1. The network card must support promiscuous mode or be able to be set to promiscuous mode
At this point, the LAN ports of all routers are open by default, and devices such as Linux can be opened using commands, for example:
ip link set eth0 prompt on2. Support single IP forwarding and NAT at the same time
Home-grade broadband routers are not capable of this, because they can generally only receive packets from the LAN port and send them out from the WAN port while performing NAT with the WAN port address (the better systems also have a switch to determine whether to perform NAT, but generally even NAT is hard-coded and cannot be turned off).
This is not a problem for Linux at all. You should know that the forward chain of iptables is used to do this. If there are two network cards with two IP addresses in different network segments on Linux and forwarding is turned on, it will directly become a three-layer switch (of course, the switching performance is another matter). If there is only one network card, turning on forwarding and IP masquerading (that is, NAT) will directly turn it into the so-called one-arm bypass router.
First optimization
This structure has been used for several years, and there is actually no problem. However, I often mess with R7000: Merlin refreshes the firmware, shadowsocks upgrades, and restarts the R7000 when something goes wrong. The network is interrupted when restarting, which is very annoying. In addition, I still want the main router and all clients to be in the same network segment to facilitate operations such as network wake-up. So I thought about it and planned to change the network structure. In addition, R7000 was already an old model at that time, and Merlin firmware and scientific plug-in support were not very good, so I ruthlessly changed to ASUS AC66uB1:
Then after changing the network structure for the second time, it becomes like this:
The advantage of this structure is that the default gateway of all users on the main router can be pointed to the LAN port address of iKuai. As for those users who need scientific configuration, they only need to configure port diversion or domain name diversion on iKuai:
Just point the corresponding user source IP address or specific domain name to the wan3 port of iKuai. At the same time, even if AC66uB1 crashes or has problems, it will not affect the normal network access of all clients (similarly, you can also turn off NAT on the wan3 port on iKuai, but you need to add a return route to the intranet on AC66uB1).
However, this structure also has disadvantages, that is, one dial-up is placed on AC66uB1, which is not as convenient for operation and maintenance and traffic load as when three dial-ups are all on iQuick, and if you want to map ports from wan3 port, you must configure it on AC66uB1, which is not very convenient. But in general, the advantages outweigh the disadvantages.
Second optimization
After a few years, I felt that the connection method shown in the figure above was awkward and my obsessive-compulsive disorder was very uncomfortable. I wanted to continue to optimize it, so I upgraded the router to the current AC86u:
Then after the third network structure adjustment, it becomes as follows:
The advantage of this structure is that all dial-ups are unified back to iQuick, and the uplinks of the three links can be easily used. At the same time, the client still only needs to point the default gateway to iQuick, and iQuick will still send the required client traffic from wan3 port to AC86u's lan port based on the source IP or target domain name (NAT needs to be enabled, iQuick defaults that all data sent from the wan port is NAT enabled), and AC86u's wan port is connected back to the intranet (NAT must also be enabled). This deployment method still retains the advantage that AC86u crashes or interrupts will not affect the normal Internet access of all clients. This is the best topology for dual hardware routing.
In addition: Since the wan1 port has 3 single-line dials, there is also a wan2 port that can be used to connect to IPTV, so the IPTV function was simply moved from Merlin to iKuai. This relieved my obsessive-compulsive disorder. The key is to further simplify the functions on Merlin and make it more replaceable. For more information about configuring IPTV on iKuai, please refer to the article:iQiyi Router Series realizes all-media playback of Telecom IPTV.
Final Optimization
However, I still feel a little uncomfortable with this structure: first, the high price of the ASUS router is largely due to the router's WiFi, but I use Netgear's mesh WiFi, so the ASUS router's WiFi is completely wasted; second, the large amount of normal Internet traffic does not pass through AC86u, and the main function of the router is science, so the performance requirements are not that high. In this case, it is completely sufficient to run a virtualization device at will. For the sake of science, it is not cost-effective to open an extra hardware 365 days a year in terms of electricity bills; third, if it breaks, do I have to buy another one? I used it before for historical reasons, which is understandable, but it would be too low to buy it again, so I started to toss openwrt (see my previous two articles:OpenWrt soft router series PVE deployment OpenWrt (23.05.2) detailed tutorialandOpenWrt soft router series must-install software 3 swordsmen: openclash+sftpserver+tailscale installation tutorial).
Then there is the final solution:
In fact, it is to use a virtual machine on PVE to run openwrt, replacing AC86u. Of course, relevant configuration needs to be performed on openwrt first. There are several key points:
1. Openwrt hardware requires dual network cards (only one by default, you need to add one):
2. Correctly configure the interface on openwrt
3. Configure firewall zones correctly
The LAN area and WAN area here are a little different from the usual ones, because usually the traffic only enters from the LAN port, exits from the WAN port and performs NAT, but in my structure, both LAN and WAN have traffic entering, the only difference is that the LAN port is dedicated to Aikua, and the WAN port is for intranet users (not used to configure the default gateway, but for intranet users to access the socks5 and http proxy that comes with openclash).
For iptables, it only looks at the configuration of the input chain, output chain, and forward chain corresponding to the network card area. In my structure, the firewall area settings are as follows:
Two ways to set the default gateway on the user side
1. The user's default gateway points to the LAN port IP of openwrt (not recommended)
For intranet users, if the default gateway is directly pointed to the wan port IP of openwrt, all traffic outside the network segment will directly reach openwrt (including traffic that needs to be processed scientifically). Openwrt will directly process the traffic that needs to be processed scientifically according to the existing strategy. The traffic that does not need to be processed scientifically will be directly sent to the lan port of iQiyi after NAT by openwrt for normal Internet traffic processing. This is usually called the one-arm bypass routing mode. This deployment method is simple and crude, with few advantages and a lot of disadvantages: once openwrt crashes, all clients pointed to by the gateway will not be able to access the Internet; part of openwrt's performance is used for forwarding and NATing traffic that does not need to be processed scientifically, while traffic that needs to be processed scientifically consumes very little performance; if the main router iQiyi has port mapping to the client, and the default gateway of the client points to openwrt, it may cause openwrt to send ICMP redirects to the client, etc.
2. The user's default gateway points to the LAN port IP of iQIYI (strongly recommended)
The default gateway of intranet users points to the LAN port address of AiKuai. AiKuai can then send the user requests that need science to the LAN port of OpenWRT through the WAN3 port according to the diversion strategy, and then OpenWRT will handle the science traffic according to the existing strategy. Although there is an additional diversion operation of AiKuai, it brings great benefits such as the client does not need to change the gateway, science equipment failure does not affect normal Internet access, and it is convenient to install the new Linux system in one step (imagine a newly installed Linux system where apt cannot download the software; you need to modify the configuration file to change the IP but there is no vim, and using vi makes you want to vomit; you want to access through SSH but cannot download the OpenSsh server, etc. With the intervention of AiKuai, you only need to throw the new system IP into OpenWRT in the diversion settings and the problem will be solved). Any normal person knows to choose the latter.
When I want to switch from AC86u to OpenWRT, I don't need to change any configuration. I just need to unplug the network cable that is directly connected to the AC86u LAN port from the AiKuai WAN 3 port and connect it to the LAN switch (the premise is that the IP address of the OpenWRT LAN port is the same as the LAN port address of the AC86u).
In addition: In fact, you don't have to use AiKuai as the main router. Any router that supports multiple WAN ports and policy routing, such as source IP address-based routing and domain name-based routing, will do. But I haven't seen any router that can compare with AiKuai in terms of traffic diversion and routing. AiKuai is too strong in this area.
Summarize
In fact, the most important thing about the final deployment plan is the idea. It does not necessarily require hardware or virtual machines (for example, you can use a virtual machine to install OpenWRT in iKuai, which is deployed independently with hardware; or you can install iKuai and OpenWRT at the same time on ESXi; or you can use iKuai as hardware and OpenWRT as a virtual machine like me, etc.). The most important thing is the connection logic between iKuai and OpenWRT (it can be a physical connection or a virtual connection through a vswitch). You can flexibly choose a solution that suits you according to your actual environment.
Hello, I deployed it according to your solution, and there is no problem with normal Internet access, but I also want to install TailScale on OpenWRT. After installation, I found that the node cannot connect to other devices in the intranet.
I just installed tailscale on openwrt, and it works fine. "The node cannot connect to other devices in the intranet", I don't understand what it means. Does this "cannot connect" mean that openwrt cannot actively ping other devices in the LAN, or does it mean that other devices in the LAN cannot ping openwrt? The node with tailscale installed can use the command "tailscale" in the terminal to set some functions, such as whether to allow LAN connection. You can take a look.
My devices are all connected to the TailScale network, the network segment is 100.64.1.0/24. In theory, after OpenWRT joins TailScale, –accept-routes=true –advertise-routes 192.168.100.0/24, with these two parameters, devices that access the Internet through OpenWRT can also join the TailScale network. But my other devices can only access 100.64.1.10 (openwrt), and cannot access 192.168.100.0/24. The LAN segment of ikuai is 192.168.1.1/24, the LAN port of openwrt is 192.168.100.0/24, and the LAN port of pve is 192.168.100.10. ikuai cannot even ping 100.64.1.1 (headscale and derp server). Pve and other devices can ping 100.64.1.1, but 100.64.1.1 cannot ping 192.168.100.1, 192.168.100.10
You don't have a topology diagram, and it's hard to associate just the IP address segment, but I guess you mean that other devices deployed with tailscale cannot access the 192.168.100.0/24 network segment where the LAN port of openwrt is located? I haven't actually done this kind of routing of network segments by tailscale, because the devices that need to visit each other are all installed with tailscale, so there is no such requirement. However, I think a key point should be whether other devices deployed with tailscale can see the route to the 192.168.100.0/24 network segment, and the gateway should point to 100.64.1.10 (openwrt). In theory, if you set it up properly and advertise-routes is also set correctly, other devices deployed with tailscale should be able to see it, which is the basis for communicating with the 192.168.100.10/24 network segment. In addition: Is –accept-routes=true set on other tailscale devices?
When I deployed it before, I just added –accept-routes on openwrt. Do other tailscale devices also need to enable this parameter? I will try it later.
“–accept-routes”, I think this switch should control whether to accept the routes announced by other tailscale nodes.
Hi, I have another problem... My current ipv6 is very strange. It is normal in the LAN and can be pinged on the Internet, but I cannot access the port service through ipv6. It seems to be a firewall problem, but I turned off the firewall of openwrt and turned on ikuai. I didn't see the firewall settings on the optical modem, but it still didn't work.
When encountering this kind of problem, you need to capture packets on iKuai to confirm whether the ping packets from the external network have reached the WAN port of iKuai. If it has reached the WAN port but cannot be received, it can be confirmed that there is a problem with the IPv6 firewall.
I would like to ask, eth0 and eth1 are no longer in the new version of openwrt, there is only br-lan, Ethernet adapter port wan, and switch interface eth0, how should I set it up? It is the last solution. I guess your openwrt kernel version is below 5.5?
Just add a network card to the virtual machine, and then set it up in openwrt. By default, there is only one eth0, and the extra ones must be added by yourself. As for the switch, you don't need to configure anything. You can run multiple network segments in one broadcast domain, but it is generally not recommended to do so. Broadcast packets in the production environment will affect each other, but you don't have to worry about it for the network you control.
Thank you blogger for giving me a good idea to solve the problem of unified configuration of single-arm routing.
Then here is a small suggestion: you can install openwrt into the iKuai virtual machine, and then cooperate with the next-hop strategy of iKuai port diversion to achieve a more natural collaboration.
2 benefits:
I also installed virtual machines on Aikuai before, but later I bought a mini host with inter cpu to install pve, and all the virtual machines and docker were migrated to it, which makes it easier to operate and manage.
I now only use Aikuai as an export device (it is an industrial computer purchased separately, not in NAS). Firstly, I was annoyed by the noise of the CPU fan of Aikuai when running virtual machines before, and secondly, because Aikuai has 3 links, each link has its own function, which is much more important than openwrt. If we really install them together, I am worried that openwrt will affect my Aikuai. Besides, openwrt is just my backup device. I mainly use AC86u now. I installed openwrt because science was unstable for a while, and I couldn't be sure whether it was a problem with ac86u or science itself, so I installed openwrt as a backup test method.
I just want to ask, if I add a port diversion strategy, if openwrt crashes, will it affect the normal use of the diverted device?
It depends on whether you check the "line binding" option. However, I feel that the judgment logic of this option may be rough. It may rely on whether the superior gateway is reachable or whether the line interface is up or down (after all, there is no specific option, I can only rely on conventional logic to judge). According to different judgment logics and how your openwrt hangs (for example, it hangs completely, and pinging the interface address cannot be pinged, or it hangs half-dead, for example, pinging the interface can be pinged, but in fact it is no longer working), the final actual effect may not be what you want, so this is one of the reasons why I separate AiKuai and openwrt. Regardless of whether openwrt lives or dies, the main AiKuai router cannot be affected in any way. After all, in my "home data center" plan, the stable and normal operation of AiKuai is the top priority.