Hello, let me share my experience.
There are applications that are critical to breaking the connection, reconnection is painful and not always. Set a goal, make jumps of routes and physical connections transparent, so that the connection is constant and TCP connection is not torn.
And the old, kind and lamp openvpn will help in this. But installation and configuration is a topic that has been beaten for a long time, it is not planned to touch it.
')
What do we need:
- Linux server with constant IP (vps, vds, dedic or just home)
- Openvpn server and client configured to work on UDP .
- iproute2 - in fact, for the focus, you need a working ip utility on Android.
- You will also need to make changes to the source code of openvpn-settings with the subsequent build of apk.
Let's get started
Let's start with editing openvpn-settings. The bottom line is that for any change in the network configuration, the
SIGUSR1 command is sent to the native openvpn daemon, which causes it to disconnect and reconnect. For our purposes, this is harmful, but we still want to be able to perform some actions when changing the network configuration.
Someone will say, but there is a
persist-tun . I answer, it does not work the way I want, openvpn jerks the “lie-up” scripts every time
SIGUSR1 arrives. And, in principle, it is almost impossible to distinguish the restart from the start by the available variables, without frills. This undermines the whole venture, but simply and reliably.
Therefore, we will replace sending
SIGUSR1 with a shell script call.
Download the source team
hg clone code.google.com/p/android-openvpn-settings
Open the file
\ src \ de \ schaeuffelhut \ android \ openvpn \ service \ ManagementThread.java
Find the function
public void sendSignal (int s) and we will edit it.
We comment on sending
SIGUSR1 and insert a call to our script with root rights.
The script file will be called exactly the same as the connection file, but supplemented with the extension sh.
It should work like this:
case SIGUSR1:
Everything can be collected, signed, installed. Before installing, be sure to uninstall the old “openvpn-setting” from the system.
Next, check the openvpn connection configuration.
Server
On the server, a
float directive is required, since we will change the physical connection, and with it the IP. Also, the server must transmit the internal address of our client to the external network. For this, it is more convenient for me to use the
up and
down directives.
up "/ bin / sh / etc / openvpn / androidupdown"
down "/ bin / sh / etc / openvpn / androidupdown"
The script should be something like this:
NATGW="1.2.3.4"
Customer
First, you need to remove the
redirect-gateway directive, if it has one. But set
up and
down with an indication of the script that will configure the routes. If you remember, we agreed that the file name will repeat the configuration name with the addition of sh. Yes, we will call the same script from both the daemon and the monitor.
If the configuration is called “testconfig.ovpn”, then so be it:
up "/ system / bin / sh /sdcard/openvpn/testconfig.ovpn.sh"
down "/ system / bin / sh /sdcard/openvpn/testconfig.ovpn.sh"
Script
Here it is worth explaining a little.
We create an alternative routing table with the number 100 in which we specify the default vpn tunnel by the gateway. And we add a routing rule that wraps all traffic in our table at number 100, before it gets into the main table called main.
In an alternative table, there is a route that pushes packets destined for the server back into the chain of rules. Further they will get to the main routing table. There they will be able to find the main route of the physical connection. But, and if they do not find it, it will happen during reconnects, then it is not terrible. Openvpn may suffer for some time, but of course not forever. Only messages in the logs will remind you that there is no connection for a short time.
Do not forget the scripts should end with a line break.
To allow running scripts on Android, you need to install the “Built-in + script” in the “Preferences”, which are called by a long tap on the connection. Now you can try.
As a result of testing, it turned out that some programs themselves check the status of the network and try to reconnect during any changes. Then either ask the authors to correct the situation. Either independently compile and correct. In any case, the TCP session is closed, not by timeout, but as it should be.
I would welcome any criticism and comments. I wish a stable connection!