This article describes the detailed process of selecting the source IP address for windows. It is also described in Microsoft's document. In short, both the strong host mode and the weak host mode are automatically selected for you, and you cannot intervene through configuration.
This is the automatic selection problem that exposes the virtual subnet address of openvpn to the real subnet. If this problem is tolerated, You have to modify the firewall and other network devices behind the openvpn server, for example, if the IP address of the virtual subnet passes through, you have to modify the application's IP address audit policy. If this happens, the cost is that communication may become one-way initiated... not all.
It took a lot of time to solve this problem, but it was not thorough. Now, I want to solve it once and for all and conquer it completely. Fortunately, there is no urgent thing at present, and there is no company or home. It is a good opportunity to conquer it. So, the little father came and stayed for a night, half a day, with the result.
Solution for setting the second IP address in the same network segment as the physical network card for the TAP-Win32
1. First configure a second IP address on the TAP-Win32 NIC that is in the same network segment as the physical Nic
My physical NIC 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 openvpn server pushed down 172.16.0.30/16, in this way, 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. Stealing ARP ing from the original default gateway on the TAP-Win32 Nic
The function of the default gateway is to obtain a MAC address used to encapsulate the target MAC address of the ethereum. After obtaining the MAC address, the gateway's mission 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 above command is the IP address pushed down by the openvpn server of the TAP-Win32 Nic, with it, the ing will be built on the TAP-Win32 Nic.
3. change all the gateways of the routes pushed by the openvpn server to 192.168.40.254 from the fake of the TAP-Win32 NIC:
Route Add a. 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, indicating that the route-related IP address is the IP address configured in the same segment as the physical Nic on the TAP-Win32 Nic.
4. Test
Capture to 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?
Physical nic and TAP-Win32 Nic share physical IP Scheme
This section will be short, because the solution fails, and the only content may be complaints.
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 Nic 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 about it than anyone else, but I did it on purpose. Because I have a solution to the conflict, I chose "no ", after confirmation, it will pop up:
---------------------------
Microsoft TCP/IP
---------------------------
The configured static IP address is already in use 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 a chance to make mistakes... let's look at the situation on Linux:
Root @ Debian60b1-AMD64-DEV :~ # Ifconfig eth0 1.1.1.1/24; echo $?
0
Root @ 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.
Bridging between physical and TAP-Win32 NICs
This solution is the result of gradual thinking. Therefore, the solution also contains many complaints about Windows network.
1. The openvpn server is successfully connected.
To ensure that the tunnel is disconnected during the bridging process, set the keepalive time long enough. I gave the bridging a minute.
2. Bridging TAP-Win32 nic and physical Nic
Press Ctrl, left click TAP-Win32 network card and physical network card "Local Connection"; right click "bridge ". A bridge is generated.
3. Configure the IP address of the bridge
Hurry up and use the fastest speed to configure the IP address before keepalive expires. In fact, it is also 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. A painful journey
After the address is configured, 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
In fact, it is to select a gateway that will import traffic to the TAP-Win32 Nic, the role of this address is to establish an ARP ing, and then let the data packet sent through the bridge, will select the physical IP address 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 calculation process is as follows:
IP Address: ADDR; original subnet mask: prefix (in the prefix form of the mask)
A. Set the New subnet mask to prefix-1
B. If the ADDR prefix bit is 0, the requested gateway address is the broadcast address of the original network segment (because the new broadcast address requires its prefix bit to be 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 prefix of ADDR is 0, you can also set the prefix of ADDR to 1, and the address of all the following 0 as the requested gateway address.
E. Because the prefix is reduced by 1 bit, the cost is to add a route pointing to the original default gateway. This route overwrites the original predfix route with a different prefix from that of ADDR.
What are the results? Windows again! The mask I clearly use 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
Set the prefix to 23 as follows, which should be:
192.168.41.255 255.255.255.255 192.168.40.34 192.168.40.34 20
That's right! 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.
. Routing
I suspect that the IP address of Windows is a mix of classes and no classes, but I cannot find any configuration methods to change this behavior. The Registry may have, 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 Routing
192.168.0.0 255.255.0.0 192.168.40.34 192.168.40.34 20
In other words, it regards all 192.168.0.0/16 as the link direct connection route. In fact, only 192.168.40.0/24 is used. Therefore, it is necessary 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 real link direct connection routes
Route add 192.168.40.0 mask 255.255.255.0 192.168.40.34
# Overwrite the fake link direct connection route
Route add 192.168.0.0 mask 255.255.0.0 192.168.40.254 metric 1
In this way, OK. To prevent auto-generated metric from being smaller than yours, it is best to turn off the "auto hop count" in the bridge card's TCP/IP advanced attribute ", 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. Add an ARP ing:
ARP-s 192.168.40.0 00-ff-c4-d3-2e-da
The MAC 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. Leakage of encrypted traffic
Because the bridge is used, and the bridge is broadcast packet on all interfaces by default in MAC without cache, so there are some packets sent to the physical nic and TAP-Win32 virtual nic at the same time, the encrypted traffic is leaked to the physical Nic. However, because the encapsulated destination MAC address is the tap0 MAC address of the openvpn server, it may only leak in this segment, does not go 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. Sad results
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...
One-bit prefix reduction scheme with conditions
Why? 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 has a clear network ID, namely:
192.168.40.0 255.255.254.0 192.168.40.34 192.168.40.34 20
Note that in the next hop algorithm:
D. If the prefix of ADDR is 0, you can also set the prefix of ADDR to 1, and the address of all the following 0 as the requested gateway address.
For 192.168.40.34, its prefix is 0, so the address obtained based on the above algorithm is 192.168.41.0, which 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, which can be used as the next hop:
Route Add a. B. C. d mask a. B .c.d 192.168.41.0
ARP-s 192.168.41.0 00-ff-c4-d3-2e-da
# Compensate for the price of one digit after the prefix
Route add 192.168.41.0 mask 255.255.255.0 192.168.40.254
Now, you don't need to set any more metric routing or distinguish between real and false links for direct connection.
Thinking process
In fact, the process of thinking is an original process. Even if you use a lot of "Giant" materials, no one thinks the process is the same as that of 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, so it doesn't matter;
4. I disguised an IP address in the same network segment as the IP address of the physical network card as the next hop, and then added a static ARP ing to the MAC address of the tap0 network card 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 something is wrong, fine-tune it. The final part of fine-tuning is actually success;
6. The first obstacle is to find that the 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 one 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 I rolled back the prefix to 8 bits, and now it is aligned with the and 24 bits you requested;
9. The prefix reverts 8 bits, which is equivalent to a large summary. The direct link routing 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 I do?
10. Add a 24-bit link direct connection route based on the longest mask. It 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!
Issues left
Basically, the problem has been solved. The only thing left behind is how to combine with openvpn, that is, how to write the aforementioned manual operations to plugin (I have completely abandoned the script ), what's more is the TAP-Win32 initialization problem, if it is not disconnected from the bridge, it can also be initialized? Even if it is not difficult, modify the openvpn Windows client code, that is, the ifdef Win32 paragraphs.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
