On Wed, 2021-12-15 at 00:37 +1000, Michael D. Setzer II:
> Just to clarify. dyndns.org only links my sites name to the
> public IP address I get from ISP. Has been the same exact
> IP for at least 2 years, but is a static one?? But works
> fine.
If they don't advertise it as static ("that's a feature!") it probably
isn't. It's highly likely that they set the lease on the IP with a
reasonable time period so that you're going to get the same IP if you
temporarily disconnect for a short period. You may get the same one if
you disconnected for a longer period, but there's probably some time
period where you lose the lease and get a different IP.
At one stage my ISP would give you the same one unless you disconnected
for quite a lengthy period, now it's only a few minutes. I suspect
that may be due to how they tell customers who complain about network
faults to reboot and reset everything, and hope that by the time they
reconnect they end up with a different address that goes slightly
different through their network, and the fault goes away (for that
customer) without the ISP actually having to do anything.
> On my internal network, I can connect to the server using
> https and it does on port 443 just fine, just gives a
> message about the certificate isn't confirmed by a 3rd
> party??
Common enough with cheap or free certificates. You generally have to
pay to get a pre-approved one.
> But otherwise works. Checked my router, and I have port
> 8081 mapped from the outside to the inside port 8081 on
> machine (how httpd setup). and it works fine. port 80 is
> blocked by ISP??
Many ISPs block customers running services. They'll either charge
extra for the feature, or simply don't want to deal with the headaches
that badly managed servers can wreak.
> Also, found I have port 8443 mapped to 443 on machine, but nothing
> gets thru, so assume that port is blocked. Sent message to ISP, but
> they haven't gotten back?
443 is the only standard port used for HTTPS. Although some nerds may
suggest that 8443 is an alternative HTTPS web browsing port, it is not.
The numbers don't suggest purpose (i.e. something with 443 in it,
somewhere, is not HTTPS because of those numbers, and something
starting with 8 is not web-related because of those numbers). While
computer users might like to pick them for human-obvious reasons,
there's nothing even semi-official about it.
As with port 80, ISPs do various things to other common port numbers,
to allow or deny services for their clients. You can try non-standard
ports, they may allow them through, web-browsers may allow them. See
how your browser fares trying to connect to other ports internally,
then you can try using them externally. You might have to go higher
up. But some ISPs inspect packet content, regardless of port, and will
mess up any kind of HTTP traffic coming into you (which also can
disrupt things like file transfers in instant messengers, ICQ, MSN,
Jabber, and others, since they often use the same hyper-text transfer
*PROTOCOL* to do the work).
There are lists of well-known and registered ports. They don't
absolutely reserve ports for specific functions, but traditionally
certain services use certain ports, and can be expected to be found
there. When you use other ports, you have to be able to either include
them in the address, or somewhere in the configuration. And be
prepared to deal with conflicts.
Ports 0 to 1023 are the most well-known ports, and your own operating
system networking will often require special privileges to be able to
use services on them (e.g. an ordinary user can't run the mail server
in their own account, on the standard mail server port numbers, it
needs a server kind of account).
Ports 1024 to 49141 have a lot pre-registered uses, and if I remember
correctly, Linux won't restrict ordinary users from using them. Though
you might have to manually twiddle firewall and SELinux rules (well, I
say "might" but in a security concious installation, you almost
definitely will have to manually configure something allow it).
Ports 49152 to 65535 are known as dynamic, private, or ephemeral ports,
with no specified use (though there are some applications which are
known to make use of some of these, they're not reserved for their
exclusive use). They are expected to be used at the whim of any
software communicating across a network. Though, again, to run a
server on them you *might* (but probably will) have to manually twiddle
your firewall and SELinux rules.
e.g. When you browse a webserver on port 80 (the server's port 80),
your end will use one of these ephemeral ports to connect to their port
80. Depending on your OS there will be some scheme as to how it picks
them. I've used far too many OSs over the decades to remember which
ones do what. They might start at the lowest un-used one and work
upwards, or the highest free one and work down, or pick at random (as a
privacy or pseudo-security technique of making your computer's
networking more unpredictable to miscreants).
I'm not sure how well different OSs handle you trying to run a service
on a port number that they might expect to be able to use by their
choice, but a TCP/IP stack ought to be able to determine whether a port
is in use by *something* and not try to double-up on it. Anything that
doesn't check and just blithely assumes it can do what it wants is
bound to have some kind of failures. If you were running multiple
servers (web servers, peer-to-peer, etc), it'd be your responsibility
to set each one up to work in different ranges.
Since you're experimenting for your own purposes, there's no reason why
you can't just try some random high port number and see what happens.
NB: Anywhere I've said that your ISP or OS may impose restrictions on
the use of port numbers, remember that your modem/router might impose
its own limitations, too.
> Give the address as sitename:8081 with http, but don't
> know if browser is changing it to https somehow?
If the browser has a HTTPS everywhere plugin, or built-in, feature,
that could be the cause. But they really should allow a HTTP fallback
when HTTPS doesn't work. Though, I suppose, even that could fail if
the webserver gives some kind of initial response, so the browser
doesn't try falling back. Akin to how years ago many websites
complained you had JavaScript turned off if you didn't accept a cookie,
or vice versa, instead of testing cookies with cookies and scripting
with scripting (programmers making dumb assumptions).
I'd read, elsewhere, about Google Chrome enforcing HTTPS with certain
domain names (e.g. with ".dev" top-level-domains).
As I've said, I'm not pleased with the HTTPS-everywhere push, it's not
always appropriate, and programmers are notorious for making dumb
assumptions.
--
uname -rsvp
Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
