On Sun, May 29, 2022 at 05:41:59AM -0500, Tom Browder wrote: > On Sat, May 28, 2022 at 20:06 IL Ka <kazakevichilya@gmail.com> wrote: > ... > > 3. You should also check that Apache is running and listening to this port, > > use ``ss -lt``. > > For this command you _may_ use sudo to get process names (``sudo ss > > -ltp``). Read ``ss --help`` > > > > If you were able to connect on this host, then try to connect to this > > machine from outside using public IP > > > > I can ssh in to the remote host. Then I tried telnet to port 80 on the same > host from the outside with the public IP and got no good response: > > $ telnet x.y.z.w 80 > Trying x.y.z.w... > telnet: Unable to connect to remote host: No route to host I may be off, but I think a firewall shouldn't do that [1]. It can lead to a "connection refused", which amounts to replying with a RST, which corresponds to the REJECT treatment, and it can just not answer, which leads to a timeout, corresponding to DROP. What you are seeing is some router in the middle telling you it doesn't know which way this x.y.z.w is (with an ICMP "Destination unreachable"). Of course this can happen at your workstation, but then it'd be quite probable you can't access x.y.z.w with ssh either. Firewalls can be configured to lie [2] in this way, alas. It very much looks like your provider has a firewall between your rental host and the rest of the world. But take all that with a grain of salt or two. Cheers [1] and I believe your Linux firewall won't do that by default. You'd have to tell it so. [2] Now destination port unreachable would be less of a lie, no? -- t
Attachment:
signature.asc
Description: PGP signature