I'm new to Riemann and also new to ruby and Clojure as well.
When I implementation of the riemann command：
riemann-health
The error message is
Riemann::Client::TcpSocket::Error Could not connect to 127.0.0.1:5555:Errno::ECONNREFUSED: Connection refused - connect(2)
/var/lib/gems/1.9.1/gems/riemann-client-0.2.5/lib/riemann/client/tcp_socket.rb:233:in `connect_nonblock'
My develop environment is:
Ubuntu 14.04.2 LTS
riemann version is 0.2.10.
java version "1.8.0_45"
ruby 1.9.3p484
I'm assuming that you are running Riemann and riemann-dash on the same computer and not using docker for either of these:
Riemann listens to
port 5555 udp for events
port 5555 tcp for events
port 5556 tcp for queries
so there are several combinations of possible problems:
riemann is not running at all
riemann started up, and then fell over and died.
this happens when it has no config file for instance.
riemann is not listening on 5555 tcp
riemann is not listening on 5555 udp
riemann is listening to the incorrect interface (aka "bind address")
If riemann where configured to listen to 1.2.3.4:5555 then it would not respond to connections from localhost (127.0.0.1)
the connection is being blocked by some firewall (no, don't turn your firewall off)
riemann is listening on udp and you are sending tcp (or the other way around)
once you have convinced yourself that the riemann process is still running run
sudo netstat -nlp | grep 5555
and be sure you can see that riemann is infact listening to port 5555 both tcp and udp. Then install netcat and make sure you can connect to those ports with
nc -v localhost:5555
and
nc -uvv localhost:5555
asdfasfd
(yes you need to type some gobbeldy to get the second example to actually send a packet.
If you still havent got a connection install etherial or tcpdump and start sniffing.
If you are running docker, and using riemann in UDP then there are a whole other set of things to check.
Related
I've confugured Dante 1.4on Ubuntu 16.04 as a socks5 proxy for Telegram.
Chats are working, but voice calls are not, failing at "Connecting".
Is there something special I need to configure in order to proxy Telegram voice traffic?
I'm using a single non priveleged (>1024) TCP/UDP port + login + password for connection.
Thanks!
UPD: Thats piece of log while i am trying to call somebody:
Apr 15 23:05:38 (1523736338.510915) danted[22977]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.36562
Apr 15 23:08:33 (1523736513.020190) danted[22989]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.49065
I can answer the call at destination device but connection is looping and getting error after 30 seconds.
Proxying UDP with socks is a bit more complex than it might seem, so let's start from the beginning.
Telegram calls use UDP with socks. Socks5 RFC1928 defines the following sequence for relaying UDP:
Client instantiates a TCP socks5 connection.
Client sends a UDP ASSOCIATE request, containing the client's source address and port, which will be used to send UDP datagrams to the socks5 Server. They might be zeros (in Telegram they are) (section 4).
Socks5 Server binds a random UDP port for relaying datagrams for this TCP socks5 connection and sends a UDP ASSOCIATE response, containing the address and port where the client should send the datagrams to be relayed (section 6).
To send a datagram, the Client must add a header to the payload, containing a destination address and port, where the server should relay that datagram (section 7).
Server will keep the UDP port bound until the TCP socks5 connection terminates.
As you can see, opening a single TCP port is not enough. For UDP to work correctly, the automatically bound UDP port must be reachable by client. NATs and Firewalls might further complicate the situation.
UDP relaying configuration with Dante
Telegram calls are Peer-to-Peer, so the udpassociate command should be allowed to 0/0:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
# udp.portrange: 40000-45000
command: udpassociate
log: error connect disconnect
}
udpreply (that's for the actual relaying, the 4'th step above) should also be allowed to everyone as well:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
command: udpreply
log: error connect disconnect
}
If your socks5 Server is behind a firewall, open a range of UDP ports (say 40000-45000) and add the udp.portrange: 40000-45000 line to the udpassociate block (see the commented out example in the first point). Then Dante would bind UDP ports in that range only.
If your socks5 Server is behind a NAT, then the returned destination address in the response to UDP ASSOCIATE request would be a local IP, rather than the external one. That local IP is unlikely to be reachable by the client, so the sent datagrams would be silently dropped.
Unfortunately, Dante uses the destination address of the TCP connection as the one where the client should send UDP datagrams to (see the comment in the source code). NAT mangles this address from an external to a local one, so the Dante's assumption that the client can reach the proxy using that destination address is broken.
A possible solution, which doesn't involve patching Dante, would be to use iptables to change the destination address from a local to the external one (assuming that it's known and doesn't change):
# 203.0.113.12 – the external IP
# 1080/tcp - Dante TCP port
# 40000:45000 – Dante UDP portrange
iptables -t nat -A PREROUTING -p tcp --dport 1080 -j DNAT --to-destination 203.0.113.12
iptables -t nat -A PREROUTING -p udp --dport 40000:45000 -j DNAT --to-destination 203.0.113.12
# If external address is not added to any network device on that
# machine, then add it to the loopback interface, so the kernel
# would know where to route the DNATed packets:
ip addr add 203.0.113.12/32 dev lo
I had the same problem. Found the solution.
You have to add udpassociate bindreply udpreply commands to conf file. here is my conf file that works with voice calls.
logoutput: syslog /var/log/danted.log
internal: ip port = 1080
external: ip
socksmethod: username
user.privileged: root
user.unprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bind connect udpassociate bindreply udpreply
log: error connect
}
Allow clients' voice traffic
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: udpreply
log: connect disconnect error
socksmethod: username
}
iptables -A INPUT -p udp -m multiport --dports 1024:65535 -j ACCEPT
You should enable calls via proxy in your telegram settings.
I'm in the middle of installing and configuring an XMPP server, using ejabberd on Windows server 2012, running on an EC2 box.
I have opened port 5222 within windows firewall, and added to the security group for the EC2 instance
Custom TCP Rule
TCP
5222
0.0.0.0/0
ejabberd_c2s
Custom TCP Rule
TCP
5222
::/0
ejabberd_c2s
My XMPP logins are not working, and so I've turned to telnet to try and debug - it sees that port 5222 is reporting as closed:
PS C:\WINDOWS\system32> telnet hostname.com 5222
Connecting To hostname.com...Could not open connection to the host, on port 5222: Connect failed
Any guidance or steps towards debugging would be appreciated!
The issue here was in ejabberd's default configuration of "::" as an IP to listen, which forced it to listen only to IPv6.
By updating the ejabbed config to
port: 5222
ip: "0.0.0.0"
module: ejabberd_c2s
I was able to connect via telnet, and able to access the server using XMPP.
Using Add rule in windows firewall, I was able to open TCP port 15537. When i am trying to executing command netstat -ano on terminal windows, this port is not listed. I tried to execute telnet command on terminal window (e.g. telnet IP port) but getting
Connecting To localhost...Could not open connection to the host, on port 15537: Connect failed
Then I downloaded PortQry application and execute it from different machine, this machine is also in the same network, the result I received was
"Not Listening".
I already spent more than 2 days and asked internal group but could not find solution.
Note: both machines are having Windows 10 OS.
No solution is needed as no problem is indicated in the question. You have opened a TCP port successfully. You have not made any attempt to cause anything to listen to that TCP port.
It's not clear what results you expected, but you got the results that you should have expected. Nothing is wrong. The port is open because you opened it. Nothing is listening on that port because you didn't set anything to listen on that port.
There may be some forwarding rules? Since the purpose of access is not on the local machine, the netstat command cannot see the port on listening, but it can see the next action based on this port, usually to do some forwarding
I am not very familiar with windows firewall configuration, but I know that if there is a forwarding rule in linux, like
-p tcp -m tcp --dport 8080 -j {other forwading chain}
we can not see 8080 listening on this host (netstat -tunpl), but telnet host:8080 may see connected
Use nmap instead of netstat for detecting opening port
nmap -p your_port_number your_local_ip
Run service on that port
For eg- In my case,in order to open port,I use
"service ssh start" or "service apache2 start "and it's open port 22 and 80 for connection respectively in my linux machine.
On using nmap in my lan network both ports opened.
Hope it help
I have an EC2 instance which is running with the following security groups:
HTTP - TCP - 80 - 0.0.0.0/0
Custom UDP Rule - UDP - 1194 - 0.0.0.0/0
SSH - TCP - 22 - 0.0.0.0/0
Custom TCP Rule - TCP - 943 - 0.0.0.0/0
HTTPS - TCP - 443 - 0.0.0.0/0
However, when I try to access http://{PUBLIC_IP} or https://{PUBLIC_IP} in the browser, I get a "{IP} refused to connect" error. I'm new to AWS. Am I missing something here? What should I do to debug?
One way to debug this particular class of problem is to use netcat in order to determine where the problem lies.
If you run netcat against port 80 on the public IP address of your instance and just get a hang (no output at all), then most likely your security group isn't allowing traffic through. Here is an example from an EC2 instance that is in a security group that doesn't allow port 80 traffic inbound:
% nc -v 55.35.300.45 80
<just hangs>
Whereas if the security group is changed to allow port 80, but the EC2 instance doesn't have any process listening on port 80, you'll get the following:
% nc -v 55.35.300.45 80
nc: connectx to 52.38.300.43 port 80 (tcp) failed: Connection refused
Given that your browser gave you a similar "connection refused", most likely the problem is that there is no web server running on your instance. You can verify this by ssh'ing into the instance and seeing if you can connect to port 80 there:
ssh ec2-user#55.35.300.45
% nc -v localhost 80
nc: connect to localhost port 80 (tcp) failed: Connection refused
If you get something like the above, you're definitely not running a webserver.
I'm not sure if it's too late to help but I was stuck with a similar issue with my test server
SG Inbound: ssh -> 22
HTTP -> 80
NACL: default allow/deny settings
but still couldn't ping to the server from my browser, then I realize there's nothing running on the server that can serve the request, and I started httpd server (webserver) and it worked.
sudo yum -y install httpd
sudo service httpd start
this way you can test the connectivity if you are playing with SGs and NACLs and of course it's not the only way, just an example if you're figuring your System N/W out.
Have you installed webserver(ngingx/apache) to serve your requests. If so please share your the config files. (So that it will help to troubleshoot)
I think the reason is probably that you did not set up a web server for your EC2 instance, because if you try to access http://{PUBLIC_IP} or https://{PUBLIC_IP}, you need to have a background server to serve the http request as #Niranj Rajasekaran said.
By the way, by simply pinging the {PUBLIC_IP}, you could see if your connection to your EC2 instance is normal or not.
In command prompt or terminal, type
ping {PUBLIC_IP}
In my case, the server was running but available on just 127.0.0.1 so it refused connections from external hosts. To see if this is your situation, you can run
netstat -an | grep <port number>
If it says 127.0.0.1:<port number> instead of 0.0.0.0:<port number>, you have this problem.
Usually there's a flag or an argument in your server code somewhere to set the host to 0.0.0.0:
app.run(host='0.0.0.0') # flask example
However, in my case, I had already set this so I thought that couldn't possibly be the issue, which is how I ended up on this thread, which asks more generally about the problem. Unfortunately, I was using docker, and had set 0.0.0.0 on the container but was mapping that explicitly to 127.0.0.1 on the host in the docker-compose port-mapping:
ports:
- "127.0.0.1:<port number>:<port number>"
Changing that line to remove the host IP specification fixed the problem upon re-deploy:
ports:
- "<port number>:<port number>"
I have my Single node Hadoop installed on Google Compute Engine instance and i want to open port 50070 on that machine to access the hadoop dashboard. i configured in the firewall rule as tcp:50070 in compute engine networks. but still i am unable to access my port outside the network (ie . via internet). I tried nmap for the public ip of my GCE instance and i got a result which has only ssh port got opened all other ports are filtered .
Note: i am using debian 7.5 image
Make sure your daemon is listening on port 50070. If you have more than one networks in you project make sure the port is opened on the right network. You can run the following commands to check the information about your instance and network.
lsof -i
gcutil --project= getinstance
gcutil --project= listnetworks
gcutil --project= listfirewalls
gcutil --project= getfirewall
Check if IP/Port is allowed in iptables or not.
iptables -L
would show you all the records.
To allow port in iptables you can do the following:
sudo iptables -A INPUT -p tcp -m tcp --dport 50070 -j ACCEPT
sudo iptables-save -c
Short answer
In addition to configure the firewall rule at GCE web console make sure that your server is listening at 0.0.0.0 instead of 127.0.0.1
Long answer
In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs - Source
In contrast 127.0.0.1 is the IP address used to stablish a connection to the same machine used by the user this address is usually referred as the localhost.
It's often used when you want a network-capable application to only serve clients on the same host. A process that is listening on 127.0.0.1 for connections will only receive local connections on that socket. - Source
Hence, if you try to stablish a connection to your server from internet and your server is listening at 127.0.0.1 at your GCE machine, then, from the server point of view a request has never been received and as a consequence Goocle Cloud Firewall will refuse the connection because there is no server listening at the opened port (in your case 50070).
I hope this answer helps to solve your problem. Best regards.