ISP Snooping — 4
I am looking at ways to avoid ISP snooping.
In my first step learning to use a virtual private network (VPN) I decided to start with a free ProtonVPN account. The account is truly free with no monetary cost, speed throttling, or monthly caps.
For Linux users the ProtonVPN is accessed through the command line.
With free accounts the options are limited to a short list of free servers. In North America there are basically five “nodes” for the free servers. The free servers may be accessed using a specific server ID (node) or using the “fastest” servers.
The term “fastest” is relative to the ProtonVPN service rather than the customer. The “fastest” designation means a server that has the most available throughput with respect to the overall ProtonVPN service. Fastest means the ability to best manage overall ProtonVPN bandwidth.
Being free the servers are almost always pushing full capacity. My initial efforts using the “fast” method often resulted in connection failures. Connecting by explicitly using one of the “nodes” was nominally better but often resulted in the same failed connection effort.
Eventually I always connected.
I quickly learned that certain known VPN IP addresses are blocked at many web sites. Likely free VPNs are abused by people with less than acceptable intentions. The blockage affected my connection to a considerable degree depending on which free IP address I connected. When connected to these problematic VPN IP addresses I could not access some of my email accounts and several web sites I commonly visit.
The ProtonVPN service does not provide split tunneling to Linux users. That means to access my bank account I need to disable the VPN or use a different computer not connected to the VPN. With respect to a snoopy ISP that is not the end of the world because I pay them through that bank account.
Some of the IP addresses were slow. I did not enjoy using those IP addresses.
I configured iptables rules to reject outgoing connections to some of those addresses. This strategy worked fine while conversely increasing the number of failed connection attempts. Yet eventually I always connected. This approach did help reduce the frustrations.
ProtonVPN prevents DNS leakage by temporarily modifying the system /etc/resolv.conf and /etc/dnsmasq.conf files. For many years I have used dnsmasq to block advertising and malicious IP addresses. My first sessions with ProtonVPN revealed to me how the dnsmasq.conf file was being modified because I saw an obvious increase in advertising.
The ProtonVPN scripts temporarily replace the existing dnsmasq.conf by commenting out all entries except the entry for a single ProtonVPN DNS server. With respect to DNS leaking that approach makes sense, but the global commenting disables all addn-hosts options too. Those configuration options is how I manage domain name blocking to block advertisements and malicious sites.
I noticed that sometimes when I disconnected that my config files were not being restored to the original copies.
My solution to these glitches was to write a shell script wrapper to ensure I was connecting the way I wanted and my config files were restored correctly. I also modified my rc.local* scripts to ensure those files were restored. As I am inexperienced using VPNs and unfamiliar with the design of the underlying ProtonVPN scripts, I needed a few weeks of trial-and-error testing to fine tune everything.
Using a VPN seemed to satisfy my desire to avoid a snoopy ISP. I was already aware of certain challenges. I wanted to ensure I did not inadvertently access my email, RSS feeds, or blog unless I was connected to a VPN.
I wrote some more shell script wrappers. The scripts check the internet connection. The affected software is allowed to launch when connected to a VPN. Otherwise a popup notification appears reminding the user to connect to a VPN. This is nominally inconvenient, but the notable advantage is not letting a snoopy ISP learn of my association with any related URLs. Likely this also would help should I travel with the laptop.
Using the addn-hosts option I created new dnsmasq hosts site files for the way I access these personally identifiable web sites and URLs. When not connected to a VPN the IP address for those related sites is 127.0.0.1. When connected to the VPN the IP address is the correct online address.
When using the VPN I might suffer up to about a 17% drop in my connection speed. Reading around the web indicates this is normal and expected. Being rural I only have single digit ISP speeds to begin with, which means a normal 8.5 Mbps down drops to about 7 Mbps with the VPN. Interestingly, upload speeds are about the same at about 4 Mbps.
I am forgiving about the free server blockage and capacity loads. I won’t complain about that. Free means not being picky. At least the ProtonVPN free access truly allows a person to learn about using the service.
Eventually I plan to pay for the service. In that respect I tuned my shell scripts such that I should be able to switch to paid servers and hopefully not skip a beat.
I probably should test other VPN services. An additional VPN provider could provide a Backup Plan B as well as further obfuscating my connections. At least now with ProtonVPN I am learning and am aware of likely challenges and pitfalls of using a VPN service. I also now have a reasonable foundation with my shell scripts to add new VPN services.
Posted: Category: Usability Tagged: General
Next: Updating Slackware — 5
Previous: Updating Slackware — 4