Here is the story. Somehow the spotlinght does not work, called apple support. The conclusion after 2 hour conversation is to clean reinstall the system. I did that and restored everything using time machine.
BUT, the webserver does not work. If can still turn on the web server. But a browser can not load the page. Scanning the port of the server, seems ports 80 and 443 are not even detected. Any one knows how to solve it?
Port Scan has started…
Port Scanning host:
Open TCP Port: 22 ssh
Open TCP Port: 88 kerberos
Open TCP Port: 311 asip-webadmin
Open TCP Port: 445 microsoft-ds
Open TCP Port: 464 kpasswd
Open TCP Port: 548 afpovertcp
Open TCP Port: 625 dec_dlm
Open TCP Port: 631 ipp
Open TCP Port: 749 kerberos-adm
Open TCP Port: 3306 mysql
Port Scan has completed…
Related
Using the Client on HIVEMQ when I try to connect my mqtt server, I get the following error:
Firefox can’t establish a connection to the server at ws://xxx.com:8083/mqtt.
Connect failed: AMQJS0007E Socket error:undefined.
I'm using the following parameters:
Host: xxx.com
Port: 8083
Running Command mosquitto, I get the response:
[ 1615.745348]~DLT~ 1670~INFO ~FIFO /tmp/dlt cannot be opened. Retrying later...
1608926628: mosquitto version 1.6.9 starting
1608926628: Config loaded from /etc/mosquitto/conf.d/default.conf.
1608926628: Opening ipv4 listen socket on port 1883.
1608926628: Opening ipv4 listen socket on port 8883.
1608926628: Opening ipv6 listen socket on port 8883.
1608926628: Opening websockets listen socket on port 8083.
and My Mosquitto conf file is:
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 1883 localhost
listener 8883
certfile /etc/letsencrypt/live/burooq.com/cert.pem
cafile /etc/letsencrypt/live/burooq.com/chain.pem
keyfile /etc/letsencrypt/live/burooq.com/privkey.pem
listener 8083
protocol websockets
certfile /etc/letsencrypt/live/burooq.com/cert.pem
cafile /etc/letsencrypt/live/burooq.com/chain.pem
keyfile /etc/letsencrypt/live/burooq.com/privkey.pem
Looking for all port opened, I get:
To Action From
-- ------ ----
[ 1] Apache Full ALLOW IN Anywhere
[ 2] 22/tcp ALLOW IN Anywhere
[ 3] 22 ALLOW IN Anywhere
[ 4] 80/tcp ALLOW IN Anywhere
[ 5] 80 ALLOW IN Anywhere
[ 6] 443/tcp ALLOW IN Anywhere
[ 7] 443 ALLOW IN Anywhere
[ 8] 80,443/tcp ALLOW IN Anywhere
[ 9] 8883 ALLOW IN Anywhere
[10] 8083 ALLOW IN Anywhere
[11] 2222 ALLOW IN Anywhere
[12] Apache Full (v6) ALLOW IN Anywhere (v6)
[13] 22/tcp (v6) ALLOW IN Anywhere (v6)
[14] 22 (v6) ALLOW IN Anywhere (v6)
[15] 80/tcp (v6) ALLOW IN Anywhere (v6)
[16] 80 (v6) ALLOW IN Anywhere (v6)
[17] 443/tcp (v6) ALLOW IN Anywhere (v6)
[18] 443 (v6) ALLOW IN Anywhere (v6)
[19] 80,443/tcp (v6) ALLOW IN Anywhere (v6)
[20] 8883 (v6) ALLOW IN Anywhere (v6)
[21] 8083 (v6) ALLOW IN Anywhere (v6)
[22] 2222 (v6) ALLOW IN Anywhere (v6)
Mosquitto version 1.6.9
Ubuntu version 20.04.1 LTS
You can't use the IP address, you have to use the hostname that you got the certificate issued for e.g. burooq.com
The reason is that the browser will not be able to validate the certificate from the broker because it will not have an CN or SAN entry for the IP address.
You will also need to ensure that the firewall is configured to allow external access on port 8083
EDIT:
Also having just double checked the HiveMQ Websocket showcase page, it does not look to support connecting to a TLS secured MQTT over Websockets broker.
I had to create the file location for logs
$ mkfifo /tmp/dlt
change the listening port in your Mosquitto config file
$ vim /etc/mosquitto/mymosqui.conf
Listeners 8443
Restart Mosquitto:
$ sudo service mosquitto restart
Check the status:
$ sudo service mosquitto status
Check the ports if they are listening:
$ netstat -tulpn | grep mos
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 148132/mosquitto
tcp6 0 0 :::8443 :::* LISTEN
148132/mosquitto
I learned about SMB infomation from https://en.wikipedia.org/wiki/Server_Message_Block.
SMB use tcp 139/445 prot. And I check my server prot by lsof,SMB only listen 139 and 445 prot.
Then I try forward SMB port by Ngrok. This is my config:
tunnels:
http:
remote_port: 1122
proto:
tcp: 5000
smb:
remote_port: 139
proto:
tcp: 139
smb2:
remote_port: 445
proto:
tcp: 445
The http server is work. But SMB server not work.
Ngrok clone from https://github.com/inconshreveable/ngrok. Version is 1.7 and build by golang 1.12
Try with this syntax:
smb:
addr: 139
proto: tcp
smb2:
addr: 445
proto: tcp
You can read about ngrok syntax for tunnels in ngrok documentation tunnel definition.
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.
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>"
Settings of my security group on EC2
TCP
Port(Service) Source Action
22 (SSH) 0.0.0.0/0 Delete
80 (HTTP) 0.0.0.0/0 Delete
443 (HTTPS) 0.0.0.0/0 Delete
Output: When I run the telnet
JP$ telnet passionate4.net
Trying 50.18.159.124...
telnet: connect to address 50.18.159.124: Operation timed out
telnet: Unable to connect to remote host
on ubuntu ec2 server
ubuntu#ip-10-166-185-18:~$ sudo netstat -nup -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:68 0.0.0.0:* 400/dhclient3
Telnet uses port 23, you don't have it in your security group.
type this:
JP$ telnet passionat4.net 80
80, 443, 3389, or whatever port you're testing for.
Windows example:
C:/> telnet www.google.com 80