I encountered some issues while forwarding internal network devices, and I will provide an example to illustrate.
Define two domain names, testaaa.com and testbbb.com
I added 2 domain names to the Address Lists on the IP/Firewall page, but both domains actually point to the same public IP address testaaa.com → a.b.c.d testbbb.com → a.b.c.d
According to my idea, requesting testaaa.com: 8000 will result in data of 192.168.88.248:8000, while requesting testaaa.com: 9000 will result in a request failure
But now I request testaaa.com: 8000 to obtain a result of 192.168.88.248:8000, and request testaaa.com: 9000 to obtain a result of 192.168.88.247:9000
How should I configure the rules now so that when requesting testaaa. com: 9000, there is a prompt stating that it cannot be found
You have two domains pointing to a same IP address.
When you src-nat and dst-nat to your local network you are using the two domains, but they will both be resolved to the same a.b.c.d IP address, wouldn’t they?
It’s not possible, connections work only with numeric addresses, they don’t see hostnames. Hostname may come later in some protocols, but for NAT it would be too late anyway, even if router understood it.
You need a „reverse proxy“ to do domain name to ip matching. This is done by nginx for example.
„Reverse proxies can inspect HTTP headers, which, for example, allows them to present a single IP address to the Internet while relaying requests to different internal servers based on the URL of the HTTP request.“
If DNS A records for server1.domain1.tld and server2.domain2.tld point at same IP address (and standard ports are in use), then L3/L4 firewall (which is what ROS runs[*]) can’t distinguish between requests for both servers. L6/L7 device is required for that and that’s exactly what reverse proxies are.
And this condition is set forward by @OP in opening post.
[*]It is possible to configure some L7 functionality in firewall (not in NAT though) … but since the L7 functionality can kick in pretty late in communication between client and server, this functionality is only useful to break connection. So not really useful to do the selective port forwarding.
The “late” part of the previous sentence is the “fourth” (or even later) part of TCP handshake, the first 3 are only connection establishment without any payload exchanged … and that handshake goes between client and server (it can be reverse proxy if one is used) and at this point NAT destination has been already chosen. When in 4th part client includes server FQDN (either plain-text for HTTP or SNI for HTTPS - when TLS 1.3 is used, not even this is plain text), it’s too late for router to redirect TCP connection to another back-end server.
Reverse proxies, OTOH, handle whole connections toward clients but select appropriate back-end servers according to client’s request (can be according to host-name, per port, can even be per path name). They only pass payload between client and back-end server. They do the SSL on their own (SSL certificate is installed on reverse proxy, back-end server can speak plain HTTP or HTTPS with same or different certificate), etc.