everyone. I want to configure cassandra on ec2 to accept remote connection from main OC (using datagrip) so i have a couple of questions. What IP should i use for rpc and listen address? public EC2 ip? What port should I use? default or for rpc? I'm a little bit confused here. Thx in advance.
Basically, the rule of thumb is following:
if applications & other nodes are only in the same region, then you can use private IP address for both listen & rpc addresses
if applications are outside, or there are other data centers in the other regions, then you set listen to private IP address, broadcast to the public IP, rpc could be set to 0.0.0.0, and broadcast rpc address to public IP
there is a plenty of documentation available on that topic - just search for something like "cassandra ec2 configuration"
Related
I am setting
listen_address: private IP (gets translated by AWS to public IP, whether I ask it to or not)
broadcast_address: public IP
rpc_address: 0.0.0.0
I'm not able to do this because of that automatic NAT'ing stuff being done by AWS Elastic IP. Cassandra refuses to start, claiming that I need to specify an address that I can bind to (e.g. my private IP), and instead giving me the public, elastic IP as my 7000 port listen_address setting.
..but I did this. And it translated to public anyway.
I tried dual-homing it, but I can't even talk to the private IP on the second NIC, so I'm kind of stuck.
Is there a workaround for this elastic IP translation?
Thanks!
Client connections rely on rpc_address. You'll need to set the following as a starting point:
listen_address: private_ip
rpc_address: public_ip
If nodes are distributed across regions and using Ec2MultiRegionSnitch set:
broadcast_address: public_ip
so nodes can communicate with nodes in another region. Cheers!
I'm trying to launch a simple socket server on Amazon Web Services, but I get an error message when trying to bind the socket like this:
var s:Socket = new Socket();
s.bind(new Host("Public AWS image IP here"), 5000);
The error is std#socket_bind exception. What am I doing wrong? Am I misusing IP address or do I need to open 5000 port? I'm a complete beginner.
UPD: I've changed IP address to 0.0.0.0, the server has started successfully, however, a client still can't connect to server:
s.connect("AWS Public IP", 5000);
But why? As I have figured out, binding to 0.0.0.0 should bind the socket to all of IPs available and there is a rule in my AWS console to allow all the connections to port 5000
If you are trying to bind the EC2 Public IP, you cannot as the public IP is not assigned to your network interface. You would bind the private IP address. The EC2 instance does not know anything about the public IP address assigned "logically" to it.
The AWS Internet Gateway (IGW) is a special type of 1 to 1 NAT gateway for public to private address mapping. This means that the public IP address is assigned to the public side of the gateway and not to your EC2 instance. Your EC2 instance receives a private IP address and this is the address that you can use in your bind() call.
However, the better choice is to bind 0.0.0.0 as this means bind to all network interfaces.
I am relatively new to AWS and I've been looking at quite a few tutorials for the past couple of days trying to figure out how to make my AWS ubuntu instance accessible from the browser.
What I've done:
1st: I configured security groups to accept all traffic for ssh, http, https just to see if the public DNS listed in the instance is accessible.
2nd: I changed the IP of my instance to an elastic IP
3rd: I wrote a simple node.js file that listens on port: 9000 and console.logs 'hello world'
For some reason ssh works, and I can run my node.js file, but agina I cannot access the remote instance from the browser.
Any help would be greatly appreciated since I've been on this for a couple of days
Thanks!
Thank you everyone for the quick responses!
My issue was I did not include a TCP rule to my specific port. Now I am able to access that port via ec2-DNSNAME:9123.
And, just to clarify, if I want to host that DNS for all traffic I should specify 'anywhere' for the TCP rule, correct?
I configured security groups to accept all traffic for ssh, http, https
In security groups, "HTTP" does not mean "HTTP on any port"... it means "any traffic on TCP port 80" -- 80 being the standard IANA assigned port for HTTP.
Security groups are not aware of the type of traffic you are passing, only the IP protocol (e.g. TCP, UDP, ICMP, GRE, etc.) and port number (for protocols that use port numbers) and any protocol specific information (ICMP message types).
You need a rule allowing traffic to port 9000.
Firstly go to your EC2 and see if curl http://localhost works..
Also, if you are exposing your nodejs on port 9000 ; did u open 9000 also on security groups or not ?
Few things to check:
Security groups
Subnet NACLS (these can function as a subnet level
firewall, but unless you've messed with these they should allow all
traffic.)
On the server if you run netstat -na | grep <PORT> do you see your
application listening on the correct ports?
You may also check your system for a firewalls that could be short circuiting the requests.
If the above doesn't point you towards where your issue is you can grab tcpdump and filter it just for requests coming from your web browser (e.g after installing tcpdump -vvn host 10.20.30.40 port 8000 Substitute your ip and port). This will let you know if you're running into a network issue (Packets aren't reaching the server) or if its something with the app.
I'd also recommend using IP addresses while doing your initial troubleshooting. That way we can establish it is not network/server configuration before going into DNS.
Thanks to everyone in advance -
I have an ec2 instance with the following network config:
eth0 - internal-ipaddressA
eth1 - internal-ipaddressB
public-elastic-ipddressA associated with internal-ipaddressA
public-elastic-ipddressB associated with internal-ipaddressB
I configured sshd to listen on both these addresses explicitly:
internal-ipaddressA
internal-ipaddressB
I can ssh to public-elastic-ipddressA and then ssh to internal-ipaddressA AND internal-ipaddressB, just to make sure sshd is working correctly on both addresses.
All that said, I am unable to ssh to public-elastic-ipddressB if it is associated with any other network interface besides the primary, which was created by default when the instance was started.
Am I missing some sort of special routing or ACL/security configurations here?
Thanks!
Sam
The sshd process is probably bond to the first adress.
You should look at /etc/ssh/sshd_config. The ListenAddress propeties contains the adress it listen to (man page).
The adress is probably first set by Cloutint.
It's a routing problem. You need to put each network interface of the instance in a different subnet of the VPC or the packets won't be routed back from the instance to the destination.
Other solution is to assign two internal IPs to the same network interface, and then configure them in the OS as eth0 and eth0:1, but this won't achieve your objective.
I have created a VPC with public and private subnets on AWS. All app servers are in private subnets and all outbound requests have to be through an internet-facing NAT instance.
At the moment, our project requires the app servers to access a ftp server provided by a service provider.
I have tried several ways to manage that, but all no luck. What I have done was to open a port range, let's say (40000 - 60000) on both NAT and APP security groups, also standard ftp ports 20 - 21 as well.
The user authentication can be passed, but I could not list contents from app servers.
I am able to access the ftp server from NAT, not problem at all.
So what should I do to make it work?
#JohnRotenstein is absolutely correct that you should use Passive FTP if you can. If, like me, you're stuck with a client who insists that you use Active FTP because their FTP site that they want you to connect to has been running since 1990 and changing it now is completely unreasonable, then read on.
AWS's NAT servers don't support a machine in a private subnet connecting using Active FTP. Full stop. If you ask me, it's a bug, but if you ask AWS support they say it's an unsupported feature.
The solution we finally came up with (and it works) is to:
Add an Elastic Network Interface (ENI) in a public subnet on to your EC2 instance in the private subnet
So now your EC2 instance has 2 network adapters, 2 internal IPs, etc.
Let's call this new ENI your "public ENI"
Attach a dedicated elastic IP to your new public ENI
Let's assume you get 54.54.54.54 and the new public ENI's internal IP address is 10.1.1.10
Add a route in your operating system's networking configuration to only use the new public ENI
In windows, the command will look like this, assuming the evil active ftp server you're trying to connect to is at 8.1.1.1:
route add 8.1.1.1 mask 255.255.255.254 10.1.1.1 metric 2
This adds a route for all traffic to the FTP server at 8.1.1.1 using subnet mask 255.255.255.254 (ie. this IP and only this IP) should go to the internet gateway 10.1.1.1 using ethernet adapter 2 (your second NIC)
Fed up yet? Yeah, me too, but now comes the hard part. The OS doesn't know it's public IP address for the public EIN. So you need to teach your FTP client to send the PORT command with the public IP. For example if using CURL, use the --ftp-port command like so:
curl -v --ftp-port 54.54.54.54 ftp://8.1.1.1 --user myusername:mypass
And voila! You can now connect to a nightmare active FTP site from an EC2 machine that is (almost entirely) in a private subnet.
Try using Passive (PASV) mode on FTP.
From Slacksite: Active FTP vs. Passive FTP, a Definitive Explanation:
In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.
Thus, the traffic is trying to communicate on an additional port that is not passed through the NAT. Passive mode, instead, creates an outbound connection, which will then be permitted through the NAT