OpenVPN-TAP mode/Policy Routing on Android, androidopenvpn-tap

OpenVPN-TAP mode/Policy Routing on Android, androidopenvpn-tap
Wake up and write a log.
On the OpenVPN Service FAQ of Android, there are three questions and three answers about the TAP mode. The final answer is: Support TAP via emulation. This was also implemented by myself in the past few months. To ask why Android itself cannot provide support for TAPmode, it seems that the author of VPNService is not concerned. The suggestion is:
If you really want to see tap-style tunnels supported in OpenVPN Connect, we wocould encourage you tocontact the Google Android team and ask that the VpnService API be extended to allow this. without such changes to the VpnService API, it is not possible for non-root apps such as OpenVPN Connect to support tap-style tunnels.
This seems to be a circle, but if we think about it carefully, we will find that this circle was originally like this:
1. The Android platform has multiple completely different underlying Implementations under a public layer, including the Linux kernel;
2. Opening the root permission of Android means that users can touch any underlying layer;
3. All public sets, including APIs and functions, must not be built based on the underlying layer, and root permissions cannot be open to all common users;
4. There must be a public layer based on which the user needs to implement
5. This layer is the Android platform.
What we need to understand is that the tun. ko driver itself is very short, and it is very simple. The reason why it can load successfully on your Linux BOX is that your Linux BOX implements Ethernet and check whether your kernel config file has:
CONFIG_NET_ETHERNET = y
What about this line? In fact, the tun's TAP mode is heavily dependent on this kernel compilation option. However, for Android, because its underlying Linux kernel is completely customized based on the specific device, you cannot guarantee that it will certainly support Ethernet. For more information, see http://source.android.com/source/building-kernels.html.
Although most Android devices support the tun driver of the TAP mode for root users, this does not indicate any problems. You still cannot guarantee that Ethernet support is required. The above self-ring explanation circle shows that the Android platform should not be built based on the complete components that the root user can touch...
Of course, you can still use the TAP mode in VPNService! The answer is to build this TAP mode on the Android platform. How can this problem be solved? Support TAP via emulation! I have already done a good job. The solution is very simple, that is, an ARP processing and Ethernet encapsulation/decoding encapsulation module are built in OpenVPN. The Code comes from uIP. This is not the point. The point is, do you have to be so capricious? Why does TUN mode mean no ?! Also from the Android FAQ, the following may add a few points to the TUN mode:
The configuration of the VPN tunnel consists of the IP address and the networks that shoshould be routed over this interface. especially, no peer partner address or gateway address is needed or required. special routes to reach the VPN Server (for example added when using redirect-gateway) are not needed either. the application will consequently ignore these settings when importing a configuration. the app ensures with the VPNService API that the connection to the server is not routed through the VPN tunnel.
Yes, as you can see, using TUN mode will save a lot of configuration, and you no longer need the IP address information of the Peer virtual network card. After the tunnel is established, when you configure the route, you only need to specify the route exit without pointing out the next hop. In fact, because the virtual network card of TUN mode is in point-to-point mode (the next hop is implicit and clear !), However, only the NIC in multi-access mode needs to parse the next hop.
Enter the second topic of this log. Android 4.4 + uses the policy firewall mechanism to add a route through the OpenVPN virtual Nic. This is because of an episode...
One day about a month ago, I went with my colleagues to troubleshoot a problem. I used adb to log on to the Android background and started the VPN, the iproute2 command set is routinely run (this tool can solve almost 98.7512% of the problem), and then the iptables-save command is used to generate a sense of frustration, the whole person is messy in an instant... it's so messy that there are rules for IPMARK. ip ru ls can see the extra route table. mark seems to be 0x3c or something... the reason for my instant collapse is that I realized that it was time for me to pay off my debt. After a few words of self-help, the customers also followed me... no one has ever moved this system. iproute2 + iptables + mark and the naming style of the policy route table are similar to mine, I admit, "this is the debugging method I added a few months ago... ", actually, I don't know what's going on... the problem is that only people around me seem to be able to do this kind of thing, and naming rules don't seem like a vendor's handwriting, so I must have done it! This is a natural reasoning .... The problem was solved that day. After that, I have been remembering memories. When did I do that? I was puzzled until I encountered another problem. Another colleague of mine said that the Android 4.4 route could not be added. Of course, the failure to add a route means that OpenVPN cannot be used, which is a serious problem. Later, google + iproute2 came into being. Later, I found some clues about ip rule. I added a new route table to handle data packets related to the OpenVPN data channel! So google confirmed and found the following text:
Routing/Interface Configuration

The Routing and interface configuration is not done via traditional ifconfig/route commands but by using the VPNService API. This results in a different routing configuration than on other OSes.

The configuration of the VPN tunnel consists of the IP address and the networks that shoshould be routed over this interface. especially, no peer partner address or gateway address is needed or required. special routes to reach the VPN Server (for example added when using redirect-gateway) are not needed either. the application will consequently ignore these settings when importing a configuration. the app ensures with the VPNService API that the connection to the server is not routed through the VPN tunnel.

The VPNService API does not allow specifying networks that shocould not be routed via the VPN. as a workaround the app tries to detect networks that shocould not be routed over tunnel (e.g. route x. x. x. x y. y. y. y net_gateway) and calculates a set of routes that excludes this routes to emulate the behaviour of other platforms. the log windows shows the configuration of the VPNService upon establishing a connection.

Behind the scenes: Android 4.4 + does use policy routing. Using route/ifconfig will not show the installed routes. Instead use ip rule, iptables-t mangle-L
Please pay attention to the last paragraph! In the future, never admit that there are too many people who share the same idea. People who share the same idea will be divided by group. In addition, if you want to have confidence in yourself, the developer of the manufacturer will make mistakes and be nonstandard. Of course, the style of solving the problem may be the same as that of the developer, after all, knowledge is shared, and I may share the same culture with him. The difference may be that he is on Google (but probably ), but I don't have the ability to get in ).
Alas, I was not ill this weekend. Instead, I did not feel relaxed, responsible, and did nothing. I had a braised leg of goat at noon, which was also a positive thing.