I use a little tool behind Cloudflare and behind a local NPM instance.
I know how to get the real IP. But I still struggle to find any info about how I can force flask to show this real IP in the log, instead a 127.0.0.x IP (due to the local NPM proxy).
Does anyone have managed to replace the IP in the logs?
Related
My machine is configured in ubuntu. It has a python flask service. I use a domain that I bought with a certificate that I generated at aws.
I am concerned about the security of my service and wanted to use a tool called flask ip ban. However the IP I receive from users both on the console and in the code using '' request.remote_addr '' are specific ip's of the same domain that starts with 172.31. *. *
Even if I use proxies the ip of my pc is always 172.31.4.145 and this is neither my ip nor my proxies.
I tried to use the ip ban flask but I ended up banning literally all users, because those few ip's that seem to bring my clients, without me knowing how, were banned
I would like to know how to do to show the real ip's. Could it be because my service is micro? Or because am I using Load balancer with my certificate? I couldn't get any relationship with flask or python
You are behind a load balancer which mean the IP address you are seeing is the one from your load balancer. As Mark advise above you can use the x-forwarded-for header but what I wanted to add is that you have a wonderful blog post that explain it all.
https://aws.amazon.com/premiumsupport/knowledge-center/elb-capture-client-ip-addresses/?nc1=h_ls
I've got some questions about ip's from Digital Ocean and Google Cloud, I have little knowledge about IP's and networks, i have two apps, one is running on a DigitalOcean server (dropplet) and the other is running on a VM Instance of Google Cloud, i was trying to setup code-server on each server.
In the droplet of DigitalOcean I configure successfully code-server, when i was running the command code-server code server got online on the address: http://127.0.0.1:8080 so i couldn't get into the app 'cause it was the local IP of the droplet, so i couldn't write that IP on my browser for obvious reasons, doing a little research i found the flag --bind-addr for code-sever, then i tried this command: code-server --bind-addr=192.231.24.04:8080 (That IP is an IP example) and it works, i was able to access code server writing in my navigator http://192.231.24.04:8080 and also i can access with mydomain.com:8080
In Google Cloud i tried to do the same, but i couldn't, i configured succesfully code-server on the VM Instance, when i run code-server code server got online on the address: http://127.0.0.1:8080 (As in DigitalOcean) obviously, that's the local IP
of the VM Instance, then i proceeded to do the same thing that i did in DigitalOcean, use the ---bind-addr flag, so i wrote this on the console: code-server --bind-addr=104.652.18.64:8080 (That IP is an IP example) and the console put this: error listen EADDRNOTAVAIL: address not available 104.652.18.64:8080, I thought Google Cloud was blocking the port 8080, so i unlock it, but still wasn't working, doing a little research i found that i had to use the IP 0.0.0.0:8080, so i wrote this command: code-server --bind-addr=0.0.0.0:8080 and i tried to access on my browsing using http://104.652.18.64:8080 and it works... i don't know why, i also tried using myseconddomain.com:8080 and also works
So i don't know what's the difference, What does IP 0.0.0.0 mean?
I returned to DigitalOcean droplet and i tried to do the same, i wrote: code-server --bind-addr=0.0.0.0:8080 and in the digital ocean droplet says: error listen EADDRINUSE: address already in use 0.0.0.0:8080
So... what's the difference?
Why does DigitalOcean work in a way that Google Cloud does not work and Google Cloud works in a way that DigitalOcean does not work?
I appreciate your responses
Google Cloud's networking has a distinction between internal and external IP addresses. In particular, a GCE VM won't actually have an interface with the externally visible IP address. Instead, Google Cloud Networking will transparently route from the external IP address to the internal IP address, assuming such routing is allowed by the firewall for that port. Thus, when you tried to start code-server listening to the external IP address specifically, the VM didn't know what that was referring to, as the interface did not exist inside the VM.
Generally on a host (in the context of starting a service on a given interface), 0.0.0.0 refers to any/all of the IP addresses on the machine. In your case, it means that you have started code-server listening to the internal IP address, and since you have removed the 8080 block in the GCP firewall, GCP networking will route requests to the external address to the VM.
I am not certain about DigitalOcean, but I presume that they do not have a different internal and external IP address, and thus when you start code-server listening to the external IP address directly, it attaches to the correct address. The error you are getting when trying 0.0.0.0 indicates something else is already listening on port 8080. Check that you stopped all the prior code-server process first, as well as anything else that may be listening on 8080 on any IP already.
I've had success building the Angular2 Quickstart app on my local machine, but I'd like to jump forward to setting it up on an AWS instance. The issue is that I ssh into the instance and so the npm start command doesn't load the app into my local browser. Even the "External" addresses provided don't work, even with an elastic IP assigned and the corresponding port opened. I've also looked through the node_modules/lite-server files to update any necessary configuration changes, but I haven't found how to alter it properly.
Can anyone point me to some resources that can help me get started wit angular2 on AWS?
So, first, there are some differences between your localhost and the aws EC2 instance.
Your computer is a graphical computer with a browser, the ec2 vm is just a command line based linux server and has no browser installed on it.
npm start, just like "grunt someTask" has extra stuff built into the steps that wouldn't make sense on a linux server... i.e. automatically opening your browser window and doing live-reload for active development, etc.
the EC2 vm is a place where you want to treat it more like beta server or production server, meaning that you dont start and stop your app with npm start, instead you want to start it with node yourAppFile.js, and you are merely running it to see if it works. You don't develop here.
Also, the ec2 vm itself is guarded / protected by a security group, and that allows very few ports to be accessed from the outside world by default, so you've got to go edit the "inbound rules" of the security group and add a rule that essentially allows: "custom" --> "the node port" --> "your IP". Doing so will make it possible to connect to it using the vm-public-ip:port-of-node-app which will look something like this in your browser: 56.128.17.42:3000. And because you put your own IP in that rule, no other IP addresses would be able to load it in their browsers... just you. If you were to say "0.0.0.0/0" in the ip field, that allows all users anywhere to connect.
I would test with curl on your local machine to make sure it's up and running. You can do that with "curl http://localhost:3000/ (change 3000 to whatever port you are running on).
If that is working okay, you may have an issue with security groups. Go to the security group topic on the EC2 page and select the security group for your server and make sure that you have the port opened from your IP address (you can google "what is my ip" if you don't know it). You can just open it the whole world if you're not worried about security.
I had been trying to establish a MongoDB database with an exposed REST API (through Crest, then Sleepy Mongoose), but neither of these had been working. I tried to do a minimal sanity test of "Can I connect to that AWS machine or not?", so here's what I tried:
1) I set up a new Amazon instance (Ubuntu 14.04), and I made sure that all incoming TCP connections were accepted.
2) I tried running sudo python -m SimpleHTTPServer 80.
3) This worked when logged into the machine and doing curl http://localhost:80/ and curl http://XX.XX.XX.XX:80/ (the machine's IP address substituted of course). However, on my local machine, the command just timed out.
I'm really looking forward to any guidance here, so I can hopefully go back to what I was originally doing (MongoDB, exposing a REST API, etc.). Really thankful for any suggestions since this has been driving me crazy!!
This is probably a security group issue.
When doing the curl http://XX.XX.XX.XX:80/ on the machine itself, did you try the internal ip (172.x.x.x / 10.x.x.x / 192.x.x.x) or the external ip?
Also, does the machine have an external ip assigned? (I'm guessing it does, otherwise ssh'ing to it would only be possible from another machine in the same subnet.)
Go to the AWS console, open the instance details and check the instance's security groups. Is port 80 open for the world (0.0.0.0/0) ?
Basically, my internal IP is masked by an external IP of my internet service provider. So, my internal IP can only be accessed inside my intranet. I want to let users outside the intranet to access my Dev server as well which is hosted on 0.0.0.0:8000 on my system. How do I do that?
Check out localtunnel on github, it does exactly what you're asking.
https://github.com/progrium/localtunnel
If you are willing to go that far you can use Reverse SSH Tunnel:
open a free micro linux instance on Amazon's AWS and create a reverse SSH tunnel to redirect port 80 on the server to your machine.
This is a cool solution for testing purposes and low traffic usage...
You can read more about it here:
http://www.techrepublic.com/article/setting-up-a-reverse-ssh-tunnel/5779944