can a NodeJS application running on Bluemix make outside HTTP requests ? What address does the receiving end see ? There is a proxy that stops traffic from unknown servers on the other end, so we need to declare the origin IP. What is it for Bluemix ?
Any application running on IBM Bluemix can make outgoing HTTP requests (or any other outgoing TCP/UDP request).
Outgoing requests will come from the IP address of the DEA running the container with this application instance. If you have multiple instances, requests can come from any of these instances.
For details on the environment variables exposing these parameters, see this page:
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html
Yes a NodeJs application running on Bluemix can make outgoing requests.
The receiving end will see the IP address of the Bluemix gateway rather than the IP address of the DEA running the container. You can work out what the IP address is by doing a nslookup of your the app url, but the IP address(es) used is/are not currently documentation so could change.
Related
https://github.com/coturn/coturn/blob/c4477bfddd2cd51de1ad37032ca88330f3c44ed6/docker/coturn/turnserver.conf#L100
In turnserver.conf , I see a world " For Amazon EC2 users", if the external-ip is only used for aws?
I let the stun server run in the k8s cluster, and then expose it to the public network with the nodeport service, but the srflx returned by stun is a gateway address, not the external-ip which I set. My k8s cluster runs on Alibaba Cloud.
I hope someone can help me solve this problem, thank you！！！
AWS EC2 instances, for the most part, run behind a NAT. Even if you've assigned a public IP address (e.g. 1.2.3.4) via the AWS Console, the instance only knows about the private network its on and is unaware of the public IP address assigned to it. That is, the instance thinks its IP address is 172.31.5.6 because that's what the Operating System discovered at boot time. Port forwarding enables certain TCP and UDP ports to be forwarded from the public IP address to the private IP address that the EC2 instance is running on.
This typically isn't a problem for most services run on an AWS EC2 instance. With STUN running in full "2 IP address and 2 port mode", the server needs to advertise its alternate IP address back to the client, should the client want to conduct NAT behavior and filtering tests. But it would be incorrect for the STUN server to send back 172.31.5.7 as its alternate IP - the client has no way of reaching that IP since its private.
Similarly for TURN, when port allocations occur, the server needs to send back the public IP address of the EC2 isntance to the client who allocated it. It would be bad if the client requested a TURN port to share with another peer - only for the TURN srever to send back 172.31.5.6.
Hence, for a STUN or TURN server to be hosted behind a NAT, a set of command line parameters or configuration parameters are needed to tell the server what its "real" IP addresses are. The STUN/TURN software will use these IP addresses for sending responses back to clients.
I have an application running on my own server with kubernetes. This application is supposed to work as a gateway and has a LoadBalancer service, which is exposing it to "the world". Now I'd like to connect this application with other applications running within the very same kubernetes cluster, so they can exchange HTTP requests with each other.
So let's say that my Gateway app is running on the port 9000, the app which I'd like to call runs on 9001. When I make curl my_cluster_ip:9001 it gives me a response. Nevertheless I never know, what the Cluster IP will be, so I can't implement this to my gateway app.
Use case is typing to the web browser url_of_my_server:9000 -> this will call the gateway -> it sends HTTP Request to the other app running in the cluster on the port 9001 -> response back to the gateway -> response back to the user.
Where the magic has to happen and how to easily make these two apps to talk with each other, while only one will be exposed to "the world" and the other one will be accessible only from within the cluster?
You can expose your app on port 9001 as a service (lets say myservice).
When you do that myservice.<namespace>.svc.cluster.local will resolve to IP addres of your app. More Info on DNS here : https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
And then you can access your app within Kubernetes cluster as:
http://myservice.<namespace>.svc.cluster.local:9001
You have a couple of options for internal service discovery:
You can use the cluster-internal DNS service to find the other application, as detailed in the answer by bits.
if both the proxy and the app runs in the same namespace, there are environment variables that expose the IP and ports. This may mean you have to restart the proxy if you remove/readd the other application, as the ports may change.
you can run both apps as two different containers in the same pod; this will ensure they get scheduled on the same host, which allows you to communicate on the same host.
Also note that support for your HTTP proxy setup already exist in Kubernetes; take a look at Ingress and Ingress Controllers.
My .Net website uses WebClient to download a resource from another server. I am receiving "403 forbidden" responses from the remote server.
I think there is some sort of firewall issue as the requests work from my home development environment but the same requests are refused when my site is deployed to a web hosting company. I want to find the IP address that the refused requests originate from.
My question is this: is there a way to programatically find the actual source IP Address used by WebClient when it made the request?
I know the public IP address of my website but this might not be the same address WebClient would use for outgoing traffic. Unfortunately I have very limited access to the hosting company shared server and can't see any IIS logs or any other logs of incoming or outgoing traffic. Hence I am trying to get this IP address programatically.
I have seen SO questions on how to request a specific outgoing IP using BindIPEndPointCallback, but none on how to discover an actual actual IP used.
With a standard Kubernetes deployment on Google Container Engine, to include services configured with the Kubernetes load balancer settings which creates network load balancers, is it possible to access the user's (or referring) IP address in an application? In the case of PHP, checking common headers in the $_SERVER superglobal only results in the server and internal network addresses being available.
Not yet. Services go through kube_proxy, which answers the client connection and proxies through to the backend (your PHP server). The address that you'd see would be the IP of whichever kube-proxy the connection went through.
Work has been done, and a tracking issue is still open to switch over to an iptables-only proxy. That would allow your PHP server to get the actual client IP.
I plan to set the Secure Gateway Client at DMZ at on-premise environment, so I need to open Outbound ports for SG Client to connect to SG on Bluemix. The following question is similar to my question, but the answer doesn't show the needed ports.
For the Bluemix Secure Gateway service, how does the data center's network need to be configured?
For the Bluemix Secure Gateway service, how does the data center's network need to be configured?
The following Bluemix Doc shows Outbound 443 is needed.
https://www.ng.bluemix.net/docs/troubleshoot/SecureGateway/ts_index-gentopic1.html#ts_sg_006
What are the best practices for running the Secure Gateway client?
Before you install the Docker client into your environment, ensure that both the internet and your on-premises assets are accessible and all host names are resolvable by a DNS. The client uses outbound port 443 to connect to the IBM Bluemix environment, normally this port is open since its secure. Ensure you check or modify additional firewall and IP Table rules that might apply.
But, the tcpdump, which I got when I executed "docker run -it ibmcom/secure-gateway-client XXXX", showed that SG Client used Outbound 443 and 9000. Is it collect that all ports SG Client uses are Outbound 443 and 9000 ?
Correct, if you are closing down both outbound and inbound ports using your firewall, then for outbound allow ports 443/9000. So your initial assertion is correct.