I am getting this error when I am running any "consul members" on consul server and clients. The port is in LISTENING state and I made sure there is no firewall blocking. I get this error when in run the same in the consul client:
Error retrieving members: Get http://127.0.0.1:8500/v1/agent/members:
dial tcp 127.0.0.1:8500: connectex: No connection could be made
because the target machine actively refused it.
When I make the above request with the private IP, I get the required output. Can I change the configuration anywhere so that it listens on the private IP for requests?
It seems that your consul members lacks the option -http-addr=....
Example
consul members -http-addr=10.10.10.10:8500
while assuming you use the standard port 8500 of the consul agent and that you started consul via:
consul agent -client=10.10.10.10 #...
Where to find the documentation?
In the Consul Documentation under Running an Agent: "Client Addr":
If you change this address or port, you'll have to specify a -http-addr whenever you run commands such as consul members to indicate how to reach the agent.
Or offline via consul members -help:
http-addr=<address>
Theaddressand port of the Consul HTTP agent. The value can be
an IP address or DNS address, but it must also include the port.
This can also be specified via the CONSUL_HTTP_ADDR environment
variable. The default value is http://127.0.0.1:8500. The scheme
can also be set to HTTPS by setting the environment variable
CONSUL_HTTP_SSL=true.
Related
Here is what i have:
GCP instance without external IP (on VPC, and NAT), and it accepts HTTP HTTPS requests
firewall allows ingress TCP for 0.0.0.0 and also for IAP's IP 35.235.240.0/20 on all ports for all instances
I ssh to the instance via IAP and run the application in the terminal on port 5000 and 0.0.0.0 host and leave the terminal hanging, but when I connect in parallel through cloud shell and ssh to this instance through IAP, and then click on web preview on port 5000, I get "Couldn't connect to a server on port 5000".
I have said that it could be a firewall rule blocking IAP, so that's why I gave access to all ports for IAP (for testing)
P.S: the process has been done on a VM with external IP and it got validated ( but without the need to connect to cloud shell to do web preview, I checked the UI with IP:port in the browser )
What did I miss?
You may be following the guide on Building Internet Connectivity for private VMs and this part on Configuring IAP tunnels for interacting with instances and the use of TCP Forwarding in IAP. By Tunneling other TCP connections:
"The local port tunnels data traffic from the local machine to the remote machine in an HTTPS stream. IAP then receives the data, applies access controls, and forwards the unwrapped data to the remote port."
You can create an encrypted tunnel to a port of the VM instance by:
gcloud compute start-iap-tunnel INSTANCE_NAME INSTANCE_PORT \
--local-host-port=localhost:LOCAL_PORT \
--zone=ZONE
I guess you want to use INSTACE_PORT and LOCAL_PORT the same, 5000.
Be aware of it's known limitations.
I have kolla-ansible openstack ussuri cluster . It used to works well. Accidently, the metadata service cannot be accessed by instance. The keypair in openstack not imported to the instance. I checked the instance log. I found this warning:
[WARNING]: No active metadata service found
I checked the neutron_metadata_agent is running.
I tried curl http://169.254.169.254/openstack from running instance that has been created before this issue
ubuntu#test-vm:~$ curl http://169.254.169.254/openstack
curl: (7) Failed to connect to 169.254.169.254 port 80: Connection refused
here is the ip route inside the instance
ubuntu#test-vm:~$ ip ro
default via 172.30.0.1 dev ens3 proto dhcp src 172.30.255.102 metric 100
169.254.169.254 via 172.30.255.3 dev ens3 proto dhcp src 172.30.255.102 metric 100
172.30.0.0/16 dev ens3 proto kernel scope link src 172.30.255.102
Could somebody help me out? thanks for your help.
The actual metadata service is hosted by the Nova API. It listens on port 8775/TCP either directly or there is a separate vhost configuration if Apache is used as e.g. TLS proxy. The Neutron metadata agent just acts as kind of forwarder between the instance and the actual metadata service.
This graphic depicts the communication flow (for Train though, but probably still the same for Ussuri).
I suggest to check whether Nova API is still listening to port 8775/TCP and if so, try to debug the communication flow in the graphic. Also check the security group of your instance. Maybe your default security group is broken.
I'm running a Node app on a HTTP instance with Debian-8 and only can reach my app via port 8080 which my node server is running on. If I remove the port and try to access through port 80, then I get a refused to connect error.
I've allowed tcp:80 to all targets in Networking -> Firewall Rules and also verified that my iptables are open in Debian. Any ideas?
Resolved - My port forwarding was not set property in Debian.
I have got chef-server installed on a centos machine.
Everything is working as expected except that I cannot access the chef-server web interface from another machine on my local network.
I can access the web interface from the centos machine itself:
telnet mychefserver.local 4000
Connected
If I do the same from my machine I have got:
telnet: Unable to connect to remote host: No route to host
I can successfully ping mychefserver.local from my machine
Any idea how to configure nginx with chef-server to access the chef-server from the network?
Since Chef Server 10, the web interface uses normal HTTPS (TCP 443), it only listens on the high ports locally, and nginx proxies as needed to the different backend services. I would try with a normal web browser as telnet isn't exactly great at error messages. Normally I would expect that to mean telnet is getting TCP transmission errors, but maybe it is just confused? If it is really a TCP transmit error then more likely the internal DNS is having issues. .local often means mDNS which has uneven support in some places, I would try an actual IP address to be sure.
My issue was iptables.
I stopped iptables and I can access the chef-server from my local network again.
I can't access remotely my postgre database. My fellow is making a QT project that access the database from my web-server. It's very close to the problem from this guy: Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432?
And with some research in google, all solutions point to set the listen_addresses property in postgresql.conf like this:
listen_addresses = '*'
and in pg_hba.conf add this line in the IPV4 connections
host all all 0.0.0.0/0 trust
I've already done it, and also have created an exception in ufw
5432/tcp ALLOW x.x.x.x.x
when x.x.x.x is the ip I want to give access.
I've also tried some variants to the configuration above ,like
listen_addresses = 'localhost, x.x.x.x'
and
host all all x.x.x.x/32 md5
The error message of the linked question happens only when trying to connect locally. That's what ...running on host localhost... means.
When connecting to a remote host, the client doesn't set localhost in the host field, but the IP address or name of the remote machine (well, unless using a SSH tunnel but it's not mentioned here).
Otherwise please indicate the exact connection parameters of the client and the exact error message.