Jump to content
Not connected, Your IP: 18.191.27.78
Staff

Linux: AirVPN Suite 1.0.0 released

Recommended Posts

Posted ... (edited)

@Staff thanks for the help. The installation went well and systemd is reporting that bluetit is running.

I'm not sure if this is intentional, but the airvpn user is making a home folder. The home folder is more or less empty, can safely I change this user to have no login, no home folder?

Edited ... by suroh

Share this post


Link to post
@suroh

Hello!

We're glad to know that the quick fix resolved the issue.
 
Quote

I'm not sure if this is intentional, but the airvpn user is making a home folder. The home folder is more or less empty, can safely I change this user to have no login, no home folder?


Yes, it's intentional, as it is a more flexible and secure solution allowing exclusive aivpn user setup, place for its files etc., log into its own session to run Goldcrest or any other Bluetit client.

Sure, you can do as you prefer, or you can even add your own user to the airvpn group, according to your security needs and preferences, but consider seriously not to run Goldcrest with root privileges and not to add airvpn user to the sudo-ers. By doing the above, you would jeopardize a portion of the security model offered by the client-daemon architecture.

Kind regards
 

Share this post


Link to post

Anyone else having instability of connection with bluetit?
 

Jan 22 23:09:01 osmc bluetit[7060]: Updating AirVPN Manifest
Jan 22 23:09:03 osmc bluetit[7060]: AirVPN Manifest successfully retrieved from server
Jan 22 23:18:13 osmc bluetit[7060]: Tunnel Options:V4,dev-type tun,link-mtu 1524,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client
Jan 22 23:18:13 osmc bluetit[7060]: Peer Info:
Jan 22 23:18:13 osmc bluetit[7060]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RSA-SHA1
Jan 22 23:18:13 osmc bluetit[7060]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Alwaid/emailAddress=info@airvpn.org, signature: RSA-SHA512
Jan 22 23:18:13 osmc bluetit[7060]: SSL Handshake: peer certificate: CN=Alwaid, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
Jan 22 23:18:13 osmc bluetit[7060]: LZO-ASYM init swap=0 asym=1
Jan 22 23:18:13 osmc bluetit[7060]: Comp-stub init swap=0
Jan 22 23:24:03 osmc bluetit[7060]: Updating AirVPN Manifest
Jan 22 23:24:07 osmc bluetit[7060]: AirVPN Manifest successfully retrieved from server
Jan 22 23:30:06 osmc connmand[277]: (null) {RX} 1822320 packets 2098696279 bytes
Jan 22 23:30:06 osmc connmand[277]: (null) {TX} 1351799 packets 121248981 bytes
Jan 22 23:30:06 osmc connmand[277]: (null) {update} flags 4240 <DOWN>
Jan 22 23:30:06 osmc connmand[277]: tun0 {newlink} index 3 address 00:00:00:00:00:00 mtu 1500
Jan 22 23:30:06 osmc connmand[277]: tun0 {newlink} index 3 operstate 2 <DOWN>
Jan 22 23:30:06 osmc connmand[277]: (null) {del} route fe80:: gw :: scope 0 <UNIVERSE>
Jan 22 23:30:06 osmc connmand[277]: (null) {del} address 10.8.135.23/24 label tun0
Jan 22 23:30:06 osmc connmand[277]: tun0 {dellink} index 3 operstate 2 <DOWN>
Jan 22 23:30:06 osmc connmand[277]: (null) {RX} 1822320 packets 2098696279 bytes
Jan 22 23:30:06 osmc connmand[277]: (null) {TX} 1351799 packets 121248981 bytes
Jan 22 23:30:06 osmc connmand[277]: (null) {remove} index 3
Jan 22 23:30:06 osmc systemd[1]: bluetit.service: Main process exited, code=killed, status=6/ABRT
-- An ExecStart= process belonging to unit bluetit.service has exited.
Jan 22 23:30:06 osmc systemd[1]: bluetit.service: Failed with result 'signal'.
-- The unit bluetit.service has entered the 'failed' state with result 'signal'.

Share this post


Link to post

For the time being, I am going to stop testing this and go back to a hummingbird solution as suggested by @Staff earlier.  For purposes of an always-on from boot-to-shutdown service, I just need something simple to set and maintain the tunnel, dns-switch, and firewall.

I like where you are going with bluetit and its clients, but I will wait for the next release before testing further.

Thanks,

 

Share this post


Link to post
@airvpnclient

Yes, every OSMC user must wait for Bluetit next version in any case. Bluetit 1.0.0 does not run properly in OSMC because of OSMC customization. Next Bluetit release will aim at full OSMC compatibility.

Kind regards
 

Share this post


Link to post

Thanks @Staff

I may be onto something for OSMC.  Found and followed these instructions and got eddie-ui cli working (it was not):

There is no dns forwarder enabled by default in OSMC

$ sudo apt-get install -y dnsmasq
$ sudo nano/etc/dnsmasq.conf

# uncomment the settings of “domain-needed” and “bogus-priv”

$ systemctl enable dnsmasq
$ systemctl start  dnsmasq

Share this post


Link to post
15 hours ago, airvpnclient said:

Thanks @Staff

I may be onto something for OSMC.  Found and followed these instructions and got eddie-ui cli working (it was not):

There is no dns forwarder enabled by default in OSMC


$ sudo apt-get install -y dnsmasq
$ sudo nano/etc/dnsmasq.conf

# uncomment the settings of “domain-needed” and “bogus-priv”

$ systemctl enable dnsmasq
$ systemctl start  dnsmasq
 Nah the tunnel comes up but -- times out with a bluetit abort signal at some interval.  May put a watchdog script on it and just keep resetting it when it fails.

Share this post


Link to post

Still working on getting a secured Kodi box that is netlocked using software from the AirVPN Suite.  I have, for the moment given up on OSMC and am working on an Xbian (highly custom Debian Buster distro).

I am able to run the hummingbird application and it works great, but when/if hummingbird fails, the host goes back to default iptables rules and is effectively wide open so I can't count on it to lock the host to the AirVPN network like Eddie does on my desktop.

What does hummingbird do with respect to network locking by default?

Currently when I run hummingbird on the rpi the following iptables (and ip6tables which I haven't quoted) rules are set:

# /usr/sbin/ip6tables-legacy -L

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all      anywhere             anywhere            
REJECT     all      localhost            anywhere             reject-with icmp6-port-unreachable
DROP       all      anywhere             anywhere             rt type:0
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp router-advertisement HL match HL == 255
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp neighbour-solicitation HL match HL == 255
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp neighbour-advertisement HL match HL == 255
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp redirect HL match HL == 255
ACCEPT     all      fe80::/10            anywhere            
ACCEPT     all      anywhere             ip6-mcastprefix/8   
ACCEPT     all      anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all      anywhere             anywhere            
DROP       all      anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DROP       all      anywhere             anywhere             rt type:0
ACCEPT     all      anywhere             anywhere            
DROP       all      anywhere             anywhere            

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all      anywhere             fde6:7a:7d20:5e5::1 
ACCEPT     all      anywhere             anywhere            
DROP       all      anywhere             anywhere             rt type:0
ACCEPT     all      fe80::/10            anywhere            
ACCEPT     all      anywhere             ip6-mcastprefix/8   
ACCEPT     all      anywhere             anywhere            
ACCEPT     all      anywhere             anywhere             state ESTABLISHED
DROP       all      anywhere             anywhere
But when I run Eddie on my desktop, I get a very different set of rules using the network lock:
# /usr/sbin/iptables-legacy -L 
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  255.255.255.255      anywhere            
ACCEPT     all  --  192.168.0.0/16       192.168.0.0/16      
ACCEPT     all  --  10.0.0.0/8           10.0.0.0/8          
ACCEPT     all  --  172.16.0.0/12        172.16.0.0/12       
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             255.255.255.255     
ACCEPT     all  --  192.168.0.0/16       192.168.0.0/16      
ACCEPT     all  --  10.0.0.0/8           10.0.0.0/8          
ACCEPT     all  --  172.16.0.0/12        172.16.0.0/12       
ACCEPT     all  --  192.168.0.0/16       base-address.mcast.net/24 
ACCEPT     all  --  10.0.0.0/8           base-address.mcast.net/24 
ACCEPT     all  --  172.16.0.0/12        base-address.mcast.net/24 
ACCEPT     all  --  192.168.0.0/16       239.255.255.250     
ACCEPT     all  --  10.0.0.0/8           239.255.255.250     
ACCEPT     all  --  172.16.0.0/12        239.255.255.250     
ACCEPT     all  --  192.168.0.0/16       239.255.255.253     
ACCEPT     all  --  10.0.0.0/8           239.255.255.253     
ACCEPT     all  --  172.16.0.0/12        239.255.255.253     
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             ec2-63-33-78-166.eu-west-1.compute.amazonaws.com 
ACCEPT     all  --  anywhere             ec2-52-48-66-85.eu-west-1.compute.amazonaws.com 
ACCEPT     all  --  anywhere             ec2-54-93-175-114.eu-central-1.compute.amazonaws.com 
ACCEPT     all  --  anywhere             ec2-63-33-116-50.eu-west-1.compute.amazonaws.com 
ACCEPT     all  --  anywhere             106.19.9.185.in-addr.arpa 
ACCEPT     all  --  anywhere             108.19.9.185.in-addr.arpa 
ACCEPT     all  --  anywhere             109.19.9.185.in-addr.arpa 
ACCEPT     all  --  anywhere             110.19.9.185.in-addr.arpa 
ACCEPT     all  --  anywhere             37.120.155.178      
ACCEPT     all  --  anywhere             37.120.155.180      
ACCEPT     all  --  anywhere             37.120.155.181      
ACCEPT     all  --  anywhere             37.120.155.182      
ACCEPT     all  --  anywhere             194.127.64.217.in-addr.arpa 
ACCEPT     all  --  anywhere             196.127.64.217.in-addr.arpa 
ACCEPT     all  --  anywhere             197.127.64.217.in-addr.arpa 
ACCEPT     all  --  anywhere             198.127.64.217.in-addr.arpa 
ACCEPT     all  --  anywhere             90.251.187.194.in-addr.arpa 
ACCEPT     all  --  anywhere             92.251.187.194.in-addr.arpa 
ACCEPT     all  --  anywhere             93.251.187.194.in-addr.arpa 
...
...
and many more lines like this.
I am not good at parsing these rulesets, but it seems to me that the hummingbird application rule set is not as extensive, and in any case they do not persist when the app stops.

I am thinking of scripting something kludgy like this to run in rc.local and somehow trigger loading them again if the tunnel drops.
#!/bin/bash
/usr/sbin/hummingbird &
/usr/sbin/iptables-legacy-restore < /etc/airvpn/airvpn.tables && /usr/sbin/ip6tables-restore </etc/airvpn/airvpn.6tables 
using my saved rules from an eddie desktop session with netlock on.

Am I missing something?

Thanks again!
 

Share this post


Link to post

Eureka!

Eddie-cli up and running with netlock on Xbian Buster with the same iptables setting as Eddie on my desktop.

Looking forward to the OSMC friendly release and until then, I will stop bugging you guys.

Though I note that when I kill Eddie, it kills the netlock which is not my preferred result.

Great software.  Thanks again.

Share this post


Link to post
@airvpnclient

Hello!

Hummingbird sets the necessary rules only (maximum optimization), while Eddie opens traffic to every AirVPN node IPv4 address, therefore it needs some thousand rules.

Hummingbird is designed in a way that when a disconnection takes place, Network Lock gets disabled, while Eddie keeps Network Lock until you explicitly tell it to disable Network Lock or exit. Therefore Hummingbird is not a suitable software if you need Network Lock while disconnected, but you can consider a "permanent" Network Lock with proper rules by default, so that traffic is blocked when Hummingbird restores default rules.

Bluetit will have a safer behavior, more similar to Eddie's behavior, but you need to remember (as you noticed) that currently Bluetit will not activate Network Lock if an account login fails. We are working to fix this flaw as well, and quickly, in the next imminent release already.

Kind regards
 

Share this post


Link to post

Anyone know of a tutorial or video demonstration/guide for the Airvpn Suite.
I would be gratfull for any as i am more of a visual learner.
thanks

Share this post


Link to post

I have successfully installed the new Bluetit software on my Pi download box but it doesn't appear to be very stable although the last run was 22 hours.

I'm not seeing anything significant in syslog except for:

pi@pidown:~ $ sudo service bluetit status
● bluetit.service - AirVPN Bluetit Daemon
   Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: enabled)
   Active: failed (Result: signal) since Thu 2021-02-04 09:09:00 GMT; 29min ago
 Main PID: 8552 (code=killed, signal=ABRT)

Feb 04 08:50:42 pidown bluetit[8552]: Peer Info:
                                      IV_VER=3.6.6 AirVPN
                                      IV_PLAT=linux
                                      IV_NCP=2
                                      IV_TCPNL=1
                                      IV_PROTO=30
                                      IV_CIPHERS=AES-256-GCM
                                      IV_LZO_STUB=1
                                      IV_COMP_STUB=1
                                      IV_COMP_STUBv2=1
                                      UV_IPV6=no
                                      IV_GUI_VER=Bluetit - AirVPN OpenVPN 3 Service 1.0.0
                                      IV_SSL=OpenSSL 1.1.1d  10 Sep 2019
Feb 04 08:50:42 pidown bluetit[8552]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RSA-SHA1
Feb 04 08:50:42 pidown bluetit[8552]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Atik/emailAddress=info@airvpn.org, signature: RSA-SHA512
Feb 04 08:50:42 pidown bluetit[8552]: SSL Handshake: peer certificate: CN=Atik, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
Feb 04 08:50:42 pidown bluetit[8552]: LZO-ASYM init swap=0 asym=1
Feb 04 08:50:42 pidown bluetit[8552]: Comp-stub init swap=0
Feb 04 08:58:28 pidown bluetit[8552]: Updating AirVPN Manifest
Feb 04 08:58:40 pidown bluetit[8552]: AirVPN Manifest successfully retrieved from server
Feb 04 09:09:00 pidown systemd[1]: bluetit.service: Main process exited, code=killed, status=6/ABRT
Feb 04 09:09:00 pidown systemd[1]: bluetit.service: Failed with result 'signal'.
 


Because Bluetit dies I have to run the --recover-network option before it will successfully reconnect.

bluetit.rc is using all default values apart from username, password and airconnectonboot (which is set to quick).

Bluetit Version

Feb  4 09:44:34 pidown bluetit: Starting Bluetit - AirVPN OpenVPN 3 Service 1.0.0 - 7 January 2021
Feb  4 09:44:34 pidown bluetit: OpenVPN core 3.6.6 AirVPN linux arm 32-bit
 


Other Info

Raspberry Pi 4 Model B Rev 1.2
Linux version 5.4.83-v7l+ (dom@buildbot) (gcc version 8.4.0 (Ubuntu/Linaro 8.4.0-3ubuntu1)) #1379 SMP Mon Dec 14 13:11:54 GMT 2020


Happy to supply any other logs/info.

D

Share this post


Link to post

Just checking some more stuff.

I see that the physical interface eth0 is set to Speed: 1000Mb/s but tun0 is set to Speed: 10Mb/s.

D

 

Share this post


Link to post
18 hours ago, Staff said:
@dL4l7dY6

Hello!

What is the operating system running in your Pi device?

Kind regards
 

pi@pidown:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian

32bit,

Share this post


Link to post

I installed AirVPN-Suite-x86_64-1.0.0.tar.gz on CentOS Stream using the install script and creating group airvpn.  It installed fine, but I noticed a couple of things:

1. Dir /etc/airvpn was created as 660 - root:root
   I changed it to 750 - root:airvpn
2. /usr/local/bin/goldcrest was installed as 700 root:root
   I changed it to 750 - root:airvpn

After I made the changes above no issues and all seems fine

A couple of times, /etc/airvpn/bluetit.lock was not removed when I issued a
'sudo systemctl stop bluetit.service'
but I was moving quickly trying to adjust permissions and config files after the install, so I cannot say for sure if it was me or not.  I will keep an eye on that.

Thanks for a nice work
 

Share this post


Link to post
@frpergflf

Hello!

Allowing access to those directories to group "airvpn" is a choice of each superuser. For security reasons, by default the installer sets them belonging to root user and root or wheel group to comply to the best security practices consolidated in UNIX in the last 30 years. In general, as an optimal security solution, we want that Bluetit files can be edited only by root and sudo-ers, while Goldcrest files (but not Goldcrest binary) can be changed only by users belonging to airvpn group.

The lock file removal failure after Bluetit clean stop order by systemd is unexpected. When the problem re-occurs, would you be so kind to send us Bluetit log?
sudo journalctl | grep bluetit


@asdfasdfasdfasdfasdf

No, it is not. If you proceed to implement, don't forget that Bluetit is a daemon.

@dL4l7dY6
@airvpnclient

A source of Bluetit instability in OSMC and Raspbian 32 bit has been detected, and it's libcurl . The linked library explodes now and then. The problem has been resolved with specific libcurl linking. Development is now focused on a new Network Lock approach, to make the whole environment more secure especially during a system bootstrap. Once it is implemented (a matter of just a few days) we will be ready for testing and soon after a new release will follow, perfectly compatible with OSMC too.

Kind regards
 

Share this post


Link to post
On 2/6/2021 at 5:13 AM, Staff said:
@frpergflf

The lock file removal failure after Bluetit clean stop order by systemd is unexpected. When the problem re-occurs, would you be so kind to send us Bluetit log?

sudo journalctl | grep bluetit
Hi,
Today I started and stopped bluetit using systemctl to see if I can get the issue to occur.  A couple of times it was unable to remove the lock file.  Attached is the log you requested.  I also executed 'sealert -l 38fc85ca-5938-44e9-b44b-03d4bcf794eb' output per the log and I attached that file also. 

Thanks
 

 

bluetit-issue.txt selinux.txt

Share this post


Link to post
@frpergflf

Thank you, the log entry showing a crash problem "Process 133092 (bluetit) of user 0 dumped core." and its previous and following entries seem very relevant. The problem will be soon under investigation.

Kind regards
 

Share this post


Link to post
@frpergflf

Hello!

SELinux correctly prevents systemd to delete the lock file. That's an illegal operation that systemd wants to perform and that tells something on how systemd is designed.

Bleutit crash is caused by the fact that systemd bombards with SIGTERM
Bluetit (and in general any real daemon). Under specific circumstances, i.e. when 2 or more SIGTERM signals are sent to Blueit almost simultaneously, Bluetit crashes, because the promise object has been already depleted when the 2nd or nth SIGTERM is received. Again, this incomprehensible behavior tells something about how systemd is designed, but at least it made us find a bug which might cause crashes in any other similar circumstance (imagine if you manage to send SIGTERM from two "kill" commands synced to be executed almost simultaneously).

Fix will be of course implemented in the next, imminent version.

Kind regards
 

Share this post


Link to post

Having set up the bluetit service to connect on boot, is there a recommended approach for After in systemd to launch a dependent service only once the VPN is connected? I tried After=sys-devices-virtual-net-tun0.device (and BindsTo) with less than stellar results. Thanks for the absolutely awesome tools! (and thank you for the Raspbian fixes, looking forward to that).

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...