How to build your own VPN if you're wary of commercial options | Hacker News Reader

How to build your own VPN if you're wary of commercial options

arstechnica.com

265 pointssgeller108 comments

The problem with a home-grown VPN is that you lose some of the plausible deniability that's gained from a shared VPN. If you have a VPN connected to a privately-owned AWS instance, the IP coming from that AWS instance is easily traced back to you. Whereas if your external IP is coming from a cluster that is shared by thousands of other people using that VPN, it is more difficult for someone to tie that specifically back to you.

> AWS instance is easily traced back to you.

Define "easily" as used in this context. Easy is a product of whom your enemy is.

Is your enemy your ISP? If that's the case, I don't think it's "easy" for them; they would have to pay Digital Ocean or Amazon to get your data, and probably isn't really that valuable to them.

Is your enemy the MPAA? If that's the case, I still don't think it's particularly "easy" for them. Unless you are a MAJOR pirate distributor, the extra effort(money) to track you down isn't worth it.

Is your enemy the NSA or the FBI? If that's the case, then yes, it's trivially easy for them to Subpoena digital ocean or amazon to get your data, but similarly they can use techniques on PIA to get your data too.

In the end, it comes down to whom you trust with your data. And whether you want a managed VPN service, or are willing to put up with the inherent problems of maintaining your own system. will PIA sell your surfing habits to advertisers, will DO sell your surfing habits to advertisers? Who gives faster speeds?

I agree overall, but PIA has may not be the best example, as they have been shown to not keep any data that could be subpoenaed[1]. One nice thing about running your own (if your client machine is on Linux) is being able to use Wireguard[2], which is quite a bit faster than OpenVPN, for example.

1: https://torrentfreak.com/vpn-providers-no-logging-claims-tes...

2: https://www.wireguard.io/performance/

Never heard of Wireguard before, but it looks really cool, especially the mosh-like roaming. However, I found this warning on their website.

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.

its also versioned with a double zero: v0.0.20170517 and the repositories are marked unstable.

also, the protocol itself is still considered 'version 0' with lots of possible changes on their website.

looking forward to it maturing though.

Also worth checking out Shadowsocks, which was originally created to circumvent the GFW:

https://shadowsocks.org/en/index.html

https://en.wikipedia.org/wiki/Shadowsocks

The MPAA will serve an automated DMCA notice to your VPS provider, who will terminate your account at the very least.

Amazon's not in the business of terminating accounts the second a copyright request comes in. They want to build trust with their customers that they won't just turn you off on a whim.

I can vouch for this, from the other side. We routinely catch AWS hosts running password-guessing bots against our login forms. Emailing abuse@amazonaws.com doesn't seem to lead to reductions in our fail2ban and custom tarpit logs.

Claiming someone is brute forcing your logins doesn't have the legal weight of a DMCA notice. Why should they do anything? DMCA provides provisions for counter notice and legal remedies for false filings.

Is it the same hosts?

Having worked web security -

This is always a battle - for big operations you've got people farming out signups using stolen data to random 'buddies' on the other side of the world with the dark hat team ready to stand up outbounding traffic as fast as they can get a processor to execute it on, not to mention the hosts that get cracked automatically..

It's whack-a-mole on crystal meth.

https://forums.aws.amazon.com/thread.jspa?messageID=399950

That's their official response, and rightly so it should be. Talking from experience, I've had many requests for different websites I run and almost all were frivolous. Some content I took down anyways, and some I explained to Amazon why it was frivolous. They've never cancelled any of my services or even threatened to.

Not all hosts are US-based, though; some hosts in other countries prefer to get a court order in their own jurisdiction before taking action against a customer.

This doesn't mesh with reality; The sea of torrent seedboxes in existence would be dropping like flies and not growing.

Aren't torrent seed boxes typically in jurisdictions hostile or indifferent to US copyright law?

This exact thing happened to me on DO; I got an email from them (also automated) telling me to cut it out our have my account terminated. I was traveling overseas and had no other option for watching my shows, so I switched to PIA.

FYI MPAA can and will go after you even for a small site with 100 of visitors daily. They went after me, tried to sue me, got my servers shut down and sent lots of scary emails to my personal email.

It's easy for anyone who can do traffic analysis on your traffic, eg your ISP and mass surveillance perpetrators. And whoever your ISP decides to sell or give this data to.

Well your traffic is encrypted (assuming OpenVPN), so all your ISP should be able to see is the amount of data to and from your VPN.

They can of course see the individual packets and their exact timings. This can be trivially correlated with egress traffic from your VPN gateway to other ISP affiliated networks or web properties. And since it's your private gateway, there is no other traffic mixed in.

Traffic analysis is a term of art in cryptanalysis and SIGINT, in case you were not familiar: https://en.wikipedia.org/wiki/Traffic_analysis

I was unaware. Thanks for the info!

Digital ocean outed me to the MPAA (they forwarded me a warning), but they didn't cancel my account. I now proxy my torrent client on top of the VPN.

There are use cases that make sense. My home linux router intercepts and sends all DNS and NTP requests, then routes all DNS requests to multiple VPS nodes that in turn, use multiple DNS recursors at each VPS datacenter. I intentionally avoid google and opendns. I override the min-ttl of all requests to avoid some shenanigans and I am well aware of the issues this can cause.

At a minimum, my ISP can not see or tamper with DNS requests. My VPS nodes are multi-purpose so it isn't really extra cost.

This also gives me the capability to intercept some of my traffic and route it over my VPN using a combination of haproxy and squid. I can do this by source PC, or by destination, or protocol, or any combination thereof.

For me, this has worked great for years and gives me a lot more flexibility, options and control over my data flows. If I want more privacy, I can use my existing tc cbq QoS and rate limited rsync's of random noise to hide some traffic patterns.

"At a minimum, my ISP can not see or tamper with DNS requests."

Are you encrypting each DNS packet at the source (e.g. your home recursor/DNS-forwwarder)?

If yes, when are your sent packets decrypted? At the authoritative nameserver, or at some intermediary recursor?

If no, how do you believe that your DNS packets are opaque and tamper resistant?

There are very few authoritative nameservers on the internet that accept and return encrypted DNS packets. Thus third party recursors must send out unencypted DNS packets. Nothing protects these unencrypted packets from being captured, viewed or tampered with.

It sounds more like you are creating a chain of recursors (that you control?) to make tracing the requests more difficult.

If you are using any third party recursors are you concerned about applications you use that implement support for ends-client-subnet extensions?

My home ISP can not see my DNS packets. Those are the adversaries I am defending against specifically. All DNS packets on my home ISP are encapsulated in a VPN to my VPS nodes. I also pre-cache popular requests via cron and via settings in Unbound.

From there, for sure, the risk increases. I am not sure I trust DNSSEC to help me much. That said, I rotate through many local recursors at each location, so they have to rewrite my traffic right as it leaves my node. That is doable, but that isn't really what I am defending against. Anything I care about, I validate in a script and write into /etc/hosts.

You are correct, there are not that many recursors that support TLS.

Beyond that, things like software updates I don't trust DNS at all and certainly not public mirrors. I validate packages with GPG signatures. Even that is tricky, because chicken+egg, so I validate the GPG sigs from trusted sources.

On a funny side note, you would be surprised how many people rely on trusting GPG keys that are contained in a package, signed by those same keys, in the same repo.

DNSSEC doesn't really protect you at all here. The last mile between you and your recursor has no DNSSEC protection at all (DNSSEC is server-to-server). There are a whole bunch of other places to redirect your traffic before and after name resolution. And, of course, DNSSEC offers no privacy whatsoever: any ISP MITM can still see every domain name you're looking up, because DNSSEC is a signing-only protocol.

Pretty clear to me he's running DNS over the VPN, and so yes, 'ISP' referred to 'his immediately upstream ISP', and so yes,

OP is "creating a chain of recursors (that you control?) to make tracing the requests more difficult"

but also, as a result less difficult to tamper with by a less trusted party such as a mass market commercial ISP - tampering with his forwarder would entail either tampering with random many other peoples traffic or compromising the 'percieved as more secure' ISP.

Pretty sure someone mucking around with TTL's on these packets to make sure they don't get too far out of intended range and the numerous other things would be aware of these issues..

That's really cool. Do you have links to share about that setup?

Sorry, I do not. I set it up manually. While I do have some scripts, they are custom tailored to my network setup. That said, it's really easy to do.

You could use the other github scripts that folks have linked for setting up the VPN. Then you would want to set up recursive DNS servers on your home router and VPS nodes. Then look into iptables mangle to intercept DNS, NTP, etc. HAProxy L4 vip on the router is an easy way to forward some web traffic to Squid running on multiple VPS nodes. Squid has an intercept mode you can use for any traffic you want to throw at it. Unbound DNS can override min-ttl and allows overriding partial or complete DNS zones for block some shenanigans. Calomel.org has some articles on some of these things.

It's probably even better if you research each step yourself so that adversaries have to work harder to generalize attacks around your configuration.

Really easy to do :)

I love HN

Really easy indeed. At least that explains your username!

Exactly. The author says because hosting companies are big they would never give information but this is a complete flaw. Google and Reddit are both known to hand information to law enforcement. Companies like digital ocean don't put as high as emphasis on customer privacy as companies likes PIA. On 90% of the service portals for servers I've purchased have had a message showing my IP was logged for safety reasons. So by making your own vpn you're just turning a direct link to you into link to a link pointing right back at you instead of thousands of people.

Put your consideration in Germany, privacy is pretty enforced here.

GEMA is pretty aggressive in Germany. Talking jane random and they don't do file sharing because they are in fear of GEMA.

People are afraid to file share but not because of GEMA which for once has nothing to do with this. Right holders (especially of popular music, movies, and TV shows) connect to torrents and log who is also in the swarm (i.e. uploading and downloading). They then go to court quickly with your IP which orders your ISP to give up your name and address.

They tell you about GEMA although as the cause of their fear, at least to me. The details, as you say, are probably different.

Yes, for some reason GEMA has become the scapegoat for all music-related inconveniences in life.

>The problem with a home-grown VPN is that you lose some of the plausible deniability that's gained from a shared VPN.

Yes, but what good is a VPN where you cannot trust your own network? I would have zero trust in any closed source private VPN. There are ways to gain anonymity from your host that wont require setting up a MITM attack vector for your traffic.

I get a lot of value from a VPN that prevents my ISP from spying on my traffic. I see from looking around this conversation that two other people cited this same reason.

I could totally see that many people wouldn't care about this particular thing.

Not just spying either, but if you are in oz at least, keeping all that metadata in a big, juicy, government mandated, and poorly secured bundle for 2 years!

VPN is one layer. Filtering all port 80, only permitting TLS, and aggressively paring down your trusted root cert list can effectively mitigate the MITM threat.

> plausible deniability that's gained from a shared VPN

Browser and device fingerprinting have become very powerful making VPNs not a very solid solution.

yep :'(

and the only solution seems to use Tor-browser with javascript disabled, which makes browsing the web a pain-in-the-ass.

Vultr (http://www.vultr.com/?ref=6979836) allows you to pay with bitcoin, making it more difficult to trace you

But they are likely to provide IP addresses used to connect to your server. So now you're facing the same problem, if you wanted to hide your IP address.

Are they so likely? Do you mean they keep logs of every attempted connection to every vps? Even in countries like Netherlands? I'd bet that's less likely than keeping a log of their paying customers' names

>allows you to pay with bitcoin, making it more difficult to trace you

...but they require a valid credit card/paypal deposit beforehand, which kills the whole point.

I had no idea of that requirement, kills the whole point indeed :(

edit: there's a list of providers allowing only bitcoin as payment method: http://cryto.net/~joepie91/bitcoinvps.html

With referral link?

Why shouldn't I?

Yes, this!

Whether or not that's important depends on your risk model.

Would it be possible to run a commercial vpn inside a hosted vpn? Still seems traceable to me...

I operate my own VPN endpoint for a couple reasons:

1. I frequently need to connect via open, untrusted local networks, such as those at hotels.

2. Many commercial VPNs (e.g., PIA) end up having some portion of their endpoint IPs end up on blacklists and break a lot of sites.

Anonymity from the government is a lower priority than both of the above, and I acknowledge the lack of it in my risk model.

Initially I started out just running a Streisand[0] server, but its scope and overall speed were unsuited for my wants. Now it's just a barebones VPS with OpenVPN running, and I connect to it primarily through a travel router.[1] Longer term I would like to develop an Ansible playbook so that I can quickly deploy a new endpoint at a close VPS when traveling if the need arises for better speed.

[0]: https://github.com/jlund/streisand

[1]: https://www.amazon.com/gp/product/B01I92T754/ref=oh_aui_deta...

>2. Many commercial VPNs (e.g., PIA) end up having some portion of their endpoint IPs end up on blacklists and break a lot of sites.

Yup. I cannot use these in good faith. I've gotten burned really badly by using shared VPNs and payment-type sites. I roll my own on a no-log VPS paid in Bitcoin through a mixer, registered to a false name/address.

What was wrong with Streisand?

That's why I have been using and recommending for a while, I've not had any speed issues. Currently running it on a t2.micro in AWS.

I can help clvx.easy-rsa, clvx.openvpn ansible role in galaxy.. there's a bug starting the service due to systemd, but it works if it's started manually. I'm working on it though.

Alternatively, just use Algo. [1] It's a self-hosted, hardened IPSEC VPN that automates setup on multiple cloud providers.

1. https://github.com/trailofbits/algo

Algo is great!

For anybody who wants steps on setting it up with an unsupported provider, I wrote a blog post on exactly that recently: http://modulolotus.net/posts/2016-03-28-setting-up-algo/. I used Vultr, but it should help for any Ubuntu-based server.

Is the "2016" date in your blog post & URL correct? Seems off by a year.

Ooo, good catch. Must have mistyped the year in the filename.

I'm really happy with Algo!

One minor issue I experienced: I have not had a good experience using Digital Ocean for VPNs. I tried manually setting up OpenVPN on it a while ago and got really bad upload speed (admittedly, I could have misconfigured it). With Algo, the speed seemed okay, but I would frequently "disconnect" every hour or two. According to Windows, I was still connected to the VPN, but my traffic wasn't getting out; I'd have to manually reconnect to get Internet access again.

I set up Algo on Azure a month ago and have had no problems at all. I'd highly recommend Algo if you're looking for ISP/untrusted network protection and pseudo-anonymization (3rd parties just seeing a cloud IP rather than your home IP).

Or Streisand.[0]

0) https://github.com/jlund/streisand

Most people who have an opinion between the two suggest algo is the better of them, for what its worth.

Thanks. I've never used either, actually. I just do it manually. Another good option for AWS is OpenVPN Access Server. There's a template.

Also packages in APT; openvpn-as is trivial to set up as long as TUN/TAP is enabled. Has a web portal and everything and serves Windows and MacOS binaries from the self-signed HTTPS page. Easy for most moderately technical users.

I'm happy with algo too, easy to setup and works great.

Like, I'm not sure why anyone thinks that:

1. AWS, DO or Linode won't respond to a subpoena

2. That any of those three won't have extensive logging in place, without the privacy goals that a VPN provider would have

You're just switching your ISP to AWS when you do this, which might be better than what you've got, but certainly isn't flawless untraceable security

I'm not sure where the claim of "untraceable security" came from.

I do something similar to this. The goal isn't avoiding legal liability or based on the belief that AWS, et al are friendly.

There are multiple reasons, but the single biggest is to thwart last-mile surveillance by my ISP. That alone is worth $10/mo and a few minutes of setup.

AWS/DO/Linode arn't trying to monetize and manipulate their outbound traffic as aggressively as Consumer ISP's are.

These private VPN solutions simply protect all your traffic from ISP interference.

I really hope people aren't using a VPN for untraceable security. VPNs are for privacy, not for getting away with illegal things.

Yeah, coffee shop wifi is for getting away with illegal things.

I can confirm. This is where I write all of my dangerous Visual Basic IP addresses.

"... but what about when your ISP literally edits your web traffic, inserting more ads, and possibly breaking webpages."

It is possible the ISP not only injects ads but injects unique identifiers that the user never sees. These could be used to track the user across different devices and networks. This possibilty was suggested a few years ago by a well-known cryptographer in a presentation titled "How to manipulate standards".

This is odd. The primary point of VPN services (aside from a layer of protection on untrusted networks) is to mix your traffic in with N other random users such that the chance of you being identified as the source of the traffic is 1/N instead of 1/1.

Hosting your own VPN exit node, with you as the sole user, defeats this use case entirely.

It's worth nothing that this may be your primary point, but that does not necessarily extend to the whole. Netflix has region-locked content that is often most easily accessed by leveraging VPNs. ISPs will have greater trouble selling off your meaningful browsing data if it's going through a VPN. And so on.

The only use-case I have for a VPN at the moment is to go around the inevitable throttling that will happen when net neutrality goes away (in the US). I have no reason to hide my browsing from the government. When I do (which I very much see as a possibility in the future), I will switch to something more anonymous.

Why is he using AES-CBC rather than AES-GCM? GCM is generally faster & more optimized, especially for hardware offloads like might be present on some routers.

Is there something about OpenVPN that doesn't support GCM?

AFAIK OpenVPN officially has GCM mode support since v2.4, which is relatively recent (official release December 2016).

I'm sure it was also present in 2.3.x - at the very least I'm certain that 2.3.10 I have on one host supports TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 - but it could be distro-specific backports or something like that. At least 2.3 changelogs don't mention anything about AEAD or GCM specifically, and GCM support is featured in https://github.com/OpenVPN/openvpn/blob/release/2.4/Changes....

Update: no I was wrong. OpenVPN v2.3.x has two connections, a control channel and data channel. That TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 (defined by `tls-cipher` setting) is a control channel, and data channel doesn't support GCM.

Anyway, 2.4 is out already.

Maybe he wasn't aware of it? Just my speculation.

In any case, AES-GCM is natively supported by OpenVPN 2.4, and Streisand as it is will configure it for you as part of the NCP ciphers list, with a fallback to AES-CBC if the client is a bit older [0]

[0] https://github.com/jlund/streisand/blob/master/playbooks/rol...

I would like to have a setup like this:

- One VPN to connect laptop on the road with machines at home LAN, and with VM:s on different hosts.

- Have this VPN "exit" via a commercial VPN-provider (for privacy).

Could I easily configure this? Have one of the VM's be the VPN server and configure it to "exit" trough the commercial VPN?

I haven't really managed / configured "real" VPN's, how does local access work? I.e, when I'm at home with my laptop and access my desktop that's on the same network, will the packets flow out to the remote VPN server and back, or can it resolve it locally somehow?

Also, will this break stuff that depend on Bonjour / ZeroConf (i.e Apple Airplay and stuff?)

> Could I easily configure this? Have one of the VM's be the VPN server and configure it to "exit" trough the commercial VPN?

This is easily doable, but it comes down to how much you trust your commercial VPN host. As it is, most of these service providers are pretty shady to say the least. If it were somehow possible to provide a service that is provably secure and log free, that would be a different story.

For the last year or something I have been using https://www.ovpn.com/en. They are not shady at all, and allow bitcoin or cash payments, and are run by a friend of a friend, so I trust them. But no less provably secure compared to the rest.

It's all about the routing table and subnet masks/link-local addressing.

start with the lan and configuring interfaces statically.. then run your own router (manually) then setup your portion of VPN to your VM.

by that time, the rest will all make sense.

I'm surprised that tinc-vpn.org isn't mentioned more in these VPN threads. It's such a pleasure to work with when compared to OpenVPN. You can standup a distributed mesh VPN in minutes.

You should add that it routes in user-space without turning on kernel forwarding, to any node in the network even if they are not directly connected. There are some nice privacy and availability aspects to this.

A lot of the focus of VPN discussion centers around logging, and around whether their provider is prepared to hole themselves up in their compounds like Branch Davidians to protect their info.

That misses the point. If the government wants to hack you, steal your traffic, etc, they can, VPN or not, 'no-log' VPN or not.

The point behind consumer-level VPNs is more to prevent the ISP-level tracking, the ad-targeting, etc, and to keep out hackers and get around government/institution blockers. For this, whatever well-reviewed service will do.

or use docker: https://hub.docker.com/r/kylemanna/openvpn/

> or use docker: https://hub.docker.com/r/kylemanna/openvpn/

That's my project, thanks for the shout out!

For those curious the main feature of the Docker container is to wrap up the PKI generation and conf file generation for the 90% use case.

"First your website uses SNI..."

s/uses/may use/

Not every website uses SNI.

For example, the majority of sites linked to from HN do not use SNI.

Also, there are workarounds when SNI is not supported. Workarounds have been published by one major corporation who authors a popular web server software and runs a cloud hosting service.

Is SNI "the only way to do it"? No. There is another way to do stream encryption for mlutiple websites from one IP. It predates HTTPS. This idea goes back to one of the original authors of the world's first web server at CERN. The legacy of this idea survives today as the Websocket "Upgrade" header. Links to further reading below.

Because of groupthink dynamics among today's standards committee people and website owners who follow along, it appears that any online discussion of alternative options to SNI is met with swift dismissal.

http://www.ietf.org/rfc/rfc2817.txt

http://www.ietf.org/rfc/rfc2818.txt

The draft below refers to proxies but further searching will find papers he wrote about how to start an encrypted stream upon connecting to an HTTP server. Any service could sit behind one simple HTTP interface. This idea was revived in "Upgrade" header referred to above. Then forgotten as HTTPS became popular. Then revived again for "Websockets".

http://www.ietf.org/archive/id/draft-luotonen-web-proxy-tunn...

SNI is not the only solution, it is just one approach, and I suspect the next-generation encryption (a TLS alternative that will be readily adaptable to PQ) will not need to send domain names in the clear.

I am interested in this idea, but I don't expect a better solution than SNI to appear anytime soon.

RFC2817's `Upgrade: TLS` is just like SNI except it requires an extra roundtrip and it only works for HTTP, not other TLS-enabled services experiencing the same issue (e.g. IRCS, FTPS, ...).

For an HTTPS server with a single certificate and no SNI handling, the domain name is (A) still leaked in plaintext by the initial DNS lookup, and (B) instantly visible by anyone who connects to the IP address.

Even if you plug the DNS hole, the fundamental issue is needing to secure communications with the remote server, before you even tell it what domain you're asking for. That can't work under the domain-validation CA model.

I suppose you could add an extra layer of indirection, by adding a certificate for the server itself; but that's just moving the chain of trust, and it's practically equivalent to a multi-domain SAN certificate.

Correction: The above draft was not the one I was thinking of. Here it is:

http://www.ietf.org/archive/id/draft-luotonen-ssl-tunneling-...

I have no current need for it, but I'd be really interested to read a step-by-step guide on setting up an untraceable server using cryptocurrency, starting from cash. As others have pointed out, the hole in these instructions is that you have to trust Digital Ocean.

I ran across this one today: https://github.com/trailofbits/algo

Based on ipsec, so no extra software to install on the clients. Looked interesting.

We also built a solution to quickly deploy your own VPN using OpenVPN: https://www.tinfoilsecurity.com/vpn

All open-source, too.

It seems the gov of Egypt is starting to block ipsec vpns like it did openvpn ones. Any generic solution to add obfuscation layer? Wish more VPN software had such functionality out of the box

What's the difference between L2TP/IPsec and OpenVPN?

They are three different protocols allowing to tunnel encrypted traffic between two end points:

- L2TP is the "layer 2 tunneling protocol", where the layer 2 is usually PPP, and an IETF standard;

- IPsec is designed to tunnel IP over IP, and an IETF standard;

- OpenVPN is a specific software and protocol, using TLS. IF memory serves well it can operate at both Ethernet and IP level, although IP is the most common.

To add, L2TP is only tunneling and not encrypted, which is why it is often used in combination with IPSec.

It is used instead of pure IPSec because it allows non IP traffic, which in some cases is more important (e.g. windows non-IP netbios traffic interop when L2TP/IPSec was first made popular)

and to confirm, yes, OpenVPN will run in IP or ethernet mode.

This might be a good idea for a startup where they create a plug and play service so users do not have to go through all of this.

Too bad IPv6 is again ignored completely; not even a mention in the article.

From my perspective in datacenter infrastructure, ipv6 interest has actually declined in recent years.

I think the emergence of a functioning IPv4 market has actually tipped the scales backwards towards v4 unfortunately. I frequently hear from operators that v4 technology (and expertise managing it) for sharing addresses (NAT) is so mature and stable that there isn't much gain for them in the riskier bet on v6.

You would also be shocked at how many also consider the unsolicited ingress connection blocking caused by NAT to be a bonus security feature that v6 doesn't have.

I'm starting to become convinced I will be dead long before v6 dominates the world. :(

I setup something from a script on digital ocean a while back.

Its difficult to make you own VPN. you have to purchase servers and IPs

The best solution is to buy a vpn and stay secured. you can run it on - devices. I use ivacy because its $2 a month and working fine with me.

Easier: https://github.com/hwdsl2/setup-ipsec-vpn

Or just use a modern deployment option like https://github.com/jlund/streisand

i think nordvpn is like 80 bucks for 2 years seems worth saving this hassle.

Reply on news.ycombinator.com