I realized that I didn't want to ever deal with port-forwarding, NAT, or dynamic DNS and decided to create this. Message me if you want a signup link.
I realized that I didn't want to ever deal with port-forwarding, NAT, or dynamic DNS and decided to create this. Message me if you want a signup link.
1) I saw that you're basically using one OVH box per IP. How do you plan to ever monetize this then?
What prevents a user from creating their own VPN instance on their own box and port forwarding from there? Granted this process is somewhat involved, but the kind of user who needs to do this is likely to be somewhat technically inclined anyway. (Some ideas: negotiate long-term deals for IP addresses and try to map > 1 IP per box / remove the static IP guarantee and keep a rotating pool of addresses – public IPs are more valuable than static IPs anyway IMO and you can integrate dynamic DNS into your service)
2) How do I know that you're not sniffing my traffic? Granted that most traffic being encrypted these days is a thing, but still I think it's a genuine concern.
3) I live in Asia, so latency was off-the-charts for me. (On the order of 500ms). But this problem could easily be solved by introducing servers in more locations.
2) that's a hard question, mainly because if I was using this service I would ask the same thing. Personally, I think a strong mission statement, privacy policy, and maybe a warrant canary would be good enough. At least with a strong privacy statement, I would be legally bound to never sell/peek at your data which is loads better than current ISPs.
I can't do much better than promise I wouldn't.
3) Did the Chicago server fare any better?
Also, thank you for the comments! I really appreciate them.
I think two tiers with a cheaper roaming IP + dynamic DNS plan and a more expensive static IP plan would be smart. But that's for you to decide.
3) Only the Canada server was available when I signed up ~2 weeks ago unfortunately. I'll take a look again.
You might want to sort out the Subspace name and trademark, sooner than later.
Alternatively, their VPSs are dirt cheap. $3.35/month.
How does this work? I thought WireGuard encrypts the traffic?
They support plaintext tunnels for free, and encrypted tunnels starting at eight dollars a month.
I cam across the service when learning how to accept incoming traffic on kubernetes.
I use it to develop a lot with twilio and salesforce callbacks.
How do you deal with the global scarcity of IPv4-addresses that you would need to scale your service? I think this can only work long term if you own the address space yourself and are not dependent on some specific provider or cloud.
Also very important is a local endpoint to get a reasonable end to end latency.
Or do I have to add a peer that's out of my control, which you use for routing between the two that are under my control?
I don't get how this helps me "build" a service. Can't find source code anywhere.
On a related note the whole reason I self host is so I don't have to rely on things I don't control so there is no way I would use something like this. Defeats the purpose of self hosting IMO.
Is there any concern over people using your service for illegal/unfavorable activities like torrenting? Or are you planning to keep logs to provide to law enforcement requests?
..that might go something like this...
Raspberry Pi at home running docker containers with a reverse proxy like Nginx or Caddy. The Pi is set to automatically connect to the wireguard service once it has a network connection. The hosting server with the external public IP forwards port 80/443 browser traffic to the Pi sitting in your home LAN. Your domains can be mapped through Cloudflare to the public IP of your external server for an extra layer of privacy and caching. Requests to your Pi webserver reverse proxy through other containerized services on the Pi or to other hosts within your private home network running services like Wordpress, GOGS, Express Node app, Verdaccio (npm cache/proxy,) pretty much anything. Things get even more interesting if you run a reverse proxy on the remote server. It's also great to have a static public address by which to reach and manage your internal servers via ssh.
Then I need to do documentation, figure out pricing/billing.