I've long given up hosting my own VPN on VPC/cloud providers as means of cheap and quick "browser in another country" hack - so many things block access to known VPC/cloud IP address ranges, especially AWS, and I was previously an advocate for just throwing up a cheap self-run VPN container somewhere too.
The big advantage offered by many of the VPN vendors this article looks down on is the fact they can give you a residential IP in the target country - this can be a vast quality of life improvement for many browsing scenarios.
~5-6 years ago a self-hosted VPN exit node in AWS worked so much better than today in my experience, so many services have since added IP range blocks. This really matters for the common use case of trying to access TV streaming services in other countries, as one example.
I still run a private WireGuard setup at home to take advantage of my personal residential IP, but that's only good for content in my home country naturally - still handy when traveling, or to get more secure access on public wifi.
> The big advantage offered by many of the VPN vendors this article looks down on is the fact they can give you a residential IP in the target country
This is almost always not true.
There are "residential" VPN providers, but they are scammy AF. The only way to get access to a true residential IP is via some proxy/gateway software run by a customer of a real home ISP. These are usually obtained via botnets of infected PCs.
Users of residential VPNs are usually using them to scrape sites which try to prevent scraping and so are probably happy to turn a blind eye to where they get their IPs from.
They're also much more expensive then traditional VPNs.
I'd dispute that most access is obtained through botnets. I see it as generally obtained through the user themselves. I will agree that the provider may not be clearly notifying the user what they are agreeing to by utilizing their software, hiding it in their lengthy Terms of Service, but the user is agreeing to it by installing their software and accepting their ToS.
This was a huge controversy not long ago. The biggest issue I see from it is that it opens the user up to a fair amount of legal liability for what other users of the VPN service do while connected to the VPN service. If the user failed to understand what they agreed to in installing the VPN service and agreeing to it then it can make for some very awkward conversations when law enforcement comes knocking.
As a cybersecurity person I also think users fail to understand what information they are potentially making available to some rando running the VPN software on their PC. I can (and have before) see any traffic that you are sending through that VPN, and potentially tamper with that traffic. If you thought Nord or PIA could not be trusted with your traffic then how do you feel about Joe Random being able to see and tamper with your traffic?
If you read my statement, "they can give you a residential IP in the target country" - I never said this was universal.
Some private VPN companies will offer you a residential IP or dedicated IP, sometimes for additional fee - I'm paying for such a service right now. I perhaps should have broadened statement to "dedicated IP" etc, but it remains true you can get a far more "useable" IP from some private VPN providers.
One such example - and I know from my own testing this dedicated IP has far fewer issues with region locked content such as the BBC iPlayer or Netflix, where as almost every IP AWS has assigned me, including elastic IPs, has been blocked in the last few years:
Fair comment on getting a residential IP. I'm not necessarily looking down on commercial VPN providers. I do think a lot of their users don't understand the transfer of trust they are engaging in. As long as you understand that then great.
Another benefit is that your traffic can be pooled with other users coming from an exit IP which can be useful (as opposed from a single endpoint you control as I wrote about in this article). Tradeoffs.
I think you touch on a valid point: we should be focusing less on where our traffic egresses and more on ensuring all of our traffic is end-to-end encrypted as much as possible, as well as ensuring any "meta data" (i.e. DNS) is encrypted too.
This is arguably too narrow a way to think about this, as where you traffic egresses can directly affect what sites or services will work - this isn't hypothetical. Both are important!
If you need access to regional services, a common VPN use case and one outlined in the original article, its the single most important factor.
Fairly off-topic, but I've been having the hardest time finding a Wireguard configuration guide that lets me connect two peers (my phone and an SBC at my house behind my router) to a VPS peer (with a public IP) in a way that routes all the traffic from my phone through the SBC (via WG) and out to the internet via my home fiber connection. All the blog posts and tutorials I've seen have traffic going out through the VPS peer, with little explanation of how all the firewall and iptables commands might change if I wanted a different configuration. Has anyone seen a configuration like that, or know which networking concepts I should keep searching for to go in the right direction?
Since you’re just asking for concepts I can take a probably wrong guess that might lead you to something useful with some googling. (I’ve done stuff like this a lot, but not lately and this is all from memory.)
The problem you’re trying to solve is basically one of routing. You have a packet leaving your phone to the internet, and you want it to route it through the VPS, from VPS to SBC, SBC to your home router, then out to the internet. Start from one end and figure out each step.
From your phone, you basically just need your wireguard config to specify 0.0.0.0/0 in the allowed IPs. That will specify that all traffic should go to the peer. So that’s the easy part down.
Next is you need your VPS to route all traffic out through the tunnel to your SBC. You’ll need to enable IP forwarding, then you’ll need to set up the routes to accomplish this. You can’t just globally route 0.0.0.0/0 otherwise your VPS will no longer be connectable. All the traffic coming in via the wireguard interface from your phone will need to be marked via iptables’ fwmark to use a separate routing table (actually wireguard may do this by default…). So that table is where you’ll need to configure a route for 0.0.0.0/0 to your SBC as the next hop. Otherwise you just need to make sure you have allow rules in place on the forward chain to permit the packets to pass.
Once it hits your SBC, it gets easier. It needs IP forwarding enabled. Depending on whether you want to use double NAT or not you can do this a couple of ways. One is to set up masquerading/NAT and call it a day. The other is to, again, simply allow it to forward the packets along (passing them to your home router) and let your router handle the NAT.
The difference between the approaches will mostly play into how you set up all the reverse routes. As long as you can add routes to your home router, you can add a route for your wireguard range(s) to be routed through the SBC and it _should_ cooperate. If your router doesn’t allow you to set up routing like this, you’ll need to do the NAT on your SBC.
Then reverse route from SBC to VPS for wireguard range. (Can control this through the AllowedIPs in the wireguard config.) Your VPS shouldn’t need any extra work because it’s directly connected to your phone.
I have a vps as the wireguard "hub" with my phone, DNS and internal services being the spokes. I don't route traffic through home, but I do use home DNS as adblocker on the go. DNS also does the split horizon to route the phone to internal services over wg.
I would strongly recommend switching from iptables to nftables -- drastically reduces wtfs/minute metric during the configuration.
If you'd like -- I can send you the relevant parts of the firewall settings with some comments. My email is in the profile.
> If you'd like -- I can send you the relevant parts of the firewall settings with some comments.
Or you could post a link to a GitHub "gist" of a "sanitized" version of it it, so other random folks (like me; it sounds interesting / useful) can also benefit from it without you havin' to email it to a zillion random people. ;~)
Wireguard is L3, right? So it behaves like a network layer VPN. That means that you can't switch how traffic is flowing based on application protocol. But I'm not super familiar with VoIP stuff.
You can split the tunnel based on IP routing, but I think that's as good as it gets. So if you want to Wireguard specific traffic to your peer then you're fine. For instance, we have our internal cloud network linked to our offices via wireguard, but traffic to anything that is not that network goes to the public Internet via our fiber.
But if we wanted to send HTTP requests always through the WG, that is not possible to configure because WG acts as an L3 VPN and Layer 3 has no conception of anything but the network. You couldn't say "Send HTTP requests through my normal fiber, but DNS requests through my VPS peer".
I'm not sure I fully understand your setup or what you are trying to accomplish so apologies beforehand if I misunderstand.
One option would be to host the wg server on your SBC (guessing a raspi or something like it?) and make the VPS a peer thus routing everything out your home network. You can also use AllowedIPs to only route specific ranges on the wg network which allows other traffic to follow the route tables on that device and exit accordingly.
But if what you are asking is how do you have different peers on a wg network route their traffic out to the internet on various different peers you're going to need to get fancy with routes/iptables/virtual network interfaces/policy based routing using PostUp commands.
Would something like AlgoVPN installed at the appropriate point in your hierarchy/network map simplify this?
Unsure if/how/why you want to modify firewalls and iptables.
If you're ok running ubuntu or debian, the commands for ufw as a firewall are pretty straight forward to setup and maintain and can be scriptable.
Algo is a nice install that works just fine installed as a docker image running on a linux VPS. Installing docker and docker-compose are essential for this.
If after reading this you are saying there is no comprehensive step by step article that does this, let me know, and I can see if I have my install notes and the install script I created to put up somewhere.
I think sometimes enough years of linux and looking things up can be at fault for some of the documentation needs.
“why they felt the anonymous VPN operator was more trustworthy than a regulated ISP”:
- the VPN operator has never had an employee visit your home.
- the VPN operator did not require any type of credit check and/or require extensive personal information.
- the barriers to change VPN operator are substantially lower.
I’m not a huge fan of the VPN operators, but there are real differences in the trust required with each.
You not giving any personal data to Mullvad, only sending Bitcoin, doesn't really change that they can still potentially see any of your traffic entering and exiting their infrastructure, to include being able to connect your residential IP to a currently active session.
Tor isn't much better, as security services have been able to gain enough control or surveillance ability to match traffic as it ingresses and egresses Tor, to then identify where the traffic originated from.
With enough of a tinfoil hat you can perpetually be paranoid and chasing "anonymity" for a long while. It's really about what you're trying to conceal and what effort you put in to securing the infrastructure at the beginning and end of an end-to-end encrypted session, as well as the level of security of the end-to-end encrypted session itself.
Does anyone know the latest on having WG support dynamically assigned IP for peers? There have been some work done[1], but it seems to have stalled for quite some time.
The stateless nature of Wireguard makes it kind of hard to implement. Having something DHCP-esque makes sense when you have an external mechanism for authentication, like most traditional VPN software does, but with Wireguard you have to exchange public keys with peers that communicate with each other, so you might as well just set up the IP at the same time.
Depending on the instance type, Lightsail easily gets throttled into oblivion. The $3.50/month instance allows for 5% utilization before you start eating up burst capacity. Perhaps WireGuard is light enough that it's okay, but thought it worth mentioning.
Linode isn't too bad for a VPS instance - best ot make sure the IP isn't on many block lists, take your time logging into all your services through it and the rest can be generally smooth sailing.
More and more cloud providers look for and block vpn's self-hosted with vps providers, in which case, finding access to residential connections (trading) or a provider is a way to go.
Yeah, it's documented, but it's fairly buried in a place where you'll only find it if you already know throttling exists for Lightsail. It's irritating when I read blog posts comparing Lightsail to other, normal VPS offerings because it's not very normal :)
I’m curious, if we have a hub and spoke vpn, could we have peer to peer end to end encryption, with the exchange between them facilitated by an untrusted hub on a cloud instance?
So, the phone wants to connect to a media server at home. In hub and spoke vpn, both connect to a vpn server. The problem is, the traffic decrypted on VPS. I want the packers from phone go to vps then to home, with end to end encryption. The VPS acts as a relay.
The connection between peers need not be direct (peer to peer). The traffic could go through the central hub if needed. I just don’t want the hub to access the decrypted traffic.
Mesh VPN is one way. The VPS node will be the coordination server.
Tor is another, onion layers of tunnels.
But maybe there is an easy networking solution, like creating a route table on VPS implementing a relay or STUN server , that says traffic coming from the peers public key is exchanged on VPS server.
I built this to deploy a wireguard instance to your digital ocean account. Pick the region you want. It’s free, just pay digital ocean for the droplet…
First off...wow. Never expected this to hit front page. Just started writing and trying to get the juices flowing.
You could totally use an Ansible playbook. I've used a lot of them over the years. Ansible, Terraform, Salt, Chef, Puppet, etc...
As I said at the end of the article I glossed over a lot of things and the beauty of tech is there are lots of ways to do things. Do what works for you. Tradeoffs all over the place.
I do think that shell scripts provide lower level insight to people that may be trying to understand what is going on rather than the magic of something like Ansible that abstracts things away. Or maybe I'm just old school :D
More and more I'm finding having a bash script that can work on most debian/ubuntu systems is pretty handy to be able to run remotely whether it's a VPS or more.
I didn't care about the AWS and zsh aspects of the article, but what vendor lock-in are you talking about and how exactly would an ansible playbook sort it?
All you need is any ubuntu vps - in fact any systemd distro if you ignore the "ufw" commands - and the 50 or so lines following "Wireguard Setup".
Well using the aws cli is locking you in to AWS, isn't it? And at least from my experience those "just 50 lines of shell" can get very messy overtime. Eventually, if you add more features (pretty much every project gets more features over time), you will refactor once or twice and end up rewriting it in Python, make it more declarative because it's easier to test and tada, you just reinvented Ansible yourself. I think this question is legit.
Question: Assuming PKI is "solved" (whatever that means) isn't mTLS in contrast to sth like a VPN the preferred solution nowadays? Or both? I'm asking because Wireguard itself looks a lot like mTLS to me and I'm curious how HN people currently see that context.
WireGuard is a better, safer protocol than mTLS. If you can use WireGuard, that's what you should use (often you can't, because you don't want IP addressing between your components).
I've long given up hosting my own VPN on VPC/cloud providers as means of cheap and quick "browser in another country" hack - so many things block access to known VPC/cloud IP address ranges, especially AWS, and I was previously an advocate for just throwing up a cheap self-run VPN container somewhere too.
The big advantage offered by many of the VPN vendors this article looks down on is the fact they can give you a residential IP in the target country - this can be a vast quality of life improvement for many browsing scenarios.
~5-6 years ago a self-hosted VPN exit node in AWS worked so much better than today in my experience, so many services have since added IP range blocks. This really matters for the common use case of trying to access TV streaming services in other countries, as one example.
I still run a private WireGuard setup at home to take advantage of my personal residential IP, but that's only good for content in my home country naturally - still handy when traveling, or to get more secure access on public wifi.
> The big advantage offered by many of the VPN vendors this article looks down on is the fact they can give you a residential IP in the target country
This is almost always not true.
There are "residential" VPN providers, but they are scammy AF. The only way to get access to a true residential IP is via some proxy/gateway software run by a customer of a real home ISP. These are usually obtained via botnets of infected PCs.
Users of residential VPNs are usually using them to scrape sites which try to prevent scraping and so are probably happy to turn a blind eye to where they get their IPs from.
They're also much more expensive then traditional VPNs.
I'd dispute that most access is obtained through botnets. I see it as generally obtained through the user themselves. I will agree that the provider may not be clearly notifying the user what they are agreeing to by utilizing their software, hiding it in their lengthy Terms of Service, but the user is agreeing to it by installing their software and accepting their ToS.
This was a huge controversy not long ago. The biggest issue I see from it is that it opens the user up to a fair amount of legal liability for what other users of the VPN service do while connected to the VPN service. If the user failed to understand what they agreed to in installing the VPN service and agreeing to it then it can make for some very awkward conversations when law enforcement comes knocking.
As a cybersecurity person I also think users fail to understand what information they are potentially making available to some rando running the VPN software on their PC. I can (and have before) see any traffic that you are sending through that VPN, and potentially tamper with that traffic. If you thought Nord or PIA could not be trusted with your traffic then how do you feel about Joe Random being able to see and tamper with your traffic?
> This is almost always not true.
If you read my statement, "they can give you a residential IP in the target country" - I never said this was universal.
Some private VPN companies will offer you a residential IP or dedicated IP, sometimes for additional fee - I'm paying for such a service right now. I perhaps should have broadened statement to "dedicated IP" etc, but it remains true you can get a far more "useable" IP from some private VPN providers.
One such example - and I know from my own testing this dedicated IP has far fewer issues with region locked content such as the BBC iPlayer or Netflix, where as almost every IP AWS has assigned me, including elastic IPs, has been blocked in the last few years:
˜ https://nordvpn.com/features/dedicated-ip/
Same thing, different vendor:
- https://www.privateinternetaccess.com/vpn-features/dedicated...
And another...
- https://surfshark.com/dedicated-ip
etc etc
Fair comment on getting a residential IP. I'm not necessarily looking down on commercial VPN providers. I do think a lot of their users don't understand the transfer of trust they are engaging in. As long as you understand that then great.
Another benefit is that your traffic can be pooled with other users coming from an exit IP which can be useful (as opposed from a single endpoint you control as I wrote about in this article). Tradeoffs.
But there is also the transfer of trust to the VPS provider, no?
The cloud provider may have a less favorable privacy policy.
I think you touch on a valid point: we should be focusing less on where our traffic egresses and more on ensuring all of our traffic is end-to-end encrypted as much as possible, as well as ensuring any "meta data" (i.e. DNS) is encrypted too.
This is arguably too narrow a way to think about this, as where you traffic egresses can directly affect what sites or services will work - this isn't hypothetical. Both are important!
If you need access to regional services, a common VPN use case and one outlined in the original article, its the single most important factor.
Another reason to host your own VPN is that you want all your devices to be on the same network.
Fairly off-topic, but I've been having the hardest time finding a Wireguard configuration guide that lets me connect two peers (my phone and an SBC at my house behind my router) to a VPS peer (with a public IP) in a way that routes all the traffic from my phone through the SBC (via WG) and out to the internet via my home fiber connection. All the blog posts and tutorials I've seen have traffic going out through the VPS peer, with little explanation of how all the firewall and iptables commands might change if I wanted a different configuration. Has anyone seen a configuration like that, or know which networking concepts I should keep searching for to go in the right direction?
Since you’re just asking for concepts I can take a probably wrong guess that might lead you to something useful with some googling. (I’ve done stuff like this a lot, but not lately and this is all from memory.)
The problem you’re trying to solve is basically one of routing. You have a packet leaving your phone to the internet, and you want it to route it through the VPS, from VPS to SBC, SBC to your home router, then out to the internet. Start from one end and figure out each step.
From your phone, you basically just need your wireguard config to specify 0.0.0.0/0 in the allowed IPs. That will specify that all traffic should go to the peer. So that’s the easy part down.
Next is you need your VPS to route all traffic out through the tunnel to your SBC. You’ll need to enable IP forwarding, then you’ll need to set up the routes to accomplish this. You can’t just globally route 0.0.0.0/0 otherwise your VPS will no longer be connectable. All the traffic coming in via the wireguard interface from your phone will need to be marked via iptables’ fwmark to use a separate routing table (actually wireguard may do this by default…). So that table is where you’ll need to configure a route for 0.0.0.0/0 to your SBC as the next hop. Otherwise you just need to make sure you have allow rules in place on the forward chain to permit the packets to pass.
Once it hits your SBC, it gets easier. It needs IP forwarding enabled. Depending on whether you want to use double NAT or not you can do this a couple of ways. One is to set up masquerading/NAT and call it a day. The other is to, again, simply allow it to forward the packets along (passing them to your home router) and let your router handle the NAT.
The difference between the approaches will mostly play into how you set up all the reverse routes. As long as you can add routes to your home router, you can add a route for your wireguard range(s) to be routed through the SBC and it _should_ cooperate. If your router doesn’t allow you to set up routing like this, you’ll need to do the NAT on your SBC.
Then reverse route from SBC to VPS for wireguard range. (Can control this through the AllowedIPs in the wireguard config.) Your VPS shouldn’t need any extra work because it’s directly connected to your phone.
And you’re done! Maybe! Good luck!
This is very helpful, thanks! Looks like I have some reading to do about IP forwarding.
I have a vps as the wireguard "hub" with my phone, DNS and internal services being the spokes. I don't route traffic through home, but I do use home DNS as adblocker on the go. DNS also does the split horizon to route the phone to internal services over wg.
I would strongly recommend switching from iptables to nftables -- drastically reduces wtfs/minute metric during the configuration.
If you'd like -- I can send you the relevant parts of the firewall settings with some comments. My email is in the profile.
> If you'd like -- I can send you the relevant parts of the firewall settings with some comments.
Or you could post a link to a GitHub "gist" of a "sanitized" version of it it, so other random folks (like me; it sounds interesting / useful) can also benefit from it without you havin' to email it to a zillion random people. ;~)
Wireguard is L3, right? So it behaves like a network layer VPN. That means that you can't switch how traffic is flowing based on application protocol. But I'm not super familiar with VoIP stuff.
You can split the tunnel based on IP routing, but I think that's as good as it gets. So if you want to Wireguard specific traffic to your peer then you're fine. For instance, we have our internal cloud network linked to our offices via wireguard, but traffic to anything that is not that network goes to the public Internet via our fiber.
But if we wanted to send HTTP requests always through the WG, that is not possible to configure because WG acts as an L3 VPN and Layer 3 has no conception of anything but the network. You couldn't say "Send HTTP requests through my normal fiber, but DNS requests through my VPS peer".
How about policy routing based on dport? See `ip rule help`.
Very cool. Thanks for the tip! I had no idea this was possible.
I'm not sure I fully understand your setup or what you are trying to accomplish so apologies beforehand if I misunderstand.
One option would be to host the wg server on your SBC (guessing a raspi or something like it?) and make the VPS a peer thus routing everything out your home network. You can also use AllowedIPs to only route specific ranges on the wg network which allows other traffic to follow the route tables on that device and exit accordingly.
But if what you are asking is how do you have different peers on a wg network route their traffic out to the internet on various different peers you're going to need to get fancy with routes/iptables/virtual network interfaces/policy based routing using PostUp commands.
Hopefully that gives you something to go on.
Would something like AlgoVPN installed at the appropriate point in your hierarchy/network map simplify this?
Unsure if/how/why you want to modify firewalls and iptables.
If you're ok running ubuntu or debian, the commands for ufw as a firewall are pretty straight forward to setup and maintain and can be scriptable.
Algo is a nice install that works just fine installed as a docker image running on a linux VPS. Installing docker and docker-compose are essential for this.
If after reading this you are saying there is no comprehensive step by step article that does this, let me know, and I can see if I have my install notes and the install script I created to put up somewhere.
I think sometimes enough years of linux and looking things up can be at fault for some of the documentation needs.
Is this what you're looking for?:
https://www.procustodibus.com/blog/2022/06/multi-hop-wiregua...
Tailscale exit node.
Or headscale.
What is an sbc and the phone's relation to it?
SBC - Single Board Computer. Raspberry Pi most famous example? https://en.wikipedia.org/wiki/Single-board_computer
In this instance consider the SBC a lightweight, low-power, always on server sitting behind his/her router.
I thought it's a VOIP SBC, but don't know how those work to fully understand his issue, hence my question.
Easier to use https://github.com/trailofbits/algo
“why they felt the anonymous VPN operator was more trustworthy than a regulated ISP”: - the VPN operator has never had an employee visit your home. - the VPN operator did not require any type of credit check and/or require extensive personal information. - the barriers to change VPN operator are substantially lower.
I’m not a huge fan of the VPN operators, but there are real differences in the trust required with each.
You not giving any personal data to Mullvad, only sending Bitcoin, doesn't really change that they can still potentially see any of your traffic entering and exiting their infrastructure, to include being able to connect your residential IP to a currently active session.
Tor isn't much better, as security services have been able to gain enough control or surveillance ability to match traffic as it ingresses and egresses Tor, to then identify where the traffic originated from.
With enough of a tinfoil hat you can perpetually be paranoid and chasing "anonymity" for a long while. It's really about what you're trying to conceal and what effort you put in to securing the infrastructure at the beginning and end of an end-to-end encrypted session, as well as the level of security of the end-to-end encrypted session itself.
This VPN setup is great to use in public WiFi.
But be aware that the IP address may not be private in cloud instances.
Is it known to what extent the traffic is logged on AWS EC2 or Lightsail?
>traffic logging
None! that's an enterprise feature, you'll have to contact sales for pricing
Not necessarily. If you want to see the logs, you’ll have to pay for them.
If your government wants them, they’ll probably get them for free.
I guess your response indicates that the DNS records are not logged.
I thought some metadata is logged, at least for security or to fight abuse, but probably for more reasons. But I’m not sure.
? VPC FLow logs exist, as well as load balancer logs
if you enable these features and pay for them? so just by not paying for these features will you get privacy naturally?
Does anyone know the latest on having WG support dynamically assigned IP for peers? There have been some work done[1], but it seems to have stalled for quite some time.
1. https://github.com/WireGuard/wg-dynamic
The stateless nature of Wireguard makes it kind of hard to implement. Having something DHCP-esque makes sense when you have an external mechanism for authentication, like most traditional VPN software does, but with Wireguard you have to exchange public keys with peers that communicate with each other, so you might as well just set up the IP at the same time.
And then half of the websites are not working because they think you are a crawler/malicious user.
'half' is a lot, can y give some examples?
Was figure of speech. Not to be taken literally
openai
Depending on the instance type, Lightsail easily gets throttled into oblivion. The $3.50/month instance allows for 5% utilization before you start eating up burst capacity. Perhaps WireGuard is light enough that it's okay, but thought it worth mentioning.
Linode isn't too bad for a VPS instance - best ot make sure the IP isn't on many block lists, take your time logging into all your services through it and the rest can be generally smooth sailing.
More and more cloud providers look for and block vpn's self-hosted with vps providers, in which case, finding access to residential connections (trading) or a provider is a way to go.
Linode is now Akamai - and considerably more expensive than Hetzner, and you don't get all that much more for your money.
Linode has only gone up a little.
Hetzner might be worth looking into but the cheapest isn’t always the best value.
Digital ocean should be avoided for all production uses
LightSail instances are burstable t2/t3 instances under the hood.
Which...those types of instances have their use. But the fact that AWS kind of hides the whole CPU credit thing in LightSail is a bit misleading.
Yeah, it's documented, but it's fairly buried in a place where you'll only find it if you already know throttling exists for Lightsail. It's irritating when I read blog posts comparing Lightsail to other, normal VPS offerings because it's not very normal :)
You’ll also discover it if you look around in IMDS, though that’s no excuse for not documenting the throttle limits.
I’m curious, if we have a hub and spoke vpn, could we have peer to peer end to end encryption, with the exchange between them facilitated by an untrusted hub on a cloud instance?
So, the phone wants to connect to a media server at home. In hub and spoke vpn, both connect to a vpn server. The problem is, the traffic decrypted on VPS. I want the packers from phone go to vps then to home, with end to end encryption. The VPS acts as a relay.
The connection between peers need not be direct (peer to peer). The traffic could go through the central hub if needed. I just don’t want the hub to access the decrypted traffic.
mesh VPNs (tailscale, zerotier) are what you want :) tailscale will do the hole punching for you. :)
In professional settings what you're describing is more-or-less what DMVPN provides.
You basically described Tor.
Mesh VPN is one way. The VPS node will be the coordination server.
Tor is another, onion layers of tunnels.
But maybe there is an easy networking solution, like creating a route table on VPS implementing a relay or STUN server , that says traffic coming from the peers public key is exchanged on VPS server.
I built this to deploy a wireguard instance to your digital ocean account. Pick the region you want. It’s free, just pay digital ocean for the droplet…
Https://vpn.democratize.cloud
I wrote a TUI tool (runs over SSH in a terminal) for managing simple WireGuard configuration on the server: https://github.com/andrianbdn/wg-cmd
You just run it on your server and it does most of things, including generating WireGuard keys for clients and showing QR codes.
There are also many scripts to automate the wireguard install and client setup and generate QR codes as well. Example: https://github.com/angristan/wireguard-install
Careful with using a domain for this. If your domain has an A and an AAAA Wireguard will prefer the A.
Which sucks on 464xlat networks, as the proxy dies after a while making you lose incoming connections.
I’m surprised how many hotels block WireGuard now. I’m finding it harder and harder to do this.
Yes, I was surprised that internet stopped after connecting to OpenVPN at home. Had to use the mobile network.
Unlikely they're doing packet analysis, and Wireguard can be run on any port. Just change the port.
Such hotels may simply be blocking UDP traffic entirely.
Why not using an Ansible playbook? You can deploy it on any VPS without vendor lock in.
First off...wow. Never expected this to hit front page. Just started writing and trying to get the juices flowing.
You could totally use an Ansible playbook. I've used a lot of them over the years. Ansible, Terraform, Salt, Chef, Puppet, etc... As I said at the end of the article I glossed over a lot of things and the beauty of tech is there are lots of ways to do things. Do what works for you. Tradeoffs all over the place.
I do think that shell scripts provide lower level insight to people that may be trying to understand what is going on rather than the magic of something like Ansible that abstracts things away. Or maybe I'm just old school :D
Ansible, etc, are great.
But also one more dependancy.
More and more I'm finding having a bash script that can work on most debian/ubuntu systems is pretty handy to be able to run remotely whether it's a VPS or more.
I didn't care about the AWS and zsh aspects of the article, but what vendor lock-in are you talking about and how exactly would an ansible playbook sort it?
All you need is any ubuntu vps - in fact any systemd distro if you ignore the "ufw" commands - and the 50 or so lines following "Wireguard Setup".
It doesn't get more simple than this.
Well using the aws cli is locking you in to AWS, isn't it? And at least from my experience those "just 50 lines of shell" can get very messy overtime. Eventually, if you add more features (pretty much every project gets more features over time), you will refactor once or twice and end up rewriting it in Python, make it more declarative because it's easier to test and tada, you just reinvented Ansible yourself. I think this question is legit.
Question is not legit. Refactor what? Did you guys actually read the article?
Just copy/paste them commands in any linux vps. You don't need aws, at least lightsail is cheap. Ionos (1&1) is cheaper.
[flagged]
Might be the only tooling they have experience using. “When the only thing you have is a hammer everything is a nail” sort of thing.
Question: Assuming PKI is "solved" (whatever that means) isn't mTLS in contrast to sth like a VPN the preferred solution nowadays? Or both? I'm asking because Wireguard itself looks a lot like mTLS to me and I'm curious how HN people currently see that context.
WireGuard is a better, safer protocol than mTLS. If you can use WireGuard, that's what you should use (often you can't, because you don't want IP addressing between your components).
mTLS is not a VPN.
yes, i do trust protonvpn more than german isps.
cool. I'll give this a try on the weekend.
[dead]