m1k1o / neko

A self hosted virtual browser that runs in docker and uses WebRTC.
https://neko.m1k1o.net/
Apache License 2.0
5.96k stars 449 forks source link

Unable to deploy to Cloud Containers - NAT issue - Self-build #229

Open KriyenKP opened 1 year ago

KriyenKP commented 1 year ago

I'm currently unable to get the system up and running on cloud due to NAT issues when building my own version of Neko. When I deploy using IPFETCH or similar onto a container, the resulting IP does not match the IP on the box. There seems to be an external IP assigned by the DNS of our cloud host and an another address being assigned to the container itself.

azure ip display:

image

container ip display inside shell:

image

What makes the least sense to me is that when I deploy the version that is on dockerhub, that is built from this repo, it works fine. But when I build the system from my local machine with edits I require, it doesn't. I'm under the impression I have incorrect settings in my .env file. Would you be able to share yours or point me in the right direction?

.env file ########################################################################### image

docker-compose-yaml ############################################################################

image

m1k1o commented 1 year ago

That .env file is only used for running development containers. It does not really affect final image or docker-compose file.

That behavior is weird, could you ensure that your docker images are up-to-date? You could run neko --version in your built container and the one from dockerhub to see what go version was used. If its different, maybe you have cached older image. Try removing golang image or just running docker system prune -a what removes all unused docker resources (notice also stopped containers).

external IP assigned by the DNS of our cloud host

This is not resolving IP using DNS, it is just getting the IP of ifconfig.co server to create HTTP request that gets your IP. You could also try different service as http://checkip.amazonaws.com or http://api.ipify.org/. Maybe your docker network egress is routed differently.

You could theoretically create your own simple HTTP service that gets your IP reliably and neko would call that. This is useful when being behind VPN. If your IP is static, just put it to NAT1TO1.

KriyenKP commented 1 year ago

I'll have a look and feedback. I might be a VPN issue to be honest. Thanks for the prompt response!

KriyenKP commented 1 year ago

I'm trying to setup Neko to run multiple instances behind an orchestrator like kubernetes. Basically being able to spin up a new instance of neko each time with injected information.

So as it turns out the issue is with containers and the way Neko is inherently architected. When spinning up a container on azure or aws, the container instance is assigned a public IP with which you can access it. However, the IP address that the container itself is aware of, is not the same. While I do not understand it well enough to explain properly to someone else, it's pretty much like a gateway so that the container itself isn't exposed. This causes issues as the the IP is assigned when it is spun up and we are not aware of it until it has. There is probably a way to configure it to be something I assign but I still need to do more learning on docker and kubernetes. Neko as a result, identifies itself as the ip on the container itself, not the instance running it, and it has no idea how to find it out either. Even with some sort of service. It would have to be injected in via some sort of script on the instance running the container.

Do you have any experience spinning neko up in a serverless environment or on a container instance on Azure or ecs on AWS?

m1k1o commented 1 year ago

I have only experience spinning neko up in environment, where IP address of the node where it is running is known in advance. That is passed using NEKO_NAT1TO1=<ip>.

It would have to be injected in via some sort of script on the instance running the container.

If you would create one internal container that is able to get the real IP, you could set it to NEKO_IPFETCH=http://neko-ip-resolver.internal. This is the only way how to currently inject ip to the instance during container. That HTTP call could be blocking until the IP is known.