"Open" and "Closed" are a bit vague, as you have at least 3-5 distinct "doors" that may be open or closed – the ISP's firewall, your router's firewall (and port forwarding), your server's firewall, and finally whether your server is currently running any service that is listening for connections on that port. Merely setting up a port-forward rule on your router is therefore not enough for it to be "open" all the way through.
How to start diagnosing to find where the issue is exactly?
Run a packet capture, e.g. Wireshark (GUI) or tshark/tcpdump (CLI), while doing the port check. This will tell you whether the packets reach your system.
tcpdump -n -i eth0 "port 8092"
tshark -i eth0 -f "port 8092"
If you see the packets arriving at the server and being ignored, the problem is likely with the server's firewall. (ufw is not the only firewall; in fact it's just a tool to auto-configure iptables, and it's possible to have iptables rules loaded without ufw being active.)
If you see the packets arriving and a TCP 'RST' reply going out, the firewall is okay but the server isn't running any service that would accept connections on that port.
If you don't see any packets, they are getting blocked either by your router or by your ISP. These days it's very common for ISPs to be the problem – see the other point.
Make sure your router has a public IP address. What external systems see about you (e.g. what your DDNS provider sees, or what a "What's my IP" website sees) is not necessarily the address that actually belongs to your system.
That is, go to your TP-Link router's "WAN Status" page (or similar) and find the WAN IP address assigned by your ISP.
If the address shown there does not match the 103.228.222.115 address shown by the DDNS provider, it means your connection is behind CGNAT (i.e. a second layer of NAT done by your ISP) and your own port-forward rules won't be able to do anything.
the WAN IP and external IP address are not matching.
That means CGNAT, i.e. ISP-level NAT.
99% of the time, CGNAT is set up in a way that prevents customers from receiving any inbound connections.
Sometimes it's because the ISP does "Many:1" NAT and the public IP address is shared between multiple customers (just like your own router's NAT shares its address between multiple devices). Sometimes it's "1:1" NAT but with very short-term IP assignments – potentially too dynamic even for DynDNS to handle – and so the ISP just deliberately doesn't set up any inbound translation.
The workarounds are:
Call your ISP and ask if they could assign you a public IP address (or a "static IP" as many ISPs bill it). Some ISPs will do that for $1/mo, some ISPs won't.
If the ISP won't give you a dedicated public IP address, the other option is to use a VPN that gives you one. (Either a commercial service, or set up your own through a cheap VPS.)
If the services are only for your own remote access (i.e. not necessarily public), there are many more VPN options that will do the job, provided that you're fine with installing the VPN client on your phone/laptop/etc. Tailscale or ZeroTier would do.
Additional thing to note here is, the UDP port 20595 was forwarded as part of hosting Multiplayer match in 0AD game and it worked perfectly fine back then (May be about 8 years ago).
Not relevant, because it was 8 years ago – your Internet connectivity relies on an external factor (your ISP's network configuration) which could have changed multiple times over those 8 years.
Indeed many ISPs have deployed CGNAT over the past 8 years, to the point that this is practically a weekly question on this site. (and I keep posting answers thinking "I'll write a general answer that I can use for close-as-duplicate in the future" but end up writing new answers again regardless...)
