Solution for setting the second IP address in the same network segment as the physical network card for the TAP-Win32

TAP-Win32 nic and physical nic with the same network segment of the second IP Solution 1. first, configure a second IP address in the same network segment as the physical network card on the TAP-Win32 Nic my physical network card address is 192.168.40.34/24, so I configure a 192.168.40.35/24 for the TAP-Win32 Nic, another address on the TAP-Win32 Nic is the 172.16.0.30/16 pushed by the OpenVPN server, so there are two IP addresses on the TAP-Win32 Nic. Note that the second IP address of the same network segment can be selected at will, will not conflict, because as long as not from the TAP-Win32 Nic packet, there will be no arp to the IP address, on the contrary, to send packets from a TAP-Win32 Nic, the following procedure ensures that the IP address is only the source IP address of the packet. It serves only this purpose. 2. on the TAP-Win32 Nic, the arp ing of the original default gateway is used to obtain a MAC address, which is used to encapsulate the target MAC address of the Ethernet frame, the mission of the gateway is complete. A good place for Windows is to specify the network card on which the arp ing can be established. Although there was originally an arp ing to the default gateway 192.168.40.254, the arp ing was created on the physical network card, now I create an arp ing to 192.168.40.254 ON THE TAP-Win32 Nic, but the mapped MAC address is not the MAC address of the true 40.254, but the MAC address of the OpenVPN server tap0 NIC: arp-s 192.168.40.254 00-ff-c4-d3-2e-da 172.16.0.30 note that the last parameter of the preceding command is the IP address pushed down by the OpenVPN server of the TAP-Win32 Nic. With it, the ing is established on the TAP-Win32 Nic. 3. change all the gateways of the routes pushed by the OpenVPN server to 192.168.40.254 in the Fake of the TAP-Win32 NIC: route add. b. c. d mask A. B .C.D 192.168.40.254 IF 0x3 note that the last parameter 0x3 of the preceding command is the Index ID of the TAP-Win32 Nic, it indicates that the IP address related to this route is the IP address configured in the same network segment as the physical network card of the TAP-Win32 network card. 4. test whether the capture reaches a on the tap0 of the OpenVPN server. b. c. d package, found that the source IP address is 192.168.40.35, that is, the TAP-Win32 network card and the physical network segment with the second IP address segment, not the virtual IP address pushed by the OpenVPN server 172.16.0.30 disadvantages: although the results have been achieved, but have to occupy two IP addresses in the same network segment, even if there is no conflict, it will be uncomfortable, because at the end of the VPN, if the source IP address audit, management will be very troublesome, you have to set your master IPaddress on the TAP-Win32 Nic, and the physical Nic to set a random non-conflict IP address, finding this IP address is a difficult task. So, the next idea came out, can you set a TAP-Win32 NIC with the same IP address as the physical Nic? The physical nic and TAP-Win32 Nic share the physical IP scheme This section will be relatively short, because this scheme failed, the only content may be complained. It is a good thing to have an idea, but the process of implementing the idea is often painful, because there are always a lot of obstacles you can't think of, especially if you are tossing the network on WIndows, it is even more so! When I configure the second IP address on the TAP-Win32 Nic, that is, the IP address 192.168.40.34 of my physical Nic, a warning is displayed: --------------------------- Microsoft TCP/IP ----------------------------- the IP address 192.168.40.34 entered for this Nic has been assigned to another MAC bridge micro port on this computer. If the same address is assigned to two NICs and both NICs are in use, only one of them will use this address. This may cause incorrect system configuration. Do you want to enter a different IP address for the NIC from the IP address list in the "advanced" dialog box? --------------------------- Yes (Y) No (N) ----------------------------- I know this is a wrong configuration, because it will conflict, I know more than anyone else, but I did it on purpose, because I have a solution to the conflict, I chose "no". After confirmation, the pop-up will pop up: ----------------------------- Microsoft TCP/IP --------------------- the static IP address just configured is already used on the network. Please reconfigure a different IP address. --------------------------- OK --------------------------- after confirmation, I found that this IP address has been added to the TAP-Win32 Nic, but does not take effect, Windows does not give me the opportunity to make mistakes... let's look at the situation on Linux: root @ Debian60b1-AMD64-DEV :~ # Ifconfig eth0 1.1.1.1/24; echo $? 0root @ Debian60b1-AMD64-DEV :~ # Ifconfig eth1 1.1.1.1/24; echo $? 0... speechless! The reason why Windows does not give you the opportunity to make mistakes is because the designer does not have the ability to solve the errors by default, so it prevents you from making mistakes. The UNIX-series system opens huge permissions to the root user, because designers think that if you make a mistake, you must have a reason to do so! Mac OS is between the two. For UNIX users, it provides a powerful BSD command line. For common users, it has a brilliant UI, Which is stricter than Windows, the "add a second IP Address" option is disabled and exposed to the user. Since I don't want to configure the UI, I think there must be a way to force the underlying API to take effect, so I opened VS2005 (old version !), MSDN examples of various attempts, familiar with Win32 API colleagues' various questions, fruitless! Forget it. Why not let me succeed? So the third idea was born. Since I was not allowed to configure the same IP address for the two NICs, I can merge the two NICs into a logical Nic, so I can search for various solutions on the Internet, various bonding is not supported. You need to download third-party software... windows comes with one: MAC bridge micro port! That's it. Physical network card and TAP-Win32 network card bridging solution is the result of gradual thinking, so the process also contains a lot of complaints about Windows network. 1. Successful connection to the OpenVPN server in order to ensure that the tunnel is disconnected during the bridging process, the keepalive time should be set long enough. I gave the bridging a minute. 2. Bridge TAP-Win32 nic and physical Nic press Ctrl, left click TAP-Win32 nic and physical nic "Local Connection"; right click bridge ". A bridge is generated. 3. configure the IP address of the bridge as quickly as possible. You can configure the IP address before keepalive expires, which is actually simple, that is, add the IP address of the original "Local Connection" and the IP address pushed by the OpenVPN server to the bridge. Note that the default gateway and DNS of "Local Connection" must also be added to the bridge. The next thing is enough for me to drink! 4. After the painful process of address configuration, the problem arises again. How can we establish arp ing now? You can no longer use the original physical network interface of the default gateway, because at this time the TAP-Win32 network interface and the physical network interface bridge into A, no longer separated, once the stolen re-defines the original default gateway arp ing, this will cause all local applications to be disconnected from the network. Obviously, it is difficult to select an IP address in this segment that nobody uses. 4. 1. select the IP address to establish arp ing is in fact to select a gateway to import traffic to the TAP-Win32 Nic, the role of this address is to establish an arp ing, and then let the packet sent through the bridge, the physical IP address is selected as the source address. Why can I find someone in this section that is useless? What should I do if it comes to management problems? I have a solution at this time, which means that the IP address mask on the original physical network card set on the bridge is one bit backward, that is, the IP address mask is reduced by one bit, in this way, can the original broadcast address and network address of the network segment be used? The following is the calculation process: IP Address: addr; original subnet mask: prefix (the form of. set the New subnet mask to a prefix-1b. if the addr prefix is 0, the requested gateway address is the broadcast address of the original network segment (because the new broadcast address requires that its prefix is 1) c. if the addr prefix is 1, the requested gateway address is the network address of the original network segment (because the new network address requires that its prefix is 0) d. if the addr prefix is 0, you can also set the addr prefix to 1, and then use the address 0 after it is followed as the requested gateway address e. because the prefix is reduced by one bit, the cost is to add a route pointing to the original default gateway. What about the original predfix routing result with different prefix bits from that of addr? Windows again! My explicit mask is 255.255.254.0, but there will still be: 192.168.40.255 255.255.255.255 192.168.40.34 192.168.40.34 20 when I set the prefix to 23, it should be: 192.168.41.255 255.255.255.255 192.168.40.34 192.168.40.34 20! However, I don't know what kind of medicine Windows sells and thought it was a cache, but I still cannot use the gateway selected by the above algorithm if I disable/enable the NIC. Some people may have similar questions on the Internet. Since the problem cannot be solved, I will not pursue it. Even if a small problem occurs on Windows, it will take several days to catch up, because it is difficult for you to debug it, it's hard to see exactly what it is! It is always good to bypass it. 4. 2. routing is used to solve the problem. I suspect that WIndows IP addresses are mixed with classless and classless IP addresses, but I cannot find any configuration methods to change this behavior. The Registry may have one, but I am afraid. As a result, I simply changed the prefix to 16 bits, so there is one of the following items in the route table: # Link route 192.168.0.0 255.255.0.0 192.168.40.34 192.168.40.34 20 that is to say, it regards all 192.168.0.0/16 as link direct connection routes. In fact, only 192.168.40.0/24 is used, therefore, you need to direct all non-40 network segments to the original default gateway. God, it's hard for Windows to implement Policy Routing. Anti-mask is not supported. How many routes are added in this way !! Therefore, I can only use Metric to overwrite the preceding routes, that is, add two routes: # add a real link direct connection route add 192.168.40.0 mask route 255.255.0 192.168.40.34 # overwrite the fake link direct connection route add 192.168.0.0 mask route 255.0.0 192.168.40.254 metric 1 so that it is OK, to prevent automatically generated Metric from being smaller than yours, it is best to turn off the "Automatic hop count" in the bridge card's TCP/IP advanced attribute and then manually add a relatively large value. As for which to choose the gateway to do the TAP-Win32, in 192.168.0.0/16 randomly find a can, I still find the original network address, that is, 192.168.40.0. Then add an arp ing. The arp-s 192.168.40.0 00-ff-c4-d3-2e-daMAC address is the MAC address of tap0 on the OpenVPN server. Test, send the packet, through the virtual network card, in the receiving end, the source IP address is 192.168.40.34, rather than the address of 172.16.0.30 VPN virtual network segment. 4. 3. the leakage of encrypted traffic is caused by the use of bridges, which broadcast packets on all interfaces by default when MAC is not cached, therefore, some data packets are sent to the physical network card and TAP-Win32 virtual network card at the same time, resulting in the traffic that should be encrypted to the physical network card, but because the encapsulated target MAC address is the tap0 mac of the OpenVPN server, therefore, this section may only leak information and will not pass through the original default gateway. In fact, it is easy to solve this problem. You only need to set a never-Expire MAC/port ing or configure a firewall. However, this is not my strength, I don't want to worry about Windows anymore! In addition, this problem can be solved through the OpenVPN server. During the initial holdon time of Windows client access, packets are continuously sent to the corresponding client through tap0, in this way, the bridge interface on Windows records the MAC/port ing, which is equivalent to learning the MAC address. However, if the Windows bridge is not a learning type, it will be sad. 5. Sadly, it seems that Windows bridges can only be manually configured! How can this be combined with the plug-in of OpenVPN? I originally wanted to write a script to create a bridge, configure IP addresses, set routes, and add arp ing in the up script of the Windows client, however, the Windows Script Function is too weak, so you are ready to write plugin and directly call the Windows API. However, if you can only do this manually, it will be a tragedy, maybe the mouse Genie and other things will come in handy... how can I narrow down the 1-bit prefix with conditions? Back again? Didn't the previous scheme say that the one-digit reduction scheme is not feasible? Yes, the last solution was not feasible, but the process of solving the problem was a process of constant thinking. Now it is actually feasible. Although such feasibility is conditional, fortunately, we have a probability of 50%. We can meet this condition! The IP address and route query in Windows are both Classful and not VLSM. Therefore, the prefix is obviously reduced by one bit in the previous solution, but its broadcast address is still 192.168.40.255, this is a class C address. However, even the Classful address still has a clear network ID, that is, 192.168.40.0 255.255.254.0 192.168.40.34 192.168.40.34 20, which is noticed in the Next Hop algorithm: d. if the prefix of addr is 0, you can also set the prefix of addr to 1, and then use the address of all 0 as the requested gateway address, which is exactly for 192.168.40.34, its prefix is 0, so the address obtained by the above algorithm is 192.168.41.0. It obviously does not belong to the IP segment on the original physical network card, however, it belongs to the IP address segment after the first digit of the prefix. It can be used as the next hop: route add. b. c. d mask A. B .C.D 192.168.41.0arp-s 192.168.41.0 00-ff-c4-d3-2e-da # compensate for the cost of one digit after prefix: route add 192.168.41.0 mask 255.255.255.0 192.168.40.254 ends. You do not need to set any more Metric routing or distinguish between real and false link direct connection routes. The process of thinking is actually an original process. Even if you use a lot of "Giant" materials, no one thinks like you. 1. when I knew the logic of selecting the source IP address for Windows, I decided to add an IP address with the same network segment as the physical Nic on the TAP-Win32 Nic, and then how to select it; 2. although I want to configure it as the primary IP address instead of the secondary IP address to give it a higher priority, what is the next hop address in the end? 3. I know that the only important role of the next hop is to obtain a MAC address encapsulated as the target MAC address. Therefore, what is it? 4. so I disguised an IP address in the same network segment as the IP address of the physical Nic as the next hop, and then added a static arp ing to the MAC address of the tap0 Nic on the OpenVPN server; 5. the idea has basically ended. The subsequent implementation process has always been the above idea, but why did it finally get to the bridge? Although the basic idea remains unchanged, the implementation process is actually a process of continuous trial and error and turning forward. If it is wrong, it is necessary to fine-tune it to the end, in fact, it is successful; 6. the first obstacle is to find that two IP addresses in the same network segment are not good. I just want to use one IP address. For this optimization, I will be gradually brought into the bridge. In fact, before that, there were some small obstacles, such as how to add arp ing to the NIC and how to specify the NIC When configuring the route. 7. after arriving at the bridge, selecting the next hop through the TAP-Win32 NIC data packet becomes a problem, in order to least conflict and least puzzling, I decided to use the original physical Nic's full 1 broadcast address or all 0 network address, then we decided to narrow down the prefix by 1 and calculate the next hop according to the standard algorithm. 8. I encountered a strange problem in the Windows route table, such as class‑free obfuscation and broadcast route calculation errors. I am not a bug reporter, so I can bypass it. What do you like? Then, the prefix is rolled back to 8 bits. Now it is aligned with the, 24 bits you requested. 9. the prefix reverts 8 bits, which is equivalent to a large summary. The link direct connection route overwrites the network that is not directly connected to the CIDR block. Therefore, you need to open these routes, but you cannot crash. What should we do? 10. according to the longest mask match, first add a 24-bit mask link direct connection route, which is a real link direct connection route; 11. overwrite the original 16-bit masked fake link direct connection route with a route pointing to the original default gateway 192.168.40.254, but the fake direct connection route cannot be deleted. What should I do? 12. If you like to keep it, I will overwrite you with a smaller Metric route! 13. Use the original network segment's network address 192.168.40.0 as the next hop through the TAP-Win32 Nic packet, and then add an arp ing to the next hop to the OpenVPN server tap0 Nic MAC address. 14. Write down this article and forget it! The problems left behind are basically solved, and the only thing left is how to combine with OpenVPN, that is, how to write the above a lot of manual operations into plugin (I have completely abandoned the script), and then it is the initialization of the TAP-Win32 problem, if it is not disconnected from the bridge, can it still be initialized? Even if it is not difficult, modify the OpenVPN Windows client code, that is, the ifdef WIN32 paragraphs.