Setting up an IPFS DApp using Express-Node on AWS EC2 instance running NGINX.
I keep on getting an empty list on ipfs swarm peers despite having a non-empty ipfs bootstrap list and an active daemon. I've used nc and checked that port 4001/tcp is open to public connections, and edited the security policy to allow outbound connections on 5001 and 8080. When I run the same code on my local machine, the ipfs swarm peers returns the expected list of peers.
Not sure how to get the ipfs swarm peers to successfully connect to other peers and upload my files onto the ipfs network.
Related
I have an ECS instance running in alibaba. My ECS is in a VPC that has a SSL server. I have downloaded the SSL client certificate which allows me to connect to openVPN and to ping the ECS instance from my local box while connected to openVPN.
However, when I login to the ECS instance, I am unable to ping back my local box. My security group is a basic one which allows all connections. I didn't touch the outbound connection.
Here are the details of my SSL Server, and successful ping screenshot (My ECS Primary Private IP Address is 192.168.0.201)
Here is a screenshot of my unsuccessful attempt to ping my local home IP address (The IP, 192.168.10.190，in the screenshot below is an arbitrary one for illustration purpose) from the ECS instance.
When you connect to VPN, you're assigned a private client IP of 192.168.2.0/24 as per your SSL VPN settings. This is the network that will be used for your VPN connection. From your screenshot I see that you're pinging to your local 192.168.10.190. Your cloud server does not have access to this network.
You can try pinging to your client 192.168.2.0/24 IP from your ECS. You probably will need to a the route to your VPC > Route Tables. I haven't tried connecting cloud server via SSL VPN myself, but I've used IPSec for two-way site-to-site connection, which is more suitable for this situation.
I am trying to set up an Apache Airflow server on ec2. I managed to get it running and verify status by hitting /health endpoint using curl on http://localhost:8989. Airflow listens on port 8989 here.
The next I want is to be able to connect to the admin dashboard/UI using the browser on EC2's public IP. So I added the inbound rule in the AWS security group ec2 instance belongs to.
While connecting to Airflow, I am getting the following error
Failed to connect to ec2-XX-XX-XXX-XXX.compute-1.amazonaws.com port 8989: Operation timed out
Not sure what else I need to do to reach server running on ec2.
If you can SSH to an EC2 instance, you've added a security group rule for ingress on another port, but can't reach the instance on that port, here are some other things to check:
Firewall running on the instance. Amazon Linux and recent official
Ubuntu AMIs shouldn't have iptables or some other firewall running on
them by default, but if you're using another AMI or someone else has
configured the EC2 instance, it's possible to have iptables/ufw or
some other firewall running. Check processes on your instance to make
sure you don't have a firewall.
Network ACL on the VPC subnet. The default ACL will permit
traffic on all ports. It's possible that the default has been changed
to allow traffic only on selected ports.
Multiple security groups assigned to the EC2 instance. It's possible
to assign more than one security group to the instance. Check to make
sure you don't have a rule in some other security group that's
blocking the port.
I have an aerospike server running on EC2 and I need to run some tests on aerospike from Codebuild. Since Codebuild container's ip is not known, I can't specify an inbound rule in the security group attached to EC2. I've tried using amazon VPC as described here.
Can anyone help me get this working?
On the server node in EC2, open port 3000-3003 to all 0.0.0.0/0 (all ips) in the custom TCP rules- that should work.
I had EC2 server where I was running my existing application. The EC2 instance was on private subnet and ELB was created in public subnet with access to particular VPN IP. So whenever I was on VPN, I was able to access my application and if I am outside that VPN IP then I wasn't able to access the application.
Now I have created EKS cluster and I am deploying my application using kubectl with docker image of the application. Weird thing is the application works fine whenever I am NOT on VPN (I tweaked security group to allow all traffic from all IPs) and whenever I am on VPN, I receive "ERR_CONNECTION_RESET" in chrome and curl shows - empty response received from server.
Till now I have tried below things. As I am relatively new with EKS, I am not able to find much.
1. Same security group applied - Not resolving
2. Checked logs of all pods - whichever pods I received from "kubectl get po --all-namespaces" - No issues showing up
3. Checked /var/log/messages
4. Tried to change application port
5. kubectl get events not showing anything on why server is sending back empty response.
6. Tried to SSH to node and tried to curl localhost:30080 and it works fine, but when tried to curl from my machine (which is on VPN), it fails with empty response.
Please again note that, the application runs totally fine when I am outside VPN. Further my old application (that is on EC2) runs fine with VPN.
Thanks in advance!
Finally found the issue was with the corporate VPN which was blocking all ports other than 80 and 443. When I was creating the service, I wanted to have ELB to expose port 5000. So I was thinking elb-host:5000 will point to dev service nodeport which was 30080. This was perfectly working when I was NOT on the VPN. But when I was connecting the site using VPN, corporate traffic was blocking port 5000 on ELB. After I changed the port to 80, it started working as expected.
While using nginx, it was creating ELB with port 80 instead of my intended port 5000. I didn't notice that port change and thought that this is happening due to IP blocking.
Using the latest Robo 3T and the command line provided by AWS
mongodb://<dbname>:<insertYourPassword>#example-db.cluster-c2e1234stuff0e.eu-west-2.docdb.amazonaws.com:27017
I get this Error:
Reason:
SSL tunnel failure: Network is unreachable or SSL connection rejected by server.
Reason: Connect failed
I have also tried following THIS walkthrough but had no joy.
I have read that it is possible to SSH to a EC2 instance on the same VPC and access documentdb this way but ideally I would like to access it directly and not pay for an extra EC2 instance. If I have that right?
I have tried via Mongo shell too and get the following response:
Error: couldn't connect to server example-db.cluster-c2eblahblaho0e.eu-west-2.docdb.amazonaws.com:27017, connection attempt failed: NetworkTimeout: Error connecting to example-db.cluster-c2eblahblaho0e.eu-west-2.docdb.amazonaws.com:27017 (<IP address>) :: caused by :: Socket operation timed out :
connect#src/mongo/shell/mongo.js:344:17
#(connect):2:6
exception: connect failed
What I suspect is happening is that either you do not have an EC2 instance in the same VPC as your DocumentDB cluster or that EC2 instance is not reachable from your laptop. I'd first connect to the EC2 instance with SSH to establish connectivity and then use that EC2 instance to SSH proxy from Robo3T.
For context, Amazon DocumentDB clusters deployed within a VPC can be accessed directly by EC2 instances or other AWS services that are deployed in the same VPC. Additionally, Amazon DocumentDB can be accessed by EC2 instances or other AWS services in different VPCs in the same region or other regions via VPC peering.
The advantage of deploying clusters within a VPC is that VPCs provide a strong network boundary to the Internet. A common way to connect to DocumentDB from your laptop is to create an EC2 instance within the same VPC as your DocumentDB cluster and SSH tunnel through that EC2 instance to your cluster: https://docs.aws.amazon.com/documentdb/latest/developerguide/connect-from-outside-a-vpc.html
To minimize costs for local development, start with the smallest EC2 instance size and utilize the start/stop functionality when not using the cluster.
The same can be done with DocumentDB. When you are developing, you can save on instance costs by stopping the cluster when it is no longer needed: https://docs.aws.amazon.com/documentdb/latest/developerguide/db-cluster-stop-start.html
An alternative is to utilize AWS Cloud9: https://docs.aws.amazon.com/documentdb/latest/developerguide/connect-with-cloud9.html. This solution still requires an EC2 instance in the same VPC as your Amazon Document. What is useful about this solution is that Cloud9 provides a mechanisms to automatically shutdown the EC2 instance if it has been idle for 30-minutes, for example, to help save costs.