Android OpenVPN ask a question.
The question now is this, I use PC when version of openvpn, after consultation with the server will create a tun interface and add routes. Probably the route follows:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
0.0.0.0 192.168.12.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.12.1 0.0.0.0 UG 204 0 0 eth0
10.2.5.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.2.5.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.2.5.192 0.0.0.0 255.255.255.252 U 0 0 0 tun0
XX.XX.XX.XX 0.0.0.0 255.255.255.255 H 0 0 0 eth0
128.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
192.168.12.0 0.0.0.0 255.255.252.0 U 204 0 0 eth0
192.168.12.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
Which the above code on line 8, which is this line:
XX.XX.XX.XX 0.0.0.0 255.255.255.252 U 0 0 0 eth0
It OpenVPN client by calling the route command added to it.
(OPENVPN my PC side is running on the LINUX)
Therefore, it is well understood, which is the normal flow of OpenVPN, probably as follows:
1, the first route is redirected to the first tun interface
2, and then to listen to the tun device data
transmitted through the OpenVPN daemon3, then browse the Internet, will produce some data, because the route is redirected in the first step, so that the data will flow tun interface
4, then we will get the original IP packet
Step 3 rounds of data5, in step 4 by the original IP data encryption process performed
6, to send encrypted data to the top of the route in detail the route, which is on XX.XX.XX.XX server.
Step 6 above is probably one of the processing logic OpenVPN. OpenVPN can be proved to implement the logic of the PC side is normal.
Here we realize the Android OpenVPN logic look.
I use OpenVPN For Android by side into the PC side and the same remote server, I get the following routing information:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
0.0.0.0 192.168.12.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.12.1 0.0.0.0 UG 204 0 0 eth0
10.2.5.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.2.5.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.2.5.192 0.0.0.0 255.255.255.252 U 0 0 0 tun0
XX.XX.XX.XX 0.0.0.0 255.255.255.255 H 0 0 0 tun0
128.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
192.168.12.0 0.0.0.0 255.255.252.0 U 204 0 0 eth0
192.168.12.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
Which the above code on line 8, which is this line:
XX.XX.XX.XX 0.0.0.0 255.255.255.252 U 0 0 0 tun0
He eventually passed the device is tun0 .. instead of eth0.
From the above routing point of view, and the new Android 4.0 after the VPN interfaces provided by a third-party VPN view, get this routing information is normal!
We can look Android 4.0 offers new interface is this:
VpnService.Builder
In fact, there are two interfaces to create VPN interface, and add routes, respectively, are so separate:
VpnService.Builder:
establish ()
Create a VPN interface using the parameters supplied to this builder.
VpnService.Builder:
addRoute (String address, int prefixLength)
Convenience method to add a network route to the VPN interface using a numeric address string.
We can explain this function from addRoute point of view, he just wanted to create a route for the VPN interface, which means that he can only give tun0 this interface to create a route. So get routing information above is not surprising to see openvpn for android through the bottom of the core code to see him is achieved:
void add_route (struct route * r, ......)
{
...
network = print_in_addr_t (r-> network, 0, & gc);
netmask = print_in_addr_t (r-> netmask, 0, & gc);
gateway = print_in_addr_t (r-> gateway, 0, & gc);
...
# If defined (....) / / this is to choose a different platform
...
# Elif defined (TARGET_ANDROID) / / on Android through this branch to operate.
struct buffer out = alloc_buf_gc (64, & gc);
buf_printf (& out, "% s% s", network, netmask);
management_android_control (management, "ROUTE", buf_bptr (& out));
# Elif defined (....)
...
}
Through the above code you can see the bottom to the top in the transmission route information, did not specify which interface to go out, so at the end of the upper receiving ROUTE Control command , will call I just said VpnService.Builder.addRoute () function to complete the route added. So ultimately will only get one sent out from the tun0 interface to the routing information.
The above analysis is normal! I also think that in accordance with the operation!
it! questions coming!
why in the absence of details of the route, Android version of OpenVPN can normally use it! Default route has been completely redirected! There is no reason you can send out packets Yeah! And I see the iptables and ip rule (policy-based routing), and there is no definition, so you can judge, iptables and routing strategies do not help, but completely routed through its own operations, through real side discovered that he was a real default by routing, which is following the route sent out.
0.0.0.0 192.168.12.1 0.0.0.0 UG 0 0 0 eth0
And after using the OpenVPN, OpenVPN has been added to the system routing table two can cover the entire segment of the route follows:
0.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
128.0.0.0 0.0.0.0 128.0.0.0 U 0 0 0 tun0
by the above two routes is completely covered with the default route, and why he eventually get out of it from the default route? ? ? ?
Please OpenVPN version of Android has great God who understand pointing 12.
Reply:
correct you:
Routing OpenVPN for PC is this:
XX.XX.XX.XX 0.0.0.0 255.255.255.255 H 0 0 0 eth0
OpenVPN for Android routing is this:
XX.XX.XX.XX 0.0.0.0 255.255.255.255 H 0 0 0 tun0
Above the red part is the content changes
Reply:
Tea God God can not sink paste from the top
Reply:
Too much food, which did not know, well, I do not know
Reply:
Top up, continue to wait for the experts.
Reply:
Give top up saying
Reply:
There are many ways to redirect, you can use if you can root SO_BINDTODEVICE do.
If the UDP, you can open a socket IP_PKTINFO do.
But looks like Android provides an interface
in the VpnService
Roughly as follows:
public boolean protect (int socket)
Added in API level 14
Protect a socket from VPN connections. The socket will be bound to the current default network interface, so its traffic will not be forwarded through VPN. This method is useful if some connections need to be kept outside of VPN. For example, a VPN tunnel should protect itself if its destination is covered by VPN routes. Otherwise its outgoing packets will be sent back to the VPN interface and cause an infinite loop. This method will fail if the application is not prepared or is revoked.
The socket is NOT closed by this method.
Returns
true on success.
Reply:
This function will be called to protect ConnectivityService.java by Binder in protectVpn function.
The ConnectivityService.java in protectVpn function will eventually be transferred jniProtect function.
And jniProtect this function will eventually call the JNI layer com_android_server_connectivity_Vpn.cpp of protect function . .
And protect the function will eventually call bind_to_interface function. This function is defined as follows:
static int bind_to_interface (int socket, const char * name)
{
if (setsockopt (socket, SOL_SOCKET, SO_BINDTODEVICE, name, strlen (name))) {
ALOGE ("Cannot bind socket to% s:% s", name, strerror (errno));
return SYSTEM_ERROR;
}
return 0;
}
In fact, he was eventually used SO_BINDTODEVICE added to the corresponding socket export standards. Details of the route is not done socket outlet device can also be specified ways. But currently there is a routing table must be set up to send out exports from the specified interface. Otherwise it will not be sent out.
No comments:
Post a Comment