info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Two questions for Marek about the operation of the vpnstatus script
15 views
Skip to first unread message
VPN user
Apr 9, 2016, 8:23:48 PM4/9/16
to
Hi Marek,
I have a question of the operation of "vpnstatus.sh", which I don't
understand how it actually works.
#############################################################
# script: vpnstatus.sh
# written by: Marek Novotny
# version: 2.8
# date: Mon Dec 28 05:41:00 PST 2015
# purpose: test status of live vpn connection
# : kill torrent if vpn disconnects
# licence: GPL v2 (only)
# github: https://github.com/marek-novotny
# readme:
#############################################################
In operation, your vpnstatus (which I've renamed "vpnwatch") keeps
watch perfectly over sensitive apps, and kills them immediately
upon loss of the VPN.
I can "see" this happen, under (at least) three circumstances:
1. When I manually control-C out of a VPN session
2. When I can see the VPN session falter (perhaps to recover & falter again)
3. When there is no "apparent" change in the VPN session
And, there is a fourth circumstance, where vpnstatus does NOT kill apps!
4. When a ping no longer works but the session remains active
In the first 2 of the 4 situations above, it's obvious what
happened, especially in the case of #2 above where I can see
the VPN output log (which defaults to "verb 3") falter, and often
recover, just to falter again.
In those first two circumstances, the vpnstatus script works flawlessly.
I'm sure the vpnstatus script is also working flawlessly in the #3
situation above; I just can't figure out *what* happened.
That is, sometimes the apps all just die; but everything else seems
fine.
When I run "route -n" situation 3 looks like a normal VPN session.
When I run "ping -c1 8.8.8.8" it looks like a normal VPN session.
When I look at the VPN session log, it didn't falter (i.e., it's
still at the line saying "Initialization Sequence Completed".
So, my first of two questions is what test can I run, in situation
3 above, to figure out what actually happened to cause all the apps
to suddenly die?
Note: This happens once every few days, and I'm on VPN every single
day, so, it doesn't happen all that often; but it happens. Why?
The second question I ask is actually unfair of me to ask since
vpnstatus was never intended to handle the situation of #4.
#4 happens usually when I walk away from the computer while on a
VPN session. Let's say I come back two hours later. Everything
looks normal, but there is actually zero connectivity.
That is, a "route -n" looks normal.
The vpn session log looks normal (the last line output being the
same "Initialization Sequence Completed" that started the session).
But what fails is a "ping -c1 8.8.8.8" (and everything else that is
connected to the Internet).
So, Pan is still running.
Firefox is still running.
But there is zero connectivity.
So my second question is why didn't vpnstatus.sh detect this anomaly?
*************************************************************
In summary, I love vpnstatus but I have two questions of you:
Q1: In situation 3, how can I debug what caused vpnstatus to kill sensitive apps?
Q2: In situation 4, why didn't vpnstatus detect that the network disappeared?
*************************************************************
NOTE: Here is the exact script that I used, called vpnwatch.sh,
almost completely unmodified from its original form.
#!/bin/bash
# vpnwatch: Kills sensitive apps the exact instant VPN falters!
#############################################################
#
# script: vpnstatus.sh
# written by: Marek Novotny
# version: 2.8
# date: Mon Dec 28 05:41:00 PST 2015
# purpose: test status of live vpn connection
# : kill torrent if vpn disconnects
# licence: GPL v2 (only)
# github: https://github.com/marek-novotny
# readme: https://github.com/marek-novotny/vpntools
#
#############################################################
condition=""
sendMessage()
{
echo "$1"
}
# Note I gave up on trying to list Google's Chromium Browser! :(
# apps that should be terminated if VPN fails
processList=("pan" "firefox" "transmission")
# apps that should not be running under vpn
restrictedApps=("thunderbird")
# check of a process stored in the variable task is running or not
checkProcess()
{
unset procID
procID="$(ps -e | grep $task | grep -v panel | awk '{print $1}')"
if [ ! -z $procID ] ; then
return 0
else
return 1
fi
}
# terminate the given process stored in the variable task
terminateProcess()
{
kill -9 $procID
killall firefox
killall transmission
killall pan
}
# routine to test for processes, report their status and kill them if running
processTerminator()
{
checkProcess
if (($? == 0)) ; then
sendMessage "$task is running..."
sendMessage "Terminating $task..."
terminateProcess
if (($? == 0)) ; then
sendMessage "$task terminated..."
else
sendMessage "$task is still running..."
fi
fi
}
# generate a random IP to test ip route against
randomizer()
{
IFS=$' '
ary=()
for x in {1..4} ; do
ary+=($(($RANDOM % 221 + 1)))
done
if [[ ${ary[0]} -eq 10 || ${ary[0]} -eq 100 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 169 ]] && [[ ${ary[1]} -eq 254 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 172 ]] && [[ ${ary[1]} -eq 16 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 192 ]] && [[ ${ary[1]} -eq 168 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 198 ]] && [[ ${ary[1]} -eq 18 ]] ; then
randomizer
else
addr=$(echo "${ary[@]}" | awk '{print $1"."$2"."$3"."$4}')
fi
}
# kill apps that should not be running if VPN is connected.
# kills these apps once, if the script is running and the VPN
# tunnel becomes active
vpnOn()
{
if [[ $condition != "on" ]] ; then
condition="on"
echo "VPN status: $condition - ${devType[0]}: ${devType[1]}"
for x in ${restrictedApps[@]} ; do
task=$x
processTerminator
done
fi
}
# drop apps that should not be running if vpn tunnel fails
vpnOff()
{
if [[ $condition != "off" ]] ; then
condition="off"
echo "VPN status: $condition - ${devType[0]}: ${devType[1]}"
echo "Terminating apps..."
for x in ${processList[@]} ; do
task=$x
processTerminator
done
fi
}
randomizer
while true ; do
devType=($(ip route get $addr | awk 'NR==1 {print $(NF-2),$(NF-0)}'))
if [[ ${devType[0]} == tun? || ${devType[0]} == ppp? ]] ; then
vpnOn
else
vpnOff
fi
done
#END
I have a question of the operation of "vpnstatus.sh", which I don't
understand how it actually works.
#############################################################
# script: vpnstatus.sh
# written by: Marek Novotny
# version: 2.8
# date: Mon Dec 28 05:41:00 PST 2015
# purpose: test status of live vpn connection
# : kill torrent if vpn disconnects
# licence: GPL v2 (only)
# github: https://github.com/marek-novotny
# readme:
#############################################################
In operation, your vpnstatus (which I've renamed "vpnwatch") keeps
watch perfectly over sensitive apps, and kills them immediately
upon loss of the VPN.
I can "see" this happen, under (at least) three circumstances:
1. When I manually control-C out of a VPN session
2. When I can see the VPN session falter (perhaps to recover & falter again)
3. When there is no "apparent" change in the VPN session
And, there is a fourth circumstance, where vpnstatus does NOT kill apps!
4. When a ping no longer works but the session remains active
In the first 2 of the 4 situations above, it's obvious what
happened, especially in the case of #2 above where I can see
the VPN output log (which defaults to "verb 3") falter, and often
recover, just to falter again.
In those first two circumstances, the vpnstatus script works flawlessly.
I'm sure the vpnstatus script is also working flawlessly in the #3
situation above; I just can't figure out *what* happened.
That is, sometimes the apps all just die; but everything else seems
fine.
When I run "route -n" situation 3 looks like a normal VPN session.
When I run "ping -c1 8.8.8.8" it looks like a normal VPN session.
When I look at the VPN session log, it didn't falter (i.e., it's
still at the line saying "Initialization Sequence Completed".
So, my first of two questions is what test can I run, in situation
3 above, to figure out what actually happened to cause all the apps
to suddenly die?
Note: This happens once every few days, and I'm on VPN every single
day, so, it doesn't happen all that often; but it happens. Why?
The second question I ask is actually unfair of me to ask since
vpnstatus was never intended to handle the situation of #4.
#4 happens usually when I walk away from the computer while on a
VPN session. Let's say I come back two hours later. Everything
looks normal, but there is actually zero connectivity.
That is, a "route -n" looks normal.
The vpn session log looks normal (the last line output being the
same "Initialization Sequence Completed" that started the session).
But what fails is a "ping -c1 8.8.8.8" (and everything else that is
connected to the Internet).
So, Pan is still running.
Firefox is still running.
But there is zero connectivity.
So my second question is why didn't vpnstatus.sh detect this anomaly?
*************************************************************
In summary, I love vpnstatus but I have two questions of you:
Q1: In situation 3, how can I debug what caused vpnstatus to kill sensitive apps?
Q2: In situation 4, why didn't vpnstatus detect that the network disappeared?
*************************************************************
NOTE: Here is the exact script that I used, called vpnwatch.sh,
almost completely unmodified from its original form.
#!/bin/bash
# vpnwatch: Kills sensitive apps the exact instant VPN falters!
#############################################################
#
# script: vpnstatus.sh
# written by: Marek Novotny
# version: 2.8
# date: Mon Dec 28 05:41:00 PST 2015
# purpose: test status of live vpn connection
# : kill torrent if vpn disconnects
# licence: GPL v2 (only)
# github: https://github.com/marek-novotny
# readme: https://github.com/marek-novotny/vpntools
#
#############################################################
condition=""
sendMessage()
{
echo "$1"
}
# Note I gave up on trying to list Google's Chromium Browser! :(
# apps that should be terminated if VPN fails
processList=("pan" "firefox" "transmission")
# apps that should not be running under vpn
restrictedApps=("thunderbird")
# check of a process stored in the variable task is running or not
checkProcess()
{
unset procID
procID="$(ps -e | grep $task | grep -v panel | awk '{print $1}')"
if [ ! -z $procID ] ; then
return 0
else
return 1
fi
}
# terminate the given process stored in the variable task
terminateProcess()
{
kill -9 $procID
killall firefox
killall transmission
killall pan
}
# routine to test for processes, report their status and kill them if running
processTerminator()
{
checkProcess
if (($? == 0)) ; then
sendMessage "$task is running..."
sendMessage "Terminating $task..."
terminateProcess
if (($? == 0)) ; then
sendMessage "$task terminated..."
else
sendMessage "$task is still running..."
fi
fi
}
# generate a random IP to test ip route against
randomizer()
{
IFS=$' '
ary=()
for x in {1..4} ; do
ary+=($(($RANDOM % 221 + 1)))
done
if [[ ${ary[0]} -eq 10 || ${ary[0]} -eq 100 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 169 ]] && [[ ${ary[1]} -eq 254 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 172 ]] && [[ ${ary[1]} -eq 16 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 192 ]] && [[ ${ary[1]} -eq 168 ]] ; then
randomizer
elif [[ ${ary[0]} -eq 198 ]] && [[ ${ary[1]} -eq 18 ]] ; then
randomizer
else
addr=$(echo "${ary[@]}" | awk '{print $1"."$2"."$3"."$4}')
fi
}
# kill apps that should not be running if VPN is connected.
# kills these apps once, if the script is running and the VPN
# tunnel becomes active
vpnOn()
{
if [[ $condition != "on" ]] ; then
condition="on"
echo "VPN status: $condition - ${devType[0]}: ${devType[1]}"
for x in ${restrictedApps[@]} ; do
task=$x
processTerminator
done
fi
}
# drop apps that should not be running if vpn tunnel fails
vpnOff()
{
if [[ $condition != "off" ]] ; then
condition="off"
echo "VPN status: $condition - ${devType[0]}: ${devType[1]}"
echo "Terminating apps..."
for x in ${processList[@]} ; do
task=$x
processTerminator
done
fi
}
randomizer
while true ; do
devType=($(ip route get $addr | awk 'NR==1 {print $(NF-2),$(NF-0)}'))
if [[ ${devType[0]} == tun? || ${devType[0]} == ppp? ]] ; then
vpnOn
else
vpnOff
fi
done
#END
Marek Novotny
Apr 10, 2016, 12:57:50 PM4/10/16
to
On 2016-04-10, VPN user <vpn...@example.com> wrote:
> Hi Marek,
>
> I have a question of the operation of "vpnstatus.sh", which I don't
> understand how it actually works.
I can't even read it and I wrote it. It became a horrible mess so I
> Hi Marek,
>
> I have a question of the operation of "vpnstatus.sh", which I don't
> understand how it actually works.
threw it in the trash...
I uploaded v4, pretty much a complete rewrite. You can download it from
the github and try that out. It is much easier to read and I added a ton
of comments all over the place to help explain it as well.
See if this isn't simpler and hopefully more robust.
--
Marek Novotny
https://github.com/marek-novotny
VPN user
Apr 10, 2016, 2:05:14 PM4/10/16
to
Marek Novotny wrote:
>
> I can't even read it and I wrote it. It became a horrible mess so I
> threw it in the trash...
>
> I uploaded v4, pretty much a complete rewrite. You can download it from
> the github and try that out. It is much easier to read and I added a ton
> of comments all over the place to help explain it as well.
>
> See if this isn't simpler and hopefully more robust.
Hi Marek,
>
> I can't even read it and I wrote it. It became a horrible mess so I
> threw it in the trash...
>
> I uploaded v4, pretty much a complete rewrite. You can download it from
> the github and try that out. It is much easier to read and I added a ton
> of comments all over the place to help explain it as well.
>
> See if this isn't simpler and hopefully more robust.
Thanks for the response to use your latest code.
https://github.com/marek-novotny/
I can understand that you don't want to deal with older vpntools:
https://github.com/marek-novotny/vpntools
I guess the good news is that you're always progressing and so
you recommend, naturally, to use the latest code. I'll the latest
vpnstatus and let you know how it goes.
https://github.com/marek-novotny/vpntools/blob/master/vpnstatus.sh
The two things I expect are that it will:
1. Kill everything the moment the vpn connection falters
2. Not kill things if the vpn connection didn't falter
The latter question is the one I'm trying to figure out, since sometimes
(the older) vpnstatus kills the connection, but I don't see any indication
of why.
They're stealthy mystery disconnects.
I'm sure there is a reason.
But I don't see any *indication* of the reason.
That's really the main question here.
I'd just like to just understand why the vpn connection died:
a. The connection log doesn't seem to indicate a failure
b. The route -n doesn't seem to indicate a failure
c. Even the outpout of vpnstatus doesn't seem to indicate a failure
It may be totally outside the bounds of vpnstatus, I guess.
So, I'll use the latest v4 vpnstatus and see what it does.
It may take a while to gather enough data though, because the non-mystery
dropouts happen all the time (maybe one out of 10) - but the stealth
dropouts are much more rare.
Marek Novotny
Apr 10, 2016, 2:19:00 PM4/10/16
to
On 2016-04-10, VPN user <vpn...@example.com> wrote:
> The two things I expect are that it will:
> 1. Kill everything the moment the vpn connection falters
> 2. Not kill things if the vpn connection didn't falter
Well, the script is essentially watching what the device id is every
> 1. Kill everything the moment the vpn connection falters
> 2. Not kill things if the vpn connection didn't falter
second. And if it changes at all it kills the connection. Now, rather
than using awk to point to a particular field I'm now always looking for
the value that follows "dev" in the command ip route get 8.8.8.8. So
that should make this a little safer.
It first determines the device ID and then stores it. And then checks
that ID for change while opening a VPN connection. It then holds those
two answers and compares them on going. If the original device ID
changes during the vpn connection then you see the new ID. And if for
any reason that new ID changes while connected I interpret that as a
failure of the tunnel, even if for just one second. That's what makes
this so fast compared to earlier versions which tested the connected
every 5 seconds for a specific device name, which was /tun/.
So what you might be seeing is either a drop in connection for a brief
period, which the script catches and shuts down everything as a safety
measure or awk was sometimes returning something I never intended
because it is kind of a blind way to get a particular result. So awk is
gone. There is no awk being used to blindly grab a field location. Now,
we have to see "dev" and take the proceeding value after dev or there is
no state change.
So see how this plays out. See if it is less prone to unexpected
behavior. And again, you'd be more likely to understand what's going on
and why in the script as there are comments all over it explaining what
each part does.
Marek Novotny
Apr 10, 2016, 4:29:01 PM4/10/16
to
On 2016-04-10, VPN user <vpn...@example.com> wrote:
> Hi Marek,
> Thanks for the response to use your latest code.
I screwed up a little. I have updated it to v4.2 just now. You'll need
> Thanks for the response to use your latest code.
this new version as I totally screwed up what should happen if the ovpn
file times out. All patched up and committed. Get the latest...
https://github.com/marek-novotny/vpntools
VPN user
Apr 10, 2016, 5:09:18 PM4/10/16
to
Marek Novotny wrote:
> I screwed up a little. I have updated it to v4.2 just now. You'll need
> this new version as I totally screwed up what should happen if the ovpn
> file times out. All patched up and committed. Get the latest...
>
> https://github.com/marek-novotny/vpntools
Heh heh ... yeah. I know ... ...I was just debugging that when I saw
> I screwed up a little. I have updated it to v4.2 just now. You'll need
> this new version as I totally screwed up what should happen if the ovpn
> file times out. All patched up and committed. Get the latest...
>
> https://github.com/marek-novotny/vpntools
your note.
$ vpnsort.sh (picks the fastest file in the current directory)
$ vpnstatus.sh vpngate_KR_na_na_na_39.123.160.54-vpn292366561.opengw.net_udp1545_20160405_6.34dn_2.25up_337ms.ovpn
vpnstatus.sh status: vpngate_KR_na_na_na_39.123.160.54-vpn292366561.opengw.net_udp1545_20160405_6.34dn_2.25up_337ms.ovpn accepted
vpnstatus.sh status: please validate sudo access:
vpnstatus.sh status: obtaining device ID now
vpnstatus.sh status: device ID set to wlan0
vpnstatus.sh status: attempting to connect to vpn
vpnstatus.sh status: vpn process is running under id 2820
[....+....+....+....+....]
#########################vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: vpn killed
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
vpnstatus.sh status: process 2820 terminated
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
#vpnstatus.sh status: vpn connection timeout reached
vpnstatus.sh status: attempting to kill the vpn
vpnstatus.sh status: kill was unsuccessful
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to wlan0
/usr/local/bin/vpnstatus.sh: line 176: killvpn: command not found
VPN user
Apr 10, 2016, 5:16:31 PM4/10/16
to
VPN user wrote:
> Heh heh ... yeah. I know ... ...I was just debugging that when I saw
> your note.
>
> $ vpnsort.sh (picks the fastest file in the current directory)
> $ vpnstatus.sh vpngate_KR_na_na_na_39.123.160.54-vpn292366561.opengw.net_udp1545_20160405_6.34dn_2.25up_337ms.ovpn
Hi Marek,
> Heh heh ... yeah. I know ... ...I was just debugging that when I saw
> your note.
>
> $ vpnsort.sh (picks the fastest file in the current directory)
> $ vpnstatus.sh vpngate_KR_na_na_na_39.123.160.54-vpn292366561.opengw.net_udp1545_20160405_6.34dn_2.25up_337ms.ovpn
I just tested the latest (version 4.4) vpnstatus on the same file
above and this time, it didn't loop forever when the ovpn file
is bad.
:)
$ vpnstatus.sh vpngate_KR_na_na_na_39.123.160.54-vpn292366561.opengw.net_udp1545_20160405_6.34dn_2.25up_337ms.ovpn
vpnstatus.sh status: vpngate_KR_na_na_na_39.123.160.54-vpn292366561.opengw.net_udp1545_20160405_6.34dn_2.25up_337ms.ovpn accepted
vpnstatus.sh status: please validate sudo access:
vpnstatus.sh status: obtaining device ID now
vpnstatus.sh status: attempting to connect to vpn
vpnstatus.sh status: vpn process is running under id 18055
[....+....+....+....+....]
#########################
vpnstatus.sh status: openvpn config file connect time exceeded...
vpnstatus.sh status: openvpn has been terminated...
VPN user
Apr 10, 2016, 5:18:46 PM4/10/16
to
Marek Novotny wrote:
> I have updated it to v4.2 just now.
Hi Marek,
> I have updated it to v4.2 just now.
I accidentally already had openvpn running when I tested vpnstatus
version 4.4 and it allowed me to run the second vpn, but when that
second vpn session failed, it killed the first (existing) vpn
session.
To prevent those multi-vpn oddities from happening, you probably
want to add something like this (which is your code snippet anyway)
to the beginning of the vpnstatus.sh script:
# Abort if openvpn is already running
openvpnPID=$(pgrep openvpn)
if [ $? -ne 1 ] ; then
echo "Oops: It seems openvpn is already running; aborting"
exit 1
fi
VPN user
Apr 10, 2016, 5:28:34 PM4/10/16
to
VPN user wrote:
> I accidentally already had openvpn running when I tested vpnstatus
> version 4.4 and it allowed me to run the second vpn, but when that
> second vpn session failed, it killed the first (existing) vpn
> session.
I tested vpnstatus version 4.4 against an existing running vpn on
> I accidentally already had openvpn running when I tested vpnstatus
> version 4.4 and it allowed me to run the second vpn, but when that
> second vpn session failed, it killed the first (existing) vpn
> session.
tun0, where, in this second test, which defaulted to tun1, the
vpnstatus.sh seems to have put a tunnel on top of a tunnel.
I'm not sure how to interpret what the result really was, but
what *seems* to have resulted were *two* simultaneous (somehow
mixed?) VPN sessions - the original on tun0 and the new one on
tun1 (even though both ovpn files simply specified "dev tun").
I won't claim to be able to understand the resulting routing table,
but here's the mixmash that resulted from running the two vpn
sessions at the same time:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.211.1.6 128.0.0.0 UG 0 0 0 tun1
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
10.211.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.211.1.6 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
39.123.160.54 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
114.183.199.141 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
128.0.0.0 10.211.1.6 128.0.0.0 UG 0 0 0 tun1
178.163.20.236 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
220.211.32.220 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
$ ip route get 8.8.8.8
8.8.8.8 via 10.211.1.6 dev tun1 src 10.211.1.5
cache
I can't claim to understand routing tables when VPN is involved, so
I can't really tell if this is a tunnel on top of a tunnel, or if
this is just one tunnel (which one?).
I guess, if it actually is a tunnel inside a tunnel, that would
have its uses.
VPN user
Apr 10, 2016, 5:45:01 PM4/10/16
to
Marek Novotny wrote:
> Well, the script is essentially watching what the device id is every
> second. And if it changes at all it kills the connection. Now, rather
> than using awk to point to a particular field I'm now always looking for
> the value that follows "dev" in the command ip route get 8.8.8.8. So
> that should make this a little safer.
Hi Marek,
> Well, the script is essentially watching what the device id is every
> second. And if it changes at all it kills the connection. Now, rather
> than using awk to point to a particular field I'm now always looking for
> the value that follows "dev" in the command ip route get 8.8.8.8. So
> that should make this a little safer.
The newer vpnstatus 4.4 script is noticeably slower to kill apps than
is the older vpnstatus version 2.8 (dated Mon Dec 28 05:41:00 PST 2015).
allowed_vpn_apps=(pan firefox transmission) # allowed to run under vpn only, will terminate if vpn fails
In the older version 2.8 script, when I control+C out of the vpn session,
all the whitelisted apps die seemingly instantly.
However, with this line in the newer 4.4 vpnstatus script, the three
apps die one by one, visibly and clearly much slower. Of course, it
only takes a couple of seconds, but the older script killed them before
I could even blink. Just so you know ...
vpnstatus.sh status: vpngate_JP_40_Tokyo_Hachioji_124.215.80.117-vpn139597105.opengw.net_udp1512_20160405_4.48dn_4.88up_150ms.ovpn accepted
vpnstatus.sh status: please validate sudo access:
vpnstatus.sh status: obtaining device ID now
vpnstatus.sh status: attempting to connect to vpn
vpnstatus.sh status: vpn process is running under id 18801
[....+....+....+....+....]
#####
vpnstatus.sh status: obtaining vpn ID now
vpnstatus.sh status: vpn ID set to tun0
^C
vpnstatus.sh status: BREAK!
vpnstatus.sh status: task pan is running...
vpnstatus.sh status: task pan has been terminated.
vpnstatus.sh status: task firefox is running...
vpnstatus.sh status: task firefox has been terminated.
vpnstatus.sh status: task transmission is running...
vpnstatus.sh status: task transmission has been terminated.
VPN user
Apr 10, 2016, 6:01:34 PM4/10/16
to
Marek Novotny wrote:
>
> So see how this plays out. See if it is less prone to unexpected
> behavior. And again, you'd be more likely to understand what's going on
> and why in the script as there are comments all over it explaining what
> each part does.
Once before, you posted this radical change to vpnstatus.sh, which
>
> So see how this plays out. See if it is less prone to unexpected
> behavior. And again, you'd be more likely to understand what's going on
> and why in the script as there are comments all over it explaining what
> each part does.
encompassed both the session start and the watching over the session
into a single file.
But the new vpnstatus version 4.4 won't work for my current use model
without me adding a few things that already exist in other scripts:
My current use model (before the 4.4 version) is to start the program
with either one or zero arguments:
$ vpnstatus complete-filename-or-only-part-of-a-filename
$ vpnstatus
1. Where adding a complete file name or a partial file name means
to choose an arbitrary file in the current directory that contains
the given argument by the use of this in the vpnstatus script:
# If no arguments are provided, then use *.ovpn* as the argument for the next random file.
# If an argument is provided (e.g., US), then use "*that*" as the argument for the next file in order.
if [ $# -eq 0 ]; then
lsFileName=\*.ovpn
else
lsFileName=\*${1}\*
fi
2. And, where adding zero arguments means to choose an arbitrary file in
the current directory by the use of this in the vpnstatus script:
# Choose a random file out of the list of files that match the arguments:
for openvpnFileName in $(ls $lsFileName | shuf ) ; do
sudo openvpn --config "$openvpnFileName" --script-security 2 --up /etc/openvpn/update-resolv-conf --down /etc/openvpn/update-resolv-conf
kickOrKeep
done
You might want to consider adding this capability to choose any
random file in the directory, or to choose any random file based
on the file name (or parts of the file name) provided.
how vpnstatus works other than to give it the capability to
Marek Novotny
Apr 10, 2016, 6:03:58 PM4/10/16
to
On 2016-04-10, VPN user <vpn...@example.com> wrote:
> Hi Marek,
>
> I accidentally already had openvpn running when I tested vpnstatus
> version 4.4 and it allowed me to run the second vpn, but when that
> second vpn session failed, it killed the first (existing) vpn
> session.
Committed to v4.5. This will pre-test for openvpn and if it finds it,
>
> I accidentally already had openvpn running when I tested vpnstatus
> version 4.4 and it allowed me to run the second vpn, but when that
> second vpn session failed, it killed the first (existing) vpn
> session.
it will kill everything. This script now assumes it is the sole
connection and status tool. So a double run will close it all up as
the script assumes something is wrong since it didn't open the
connection.
If you don't like that idea, all you have to do is remove one call to
the kill routine. For myself, I don't run it unless I want it to do the
whole job for me. So if I see openvpn already running, I want the script
to kill it so that all I have to do is rerun it.
VPN user
Apr 10, 2016, 6:10:22 PM4/10/16
to
Marek Novotny wrote:
> So what you might be seeing is either a drop in connection for a brief
> period, which the script catches and shuts down everything as a safety
> measure or awk was sometimes returning something I never intended
> because it is kind of a blind way to get a particular result. So awk is
> gone. There is no awk being used to blindly grab a field location. Now,
> we have to see "dev" and take the proceeding value after dev or there is
> no state change.
Hi Marek,
> So what you might be seeing is either a drop in connection for a brief
> period, which the script catches and shuts down everything as a safety
> measure or awk was sometimes returning something I never intended
> because it is kind of a blind way to get a particular result. So awk is
> gone. There is no awk being used to blindly grab a field location. Now,
> we have to see "dev" and take the proceeding value after dev or there is
> no state change.
I understand you, and that *may* be happening, but it may be so brief
when the connectivity is lost that I can't catch it manually.
Certainly I don't "see" the loss in connectivity in:
1. A ping of 8.8.8.8 doesn't show the loss in connectivity
2. A route -n shows that the tunnel appears to still be up
3. An "ip route get 8.8.8.8" shows the tunnel still up
4. The openvpn session log doesn't appear to have faltered
Yet ... in those mysterious phantom cases, the vpnstatus.sh script
kills the whitelisted apps (transmission, pan, and firefox) but
mere moments later, when I run the four tests above, I can't
*see* any loss in connectivity.
It's not a big deal and you are probably correct that the loss of
connectivity is too fast for me to react.
If that's the case, then thank God that the vpnstatus script
caught it and instantly killed the whitelisted apps (transmission,
pan, and firefox) because it happens so fast, there's no way to
manually catch it because it goes right back up to full
connectivity instantly without any indication of a falter.
VPN user
Apr 10, 2016, 6:13:42 PM4/10/16
to
VPN user wrote:
> If that's the case, then thank God that the vpnstatus script
> caught it and instantly killed the whitelisted apps (transmission,
> pan, and firefox) because it happens so fast, there's no way to
> manually catch it because it goes right back up to full
> connectivity instantly without any indication of a falter.
However, my "jury" is still out that it could be something else,
> If that's the case, then thank God that the vpnstatus script
> caught it and instantly killed the whitelisted apps (transmission,
> pan, and firefox) because it happens so fast, there's no way to
> manually catch it because it goes right back up to full
> connectivity instantly without any indication of a falter.
since, even an instantaneously short loss of connectivity should
still show up in the openvpn log file (and, in these phantom cases,
there is nothing in the "verb 3" level openvpn log file).
I guess I could manually change the verb from 3 to something
bigger, to see if there is any indication in the openvpn log file.
Marek Novotny
Apr 10, 2016, 6:18:18 PM4/10/16
to
On 2016-04-10, VPN user <vpn...@example.com> wrote:
> Hi Marek,
>
> The newer vpnstatus 4.4 script is noticeably slower to kill apps than
> is the older vpnstatus version 2.8 (dated Mon Dec 28 05:41:00 PST 2015).
It's not actually slower to kill the app, it's slower to report killing
>
> The newer vpnstatus 4.4 script is noticeably slower to kill apps than
> is the older vpnstatus version 2.8 (dated Mon Dec 28 05:41:00 PST 2015).
it. For the first app anyway. There is a sleep 1 cycle between the
killing of the app and the reporting of the app being killed. On my
machine it is so fast that it double reports the app as being active
even after killing it. So I needed to slow it down a little.
> allowed_vpn_apps=(pan firefox transmission) # allowed to run under vpn only, will terminate if vpn fails
> In the older version 2.8 script, when I control+C out of the vpn session,
> all the whitelisted apps die seemingly instantly.
>
> However, with this line in the newer 4.4 vpnstatus script, the three
> apps die one by one, visibly and clearly much slower. Of course, it
> only takes a couple of seconds, but the older script killed them before
> I could even blink. Just so you know ...
VPN user
Apr 10, 2016, 6:27:35 PM4/10/16
to
Marek Novotny wrote:
> Committed to v4.5. This will pre-test for openvpn and if it finds it,
> it will kill everything. This script now assumes it is the sole
> connection and status tool. So a double run will close it all up as
> the script assumes something is wrong since it didn't open the
> connection.
>
> If you don't like that idea, all you have to do is remove one call to
> the kill routine. For myself, I don't run it unless I want it to do the
> whole job for me. So if I see openvpn already running, I want the script
> to kill it so that all I have to do is rerun it.
>
> https://github.com/marek-novotny/vpntools
Got the 4.5 version and will test.
> Committed to v4.5. This will pre-test for openvpn and if it finds it,
> it will kill everything. This script now assumes it is the sole
> connection and status tool. So a double run will close it all up as
> the script assumes something is wrong since it didn't open the
> connection.
>
> If you don't like that idea, all you have to do is remove one call to
> the kill routine. For myself, I don't run it unless I want it to do the
> whole job for me. So if I see openvpn already running, I want the script
> to kill it so that all I have to do is rerun it.
>
> https://github.com/marek-novotny/vpntools
I will need to add a few things though:
ARGUMENTS:
1. Accept zero or one argument
a. The one argument can be any portion of a filename
b. Then it will randomly choose the next ovpn file based on that argument
KICKORKEEP:
2. If the vpn session fails or if I kill the VPN session, allow me to do two things:
a. Allow me to kickorkeep (i.e., move) the file elsewhere with a case statement
b. Allow me to load in the next random file that fit the requirements
I already have this in the old vpnrun script (I posted the snippet that
allows this, a few moments ago) so I would need to port it over.
The use model is this:
A. I go to the vpn_winners directory which might have a thousand config files
B. I either run "vpnstatus" or "vpnstatus US" or "vpnstatus 12.123.123.12"
or "vpnstatus Buffalo" or "vpnstatus <whatever>".
C. It will start vpn on a random file in the selected set
Since the vpngate files are so flaky, the next step is important!
D. If the session fails, it allows me to kickorkeep the bad file into pre-defined bins
E. Likewise if I kill the session myself (e.g., if it's too slow for my liking)
F. And it will just go to the *next* random file in that selected set.
Here's the verbatim vpnrun.sh that currently does all that:
#!/bin/bash
# vpnrun runs vpn on all *.ovpn files or just selected files
#########################################################
# script: vpnrun.sh was initially based off vpntest by Marek Novotny
# version: original version of vpntest was .01
# date: original date of vpntest was 2015-11-24
# purpose: run vpn but kick out bad files
#########################################################
# To Use: vpnrun (this will select files *.ovpn)
# Or Use: vpnrun US (this will select files *US*)
# Or Use: vpnrun Buffalo (this will select files *Buffalo*)
# Or Use: vpnrun whatever (this will select files *whatever*)
set -u
# Abort if openvpn is already running
openvpnPID=$(pgrep openvpn)
if [ $? -ne 1 ] ; then
echo "Oops: It seems openvpn is already running; aborting"
exit 1
fi
_vpnPIDtmpFile=/tmp/openvpn.log
# Define good directories inside the current directory
# In general, run vpngeo & vpnspeed on the good ones:
LOCAL_GOOD_DIR=./good
# If they're really really fast, make note of them here:
LOCAL_FAST_DIR=./fast
# If they suck at nntp, then push them into here:
_badNntpLocalhost=./bad_nntp
# u (the most common of errors)
# Change the IP address to a bogus one in the config file & you get this error.
# UDPv4 link local: [undef]
# UDPv4 link remote: [AF_INET]1.2.3.4:1234
_badUdpLink=$HOME/doc/cert/bad_udp
# a (the second most common of errors)
# Socket Buffers: R=[87380->131072] S=[16384->131072]
# Attempting to establish TCP connection with [AF_INET]1.2.3.4:1234 [nonblock]
_badAttemptDir=$HOME/doc/cert/bad_attempt
# c (happens if you wait long enough after some attempts)
# Change the hostname to www.google.com and you get this.
# Attempting to establish TCP connection with [AF_INET]1.2.3.4:1234 [nonblock]
# TCP: connect to [AF_INET]1.2.3.4:1234 failed, will try again in 5 seconds: No route to host
_badTcpConnect=$HOME/doc/cert/bad_tcpconnect
# l (very rare TLS initial packet, happens after UDP)
# UDPv4 link local: [undef]
# UDPv4 link remote: [AF_INET]147.47.50.52:1195
# TLS: Initial packet from [AF_INET]147.47.50.52:1195, sid=43600901 812e7825
_badTlsInitialPacket=$HOME/doc/cert/bad_tlsinitialpacket
# r (happens if you get a tls error)
# TLS Error: TLS object -> incoming plaintext read error
# TLS Error: TLS handshake failed
# SIGUSR1[soft,tls-error] received, process restarting
# Restart pause, 2 second(s)
_badRestartPause=$HOME/doc/cert/bad_restart
# s
# SENT CONTROL [s4fpa9jg1yo9tbhk.org]: 'PUSH_REQUEST' (status=1)
# AUTH: Received control message: AUTH_FAILED
# SIGTERM[soft,auth-failure] received, process exiting
_badSigterm=$HOME/doc/cert/bad_sigterm
# d (this is when there are HTML files posing as ovpn files)
# Options error: Unrecognized option or missing parameter(s) in file.ovpn:2: <!DOCTYPE (2.3.2)
_badDoctype=$HOME/doc/cert/bad_doctype
# p (this is a rare push-request failure)
# SENT CONTROL [8ttpjpvu35f6656.jp]: 'PUSH_REQUEST' (status=1)
_badPushRequest=$HOME/doc/cert/bad_pushrequest
kickOrKeep () {
echo ""
echo "$openvpnFileName"
echo ""
echo "WORKING: (good/fast/nntp)"
echo "RARE: (doctype/sigterm/restart)"
echo "ATTEMPT->(tcp)"
echo "UDP ->(tls)"
echo "COMMON: (attempt/udp)"
echo ""
echo "(good,fast,nntp) (pushreq doctype sigterm restart) (attempt-TcP udp-TlS) "
read -p "(g f n ) (p d s r ) (a -> c u -> l ) " answer
case $answer in
[Yy]* )
echo "do nothing..."
;;
[Gg]* )
mkdir -p $LOCAL_GOOD_DIR
echo "mv -i \"$openvpnFileName\" $LOCAL_GOOD_DIR..."
# mv -i "$openvpnFileName" $LOCAL_GOOD_DIR
mv "$openvpnFileName" $LOCAL_GOOD_DIR
;;
[Ff]* )
mkdir -p $LOCAL_FAST_DIR
echo "mv -i \"$openvpnFileName\" $LOCAL_FAST_DIR..."
# mv -i "$openvpnFileName" $LOCAL_FAST_DIR
mv "$openvpnFileName" $LOCAL_FAST_DIR
;;
[Ss]* )
mkdir -p $_badSigterm
echo "mv -i \"$openvpnFileName\" $_badSigterm..."
# mv -i "$openvpnFileName" $_badSigterm
mv "$openvpnFileName" $_badSigterm
;;
[Nn]* )
mkdir -p $_badNntpLocalhost
echo "mv -i \"$openvpnFileName\" $_badNntpLocalhost..."
# mv -i "$openvpnFileName" $_badNntpLocalhost
mv "$openvpnFileName" $_badNntpLocalhost
;;
[Rr]* )
mkdir -p $_badRestartPause
echo "mv -i \"$openvpnFileName\" $_badRestartPause..."
# mv -i "$openvpnFileName" $_badRestartPause
mv "$openvpnFileName" $_badRestartPause
;;
[Uu]* )
mkdir -p $_badUdpLink
echo "mv -i \"$openvpnFileName\" $_badUdpLink..."
# mv -i "$openvpnFileName" $_badUdpLink
mv "$openvpnFileName" $_badUdpLink
;;
[Aa]* )
mkdir -p $_badAttemptDir
echo "mv -i \"$openvpnFileName\" $_badAttemptDir..."
# mv -i "$openvpnFileName" $_badAttemptDir
mv "$openvpnFileName" $_badAttemptDir
;;
[Cc]* )
mkdir -p $_badTcpConnect
echo "mv -i \"$openvpnFileName\" $_badTcpConnect..."
# mv -i "$openvpnFileName" $_badTcpConnect
mv "$openvpnFileName" $_badTcpConnect
;;
[Ll]* )
mkdir -p $_badTlsInitialPacket
echo "mv -i \"$openvpnFileName\" $_badTlsInitialPacket..."
# mv -i "$openvpnFileName" $_badTlsInitialPacket
mv "$openvpnFileName" $_badTlsInitialPacket
;;
[Dd]* )
mkdir -p $_badDoctype
echo "mv -i \"$openvpnFileName\" $_badDoctype..."
# mv -i "$openvpnFileName" $_badDoctype
mv "$openvpnFileName" $_badDoctype
;;
[Pp]* )
mkdir -p $_badPushRequest
echo "mv -i \"$openvpnFileName\" $_badPushRequest..."
# mv -i "$openvpnFileName" "$_badPushRequest"
mv "$openvpnFileName" "$_badPushRequest"
;;
* )
kickOrKeep
;;
esac
}
# If no arguments are provided, then use *.ovpn* as the argument for the next random file.
# If an argument is provided (e.g., US), then use "*that*" as the argument for the next file in order.
if [ $# -eq 0 ]; then
lsFileName=\*.ovpn
else
lsFileName=\*${1}\*
fi
# Use shuffle to randomly choose the next ovpn file:
# If no arguments are provided, then use *.ovpn* as the argument for the next random file.
# If an argument is provided (e.g., US), then use "*that*" as the argument for the next file in order.
if [ $# -eq 0 ]; then
lsFileName=\*.ovpn
else
lsFileName=\*${1}\*
fi
for openvpnFileName in $(ls $lsFileName | shuf ) ; do
echo "The current \$openvpnFileName is $openvpnFileName"
echo "sudo openvpn --config \"$openvpnFileName\" --script-security 2 --up /etc/openvpn/update-resolv-conf --down /etc/openvpn/update-resolv-conf ..."
DATE=$(date)
echo $(pwd)"/"$openvpnFileName > $_vpnPIDtmpFile
sudo openvpn --config "$openvpnFileName" --script-security 2 --up /etc/openvpn/update-resolv-conf --down /etc/openvpn/update-resolv-conf
kickOrKeep
done
#END SCRIPT#
kickOrKeep
done
VPN user
Apr 10, 2016, 7:05:20 PM4/10/16
to
Marek Novotny wrote:
> It's not actually slower to kill the app, it's slower to report killing
> it.
Hi Marek,
> It's not actually slower to kill the app, it's slower to report killing
> it.
Ah, that's interesting. Thank you for the clarification that it's
just slow in reporting, but not slower in killing!
> You should put those apps in the order you want them killed.
That makes sense to put the critical apps earlier.
> Your three apps will be killed in 2 seconds.
Marek Novotny
Apr 10, 2016, 7:21:16 PM4/10/16
to
On 2016-04-10, VPN user <vpn...@example.com> wrote:
> Marek Novotny wrote:
>
>> It's not actually slower to kill the app, it's slower to report killing
>> it.
>
> Hi Marek,
>
> Ah, that's interesting. Thank you for the clarification that it's
> just slow in reporting, but not slower in killing!
>
>> You should put those apps in the order you want them killed.
For the first app. First app is killed. A sleep 1 state takes place and
>
>> It's not actually slower to kill the app, it's slower to report killing
>> it.
>
> Hi Marek,
>
> Ah, that's interesting. Thank you for the clarification that it's
> just slow in reporting, but not slower in killing!
>
>> You should put those apps in the order you want them killed.
then it reports if it was successfully killed. So the second app is
delayed by that slower report.
So the first app is killed instantly. The second app takes a second and
the third takes another second. So three apps will be terminated in 2
seconds.
> Thanks for the tidbit.
> That makes sense to put the critical apps earlier.
>
>> Your three apps will be killed in 2 seconds.
>
> Yup.
William Unruh
Apr 10, 2016, 8:50:16 PM4/10/16
to
On 2016-04-10, VPN user <vpn...@example.com> wrote:
progress from most specific genmask to most general. You AND the address
with the genmask (starting with the one with the most 1 bits in it) and
see if the result matches the destination. If it does use it.
Thus the the 6 addresses, 10.211.1.2 10.211.1.6 39.123.160.54
114.183.199.141 178.163.20.236 220.211.32.220 go directly to their
gateways. Then 192.168.1.x gets dumped onto wlan0 as a local network
Then everything else goes to tun1. The default (genmask 0.0.0.0) never
gets reached since all addresses got sent to tun1 already.
Everything to tun1 gets sent to 10.211.1.6 which by its specific route
gets dumped directly onto tun1.
The only things that get sent to tun0 are stuff which id directly sent
to
10.211.1.2
>
> I guess, if it actually is a tunnel inside a tunnel, that would
> have its uses.
But I guess it depends on how the system impliments tun1.
Bit Twister
Apr 10, 2016, 9:04:00 PM4/10/16
to
On Sun, 10 Apr 2016 16:21:15 -0700, Marek Novotny wrote:
>
> For the first app. First app is killed. A sleep 1 state takes place and
> then it reports if it was successfully killed. So the second app is
> delayed by that slower report.
>
> So the first app is killed instantly. The second app takes a second and
> the third takes another second. So three apps will be terminated in 2
> seconds.
I have not looked at the code, but I would have run through the kill
>
> For the first app. First app is killed. A sleep 1 state takes place and
> then it reports if it was successfully killed. So the second app is
> delayed by that slower report.
>
> So the first app is killed instantly. The second app takes a second and
> the third takes another second. So three apps will be terminated in 2
> seconds.
list soft killing apps, sleep 1, run through it again checking if killed.
Then you get to decide if a hard kill is necessary.
I suggest soft kill for those apps using a database like thunderbird.
Marek Novotny
Apr 10, 2016, 10:50:29 PM4/10/16
to
VPN user
Apr 11, 2016, 3:01:50 AM4/11/16
to
Marek Novotny wrote:
> For the first app. First app is killed. A sleep 1 state takes place and
> then it reports if it was successfully killed. So the second app is
> delayed by that slower report.
>
> So the first app is killed instantly. The second app takes a second and
> the third takes another second. So three apps will be terminated in 2
> seconds.
Thanks for clarifying that the first app is killed instantly, while the
> For the first app. First app is killed. A sleep 1 state takes place and
> then it reports if it was successfully killed. So the second app is
> delayed by that slower report.
>
> So the first app is killed instantly. The second app takes a second and
> the third takes another second. So three apps will be terminated in 2
> seconds.
rest have to await the sleep. I'll probably remove the sleep, but I'll
test first.
I guess I'm spoiled by how the older version worked instantly on all
three apps I had listed, which were transmission, pan, and firefox.
BTW, does it matter if I put them in quotes?
It seems to work either way.
So, I guess the quotes don't matter?
allowed_vpn_apps=(pan firefox transmission) # allowed to run only under vpn
# all will terminate if vpn fails
allowed_vpn_apps=("pan" "firefox" "transmission") # allowed to run only under vpn
# all will terminate if vpn fails
VPN user
Apr 11, 2016, 4:32:28 AM4/11/16
to
> All routing tables are the same, no matter what is involved. You
> progress from most specific genmask to most general. You AND the address
> with the genmask (starting with the one with the most 1 bits in it) and
> see if the result matches the destination. If it does use it.
> Thus the the 6 addresses, 10.211.1.2 10.211.1.6 39.123.160.54
> 114.183.199.141 178.163.20.236 220.211.32.220 go directly to their
> gateways. Then 192.168.1.x gets dumped onto wlan0 as a local network
>
> Then everything else goes to tun1. The default (genmask 0.0.0.0) never
> gets reached since all addresses got sent to tun1 already.
>
> Everything to tun1 gets sent to 10.211.1.6 which by its specific route
> gets dumped directly onto tun1.
>
> The only things that get sent to tun0 are stuff which id directly sent
> to
> 10.211.1.2
Thanks for that explanation as routing tables have always been like
> progress from most specific genmask to most general. You AND the address
> with the genmask (starting with the one with the most 1 bits in it) and
> see if the result matches the destination. If it does use it.
> Thus the the 6 addresses, 10.211.1.2 10.211.1.6 39.123.160.54
> 114.183.199.141 178.163.20.236 220.211.32.220 go directly to their
> gateways. Then 192.168.1.x gets dumped onto wlan0 as a local network
>
> Then everything else goes to tun1. The default (genmask 0.0.0.0) never
> gets reached since all addresses got sent to tun1 already.
>
> Everything to tun1 gets sent to 10.211.1.6 which by its specific route
> gets dumped directly onto tun1.
>
> The only things that get sent to tun0 are stuff which id directly sent
> to
> 10.211.1.2
rocket science to me. Whenever I look up how routing tables work,
the online descriptions never look anything like what I consistenly
see when connect to a public VPN server.
So, it has always been a mystery for me to figure out what a
openvpn-set-up routing table is trying to tell me.
Luckily, all the routing tables I've seen under my openvpn setup are
consistently using only 4 different Genmasks, specifically, they all
use either 255.255.255.255 or 255.255.255.0 or 128.0.0.0 or 0.0.0.0.
Likewise, there are only 3 gateways to figure out, which are always
either 0.0.0.0 or 192.168.1.1 or 10.211.1.something.
Normally, when not on VPN, my routing table is always these two lines:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
The first line I inherently know basically says to send everything destined
for the local network (i.e., 192.168.1.x) over wlan0 to the Gateway of 0.0.0.0
which means to send the packets directly to the WiFi card.
The secondline inherently says send everything destined for the Internet
over wlan0 through the Gateway 192.168.1.1, which is the router.
However, when I go on VPN, invariably four strange lines get added:
$ sudo openvpn --config vpngate_JP_114.183.199.141.ovpn
Destination Gateway Genmask Flags Metric Ref Use Iface
114.183.199.141 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
10.211.1.38 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.211.1.38 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 10.211.1.38 128.0.0.0 UG 0 0 0 tun0
If I follow your stated logic, when on VPN, I should order the 6 lines as
shown below, primarily with the Genmasks with the most number of 1s,
and then perhaps secondarily with the Destinations with the most number
of 1s?
Destination Gateway Genmask Flags Metric Ref Use Iface
114.183.199.141 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
10.211.1.38 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 10.211.1.38 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.211.1.38 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
In attempting to follow your reasoning, I've ordered the 6 lines above
from most specific Genmask to most general Genmask, and from most specific
Destination to most general Destination.
Is this correct?
Scenario 1:
$ ping -c1 114.183.199.141
I first *AND* the desired IP address of 114.183.199.141 with the
most specific (i.e., most 1s) Genmask of 255.255.255.255 where I get,
as a result, 114.183.199.141. I look to see if that result matches
the Destination, which it does, so the packets get sent over the
wlan0 card to the Gateway of 192.168.1.1, which is the home router.
Scenario 2:
$ ping -c1 10.211.1.38
I *AND* the desired address of 10.211.1.38 with the most specific
single-host Genmask of 255.255.255.255, which results in 10.211.1.38,
which does NOT match the Destination in the first line, but which does
match the Destination in the second line, so the packets are sent over
tun0 to the Gateway of 0.0.0.0 which is a direct route to 10.211.1.38
which, I guess, is an internal IP address on the VPN server's network?
Scenario 3:
$ ping -c1 8.8.8.8
I *AND* the desired address of 8.8.8.8 with the most specific
single-host Genmask of 255.255.255.255, which results in 8.8.8.8,
which does NOT match the Destination in the first line. It does
not match the Destination in the second line either. Nor does
it match the Destination in the third line.
The fourth and fifth lines seem to be the first and second half of
the Internet respectively:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.211.1.38 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 10.211.1.38 128.0.0.0 UG 0 0 0 tun0
Where the 4th line 0.0.0.0 Destination and 128.0.0.0 Genmask handles the
first half of the Internet from 0.0.0.0 to 127.255.255.254 and where the
5th line of Destination 128.0.0.0 and 128.0.0.0 Genmask handles the 2nd
half of the Internet from 128.0.0.0 to 255.255.255.255.
So, the ping of 8.8.8.8 is handled by the fourth line, which sends the
packets over the tun0 to the Gateway of 10.211.1.38, which presumably
is an internal address on the VPN server network?
Scenario 4:
$ ping -c1 google.com (aka 172.217.0.78)
This Google IP address is on the second half of the Internet, so, it's
handled by the 5th line of Destination 128.0.0.0 and Genmask 128.0.0.0,
so the packet gets handed to the tun0 heading toward the Gateway of
10.211.1.38, which is presumably on the local network of the VPN server?
Scenario 5:
$ ping -c1 192.168.1.10
This desired IP address tickles the 3rd line where the Gateway of
255.255.255.0 applies, which sends all internal network traffic
of 192.168.1.x over the wlan0 to the Gateway of 0.0.0.0 which is
a direct route to the wlan0 broadcast channel.
Scenario 6:
The last line (i.e., the default route) never gets reached, where the
Genmask is 0.0.0.0 and the Destination is 0.0.0.0, so that means any
IP address whatsoever would be sent over wlan0 to the Gateway of
192.168.1.1 which is the home router.
It never gets reached because there are no packets left, since everything
has been taken care of in the first 5 of the 6 lines.
Is any of what I wrote correct?
Is some of it wrong?
What would you change in the description above to clarify what goes
on in this VPN scenario?
Marek Novotny
Apr 11, 2016, 9:56:54 AM4/11/16
to
to preserve white spaces. In this case, we don't. So no quotes are
needed. Just use spaces between each one and you're good.
VPN user
Apr 11, 2016, 11:55:48 AM4/11/16
to
Marek Novotny wrote:
> You do not need quotes. The reason you see quotes is sometimes you need
> to preserve white spaces. In this case, we don't. So no quotes are
> needed. Just use spaces between each one and you're good.
Thanks for clarifying.
> You do not need quotes. The reason you see quotes is sometimes you need
> to preserve white spaces. In this case, we don't. So no quotes are
> needed. Just use spaces between each one and you're good.
Sometimes the punctuation matters, and sometimes it doesn't.
It would be rare to find an executable or script that has spaces in
the name I guess.
Marek Novotny
Apr 11, 2016, 12:12:39 PM4/11/16
to
On 2016-04-11, VPN user <vpn...@example.com> wrote:
reserve the period for an extension that I want to use to help describe
what the file type is, like .c for a c code or .sh for a shell script.
You could use spaces and escape the spaces such as:
$ mv file\ name file_name or $ mv "file name" file_name
TOSEM
Apr 12, 2016, 11:03:48 AM4/12/16
to
Marek Novotny <marek....@marspolar.com> wrote;
>> It would be rare to find an executable or script that has spaces in
>> the name I guess.
>
/rolls eyes
>You could do it, but yeah I would advise //against// it.
Respects Marek (extended) in your efforts to patch a script <VPN user>
struggles with. It is understood and appreciated you would work to preserve
your work , in good faith.
However.. <VPN user> is stretching the tutorial to hopefully harvest code
able to be used beyond your intention. And NOT in a kind way (Usenet).
"He who brings sand hoping for gold" applies in respect of your 'student'.
Well known throughout Usenet.
http://news.software.readers.narkive.com/IimwnE9N/seamus-is-roy-schestowitz-notorious-linux-advocacy-troll
Language orientated..(?).. it is possible yourself and I are on separate
Planets.
Whatever.. I provide this link to my summary of recent activity in <a.o.l>
from <VPN user> as relative to why the poster seeks your assistance.
{-----
From: TOSEM
<7he0ther5ide0f3...@derbyshire.kooks.out.example.invalid>
Newsgroups: alt.free.newsservers
Subject: 0bervation [was] Who owns Free News Servers
Date: Mon, 11 Apr 2016 22:29:52 +1000
Message-ID: <neg5br$46l$4...@news.albasani.net>
-----}
I trust you get the message.
cheerio...
>On 2016-04-11, VPN user <vpn...@example.com> wrote:
>> Marek Novotny wrote:
>>
>>> You do not need quotes. The reason you see quotes is sometimes you need
>>> to preserve white spaces. In this case, we don't. So no quotes are
>>> needed. Just use spaces between each one and you're good.
>>
>> Thanks for clarifying.
>> Sometimes the punctuation matters, and sometimes it doesn't.
>>
.. most definitely , Paul.
>> Marek Novotny wrote:
>>
>>> You do not need quotes. The reason you see quotes is sometimes you need
>>> to preserve white spaces. In this case, we don't. So no quotes are
>>> needed. Just use spaces between each one and you're good.
>>
>> Thanks for clarifying.
>> Sometimes the punctuation matters, and sometimes it doesn't.
>>
>> It would be rare to find an executable or script that has spaces in
>> the name I guess.
>
>You could do it, but yeah I would advise //against// it.
Respects Marek (extended) in your efforts to patch a script <VPN user>
struggles with. It is understood and appreciated you would work to preserve
your work , in good faith.
However.. <VPN user> is stretching the tutorial to hopefully harvest code
able to be used beyond your intention. And NOT in a kind way (Usenet).
"He who brings sand hoping for gold" applies in respect of your 'student'.
Well known throughout Usenet.
http://news.software.readers.narkive.com/IimwnE9N/seamus-is-roy-schestowitz-notorious-linux-advocacy-troll
Language orientated..(?).. it is possible yourself and I are on separate
Planets.
Whatever.. I provide this link to my summary of recent activity in <a.o.l>
from <VPN user> as relative to why the poster seeks your assistance.
{-----
From: TOSEM
<7he0ther5ide0f3...@derbyshire.kooks.out.example.invalid>
Newsgroups: alt.free.newsservers
Subject: 0bervation [was] Who owns Free News Servers
Date: Mon, 11 Apr 2016 22:29:52 +1000
Message-ID: <neg5br$46l$4...@news.albasani.net>
-----}
I trust you get the message.
cheerio...
VPN user
Apr 12, 2016, 11:31:50 AM4/12/16
to
Oh geez.
The stink is following us from alt.free.newsservers.
Marek, BitTwister, William Unruh, etc., please be advised that TOSEM
is a bona-fide kook, who is intent in destroying any thread where he
sees any interest in by normal people.
Be advised, that the Mark Twain aphorism applies of "never argue with
an idiot" because this particular crazy is prolific.
As such, I will put this entire thread on ignore so that I won't
even *see* anything he posts, as I am quite aware of the power of
little babies to destroy things, and once TOSEM has latched onto
a thread, he *will* destroy it.
I had him in my plonked for other newsgropus, as my killfiles are
ng specific, but it looks like the stink is following.
I will not respond further to anything in this thread as I won't
even see it after this post.
The stink is following us from alt.free.newsservers.
Marek, BitTwister, William Unruh, etc., please be advised that TOSEM
is a bona-fide kook, who is intent in destroying any thread where he
sees any interest in by normal people.
Be advised, that the Mark Twain aphorism applies of "never argue with
an idiot" because this particular crazy is prolific.
As such, I will put this entire thread on ignore so that I won't
even *see* anything he posts, as I am quite aware of the power of
little babies to destroy things, and once TOSEM has latched onto
a thread, he *will* destroy it.
I had him in my plonked for other newsgropus, as my killfiles are
ng specific, but it looks like the stink is following.
I will not respond further to anything in this thread as I won't
even see it after this post.
0 new messages