Hi guys!
I am pretty nervous about the release of this new feature because if I input this ipv4 address into the network access list of a mongodb atlas cluster it would be possible for some “stranger” to retrieve my database (I know they need a password and a username)?
Can I input this shared ip address without any concern about the security?
Thanks!
Hi! To clarify, the IP addresses assigned to your app are actually for ingress only. When you connect to one of them, you’re actually connecting to fly-proxy in the nearest Fly.io region, which then talks to your app. The choice of a shared or dedicated IPv4 address for ingress won’t affect the IP addresses that your app VMs use to connect out to other services.
When an app VM itself connects out over the Internet, the source IP address is one that’s assigned to the VM itself (and for IPv4, it’s behind NAT). Unfortunately, we currently don’t support setting a stable IP for this, which is what you’d need for your ACL. There are some suggestions for workarounds here.
Hope this helps!
Hello @MatthewIngwersen!
Thanks for your answer.
What other possibilities are there for assigning a static ip address?
If I set up a fly.io volume, would it be possible to access this without a allocated static ip address?
Thanks!
When would you introduce to have a static ip address of a vm?
Hey @TheDev, we’re aware of requests for static egress IPs (and thanks for posting about your use case; it’s important for us to know what people are doing with the platform!). Generally we can’t make any promises here about possible features or timelines, though.
To address your volume question: Volumes are attached directly to your app’s VMs, and each volume is accessible only from the VM it’s attached to. You don’t access the raw contents of a volume over the network. (If you wanted to tell me a bit about what you’re trying to do with volumes, I might be able to provide a little more help.)
Hi
- |
Thank you for your fast reply, I really appreciate it!
One question:
What is the difficulty for implementing unique IP addresses for a vm? Maybe (as a idea) you could assign the ipv4 address of the fly-proxy (per application) to the vm (the vm makes requests with this IP address) so you wouldn’t have to buy new ip addresses for the vm.
Hey @TheDev, sorry for taking a while to reply to you! This is a good question. I haven’t been part of any discussions about static egress IPs at Fly, but I think I can explain a bit about why this is nontrivial.
Sending data from a particular IP address is pretty easy, but making sure that other hosts can send data back to that IP address is the hard part.
Take your example: say we wanted to assign one of your app’s addresses (the ones that fly-proxy uses) to individual VMs. Those are anycast addresses. They’re assigned to fly-proxy instances running in all Fly regions, and some Internet routing techniques ensure that packets sent to those addresses end up reaching the closest fly-proxy. That’s great, because when a user connects to your app, they hit the closest fly-proxy instance, which can then proxy to the nearest instances of your app, decreasing latency.
However, now suppose that one of your VMs uses one of those addresses to talk to your external MongoDB database. When that MongoDB sends data back to that IP, it will get routed to the nearest fly-proxy, not to your VM! Now, maybe that fly-proxy could itself forward that data back to your VM, but to do so, it would need a way to distinguish the traffic that’s for the VM from that traffic that’s intended for fly-proxy. There’s no good way to do that. (After all, that’s what the IP address is supposed to distinguish, but in this case it can’t use that: it’s the same IP for the proxy and for your VM!) Furthermore, even if there were a good way to do this, it would still involve that traffic taking a detour through a fly-proxy, which probably isn’t what you want.
Giving your app’s VMs static egress IP addresses different from the fly-proxy ones is more feasible, but it still requires a bunch of work to make sure that data addressed to them gets delivered to the right place. I’ve already written a lot, so I won’t bore you with further elaboration, but hopefully this helps clear things up!
Hey MatthewIngwersen,
Thank you for your detailed answer. Now I understand how it works, though, I would like to ask 3 other questions:
I really appreciate you and your teams work and love to deploy my future apps on your Plattform, but please answer above questions for a better understanding for me.
Thanks!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.