We've got a service (java-based) and mysql both running as ECS services. The service wants to communicate to a mysql database through a network ELB.
When our service and the mysql database are running on the same EC2 instance, it can't connect to the mysql database. I can reproduce this using telnet - if I telnet to the mysql database through the ELB from another computer I can connect, but if I ssh to the EC2 instance that mysql is running on and then try to telnet to it through the ELB, it just hangs.
What's going on?
If an instance needs to connect to itself via a network load balancer I think the only way to get it to work is to disable client IP preservation on the load balancer target group.
From https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html
Check whether client IP preservation is enabled on your target group.
Load balancers with client IP preservation enabled do not support
hairpinning or loopback. If an instance is a client of a load balancer
that it's registered with, and it has client IP preservation enabled,
the connection succeeds only if the request is routed to a different
instance. Otherwise, the source and destination IP addresses are the
same and the connection times out.
If an instance must send requests to a load balancer that it's
registered with, do one of the following:
Disable client IP preservation.
Ensure that containers that must communicate, are on different
container instances.
Related
I have two containers, a client container and a proxy container. My goal is to get all of the client's outgoing network traffic (TCP and UDP) to be sent to the proxy container. The proxy container has a local socket that receives all traffic from the client, does some processing on it, then forwards the traffic to its original destination (using a new socket).
I have been able to implement this with real hardware (using two Raspberry Pis), but I'm trying to get this working on Docker now.
Currently, I'm trying to do this by creating two networks, an internal and an external network. The client is connected to the internal network and the proxy is connected to both the internal and external network. I then set the default route for the client to send all traffic the proxy. On the proxy, I have IP tables routes that should be sending content to a local proxy running on the system (using these instructions: https://www.kernel.org/doc/html/latest/networking/tproxy.html). Unfortunately, no connections are made to the proxy socket.
I'm hoping someone can point me in the right direction for getting this to work. I'm happy to describe more about what I've tried, but I worry that might just confuse the issue.
So I am having a pterodactyl installation on my node,
I am aware that pterodactyl runs using docker so to protect my Backend IP from being exposed when connecting to the servers I am using a GRE Tunnel from X4B.net
After installing the script I was provided by X4B I got this message
Also Note: This script does not adjust the configuration of your applications. You should ensure your applications are bound to 0.0.0.0 or the appropriate tunnel IP.
At first I was confused and tried connecting to my server but nothing worked, so I was thinking that it was due the docker not being bounded to 0.0.0.0
As for the network layout I was provided with:
10.16.1.200/30 Network,
10.16.1.201 Unified Gateway,
10.16.1.202 Bound via NAT to 103.249.70.63,
10.16.1.203 Broadcast
So If I host a minecraft server what IP address would I use?
I have a Python 3 application deployed in Google App Engine, flexible environment.
I'm using psycopg2 to connect to a PostgreSQL instance hosted in Google cloud SQL.
I'm having trouble connecting to PostgreSQL from Google App Engine.
Cloud SQL Proxy seems to initialize ok, but it binds to 0.0.0.0
Listening on 0.0.0.0:5432 for projectID:us-central1:my-db
Trying to connect on 127.0.0.1 or localhost doesn't work. Connection is refused.
What does work is using the docker (app engine flexible environment uses docker underneath) default IP 172.17.0.1 (from the docker0 adapter)
Using that IP address to connect to Cloud SQL seems like it would bite me in the ass if someone decides to change it.
Why is this happening?
Is using the default docker0 adapter's IP address a viable long term solution?
Is there an alternative other than switching to a socket based connection instead of the tcp approach.
It sounds like you are running the Cloud SQL proxy on your host machine, while you are attempting to run your application from inside a container. The reason it can't connect to the proxy is because 127.0.0.1 refers to docker's loopback interface, while the proxy is bound to the host machine's interface. The 172.17.0.1 is the address the container can use to can reach the host interface.
One alternative is to use host networking (https://docs.docker.com/network/host/), by passing in --network host. This will cause the host's interface to be used for the application.
I've switched from using TCP as the connection method and to using a Unix Socket.
The TCP issue seems to be a bug in the app engine flexible environment. But it's a beta feature (it is under the name beta_settings in app.yaml) and I'm not holding out for Google to fix it.
I also don't want to commit to an IP address that could be changed sometime in the future as a workaround.
I have created AWS ElastiCache redis server and configured with EC2 instance, but somehow I am not able to connect Redis via EC2 instance.
I have assigned the same security group as well.
here is my configuration
Error I am facing is Redis::CannotConnectError: Error connecting to Redis on some-prod.dhgdjw.0001.usw2.cache.amazonaws.com:6379 (Redis::TimeoutError)
Any help will be highly appreciated.
As you mention the same security group where you do not need such a setting. You Redis SG should be different it just suggestion as you need it on your local VPC.
Verify Few things...
Go you ElastiCache Dashboard
Select the Redis and click on the cluster then click on modify
then you will see security group attach with this Cluster You can attach one or many group with this cluster.
click on the edit icon and verify does it allow trafic on 6379 from 10.0.0.1/16 If instance and redis in same VPC, if not then allow public IP of instance in redis SG.
and you can allow also your public IP to check if it accessible. Install redis-client and try this command.
redis-cli -h some-prod.dhgdjw.0001.usw2.cache.amazonaws.com ping
PONG
If ping pong working its mean SG allow traffic.
We are developing an application for a platform that uses only IPv6 addresses on their client. We have built out our infrastructure using Rancher Server and Rancher hosts for the application containers.
Rancher does not support IPv6, so to allow the IPv6-only client to be able to connect to the application, I have put an Application Load Balancer (ALB) that supports IPv6 in front of the Rancher load balancer, which uses haproxy.
In Route53, my A and AAAA entries point to the application load balancer which is then forwarding traffic to the haproxy loadb alancer in Rancher which then distributes traffic to the application.
When we test the client, we are getting an error which states that the host is unreachable via IPv6. However if the ALB (application load balancer) is accessible via IPv6, it can forward to an IPv4-only host when it receives a connection from an IPv6-only client.
I actually solved the issue - I realized that in my terraform security group script, I was not adding IPV6 cidr blocks so therefore ipv6 traffic was not permitted at all to any of my instances. I updated my security group settings via Terraform and voila - this works as expected. So anyone who is looking for ipv6 support for your applications using Rancher on AWS, you can accomplish this using a dualstack application loadbalancer (ALB). Make sure your VPC is configured with ipv6 so this works.
Make sure your security groups allow for ipv6 traffic by configuring an ipv6 cidr block on the respective ports.