Those of you who are familiar with me know that I love to toss NAS, and I run a lot of services in my NAS at home. As a family of geeks, most of my use is through the routing side of the intranet address to jump to use, and did not pay attention to the access status of the public network. Recently, however, one day, I suddenly went out and found that these services on the NAS could not be accessed through the public network.
I found out the reason is that port 443 of IPv6 is blocked, and in the past, IPv6 was not blocked for 443 in my city. I thought it was a phased blocking of ports and would be unblocked after a while, however, more than a month has passed and it still hasn’t been unblocked, so I’m afraid it won’t be unblocked for quite some time.
Lucky.
In the past, my service on the NAS has been realized through DDNS-Go + Ngnix Prosy Manager. I experienced Lucky Daikichi when I tossed iStoreOS on my Lab machine some time ago, and this time I plan to formally apply Lucky to the NAS as well. I’m not the only one who uses the network at home, and there’s a history of being criticized by the whole family because of something going wrong with All In One. So I have all my services on the NAS now, and the routing will just be routing.
Lucky Daji is based on DDNS integrated reverse proxy solution, support for many domain name service provider platform, also through the API and key management (I believe that friends can see here, must know how to apply for API and key), but its management background design is more humanized, a variety of processes are also more intuitive. ssl certificates are also managed individually, more suitable for the use of national I’ve used CloudCloud myself. I myself have used CloudFlare’s 15-year certificate, so long cycle, or very worrying.

Of course the biggest problem is still the port issue. Because I’m a lazy person, I only set up one external listening port when shadowing ports through Biggie, and the various services are differentiated by secondary domain names. The reverse proxy service addresses on the NAS are prefixed with nasx.

source rules
Although a port is better to remember, through the domain name plus port can also be used. But as a slightly obsessive-compulsive have bacteria, always feel very awkward, so also have been looking for ways to realize the public port jump. Before in the big mom also have seen other friends write, through the redirection rules and source rules to realize the way, but let a person more helpless is the free version only 10 redirection and 10 source rules to use the authority.

In the course of my attempts, I found that the source rule has an option to match “SSL/HTTPS” to point the default port 443 to the specified port of the service host, which is literally customized for my current situation.

CloudFlare’s source rules are very user-friendly and can be used to create a variety of complex judgment combinations through “And” and “Ro” to adapt to various situations. If there is only one host in a single network segment, it can be judged by the IPv6 segment, which does not need a prefix and is easy to remember. But I have other hosts under “2408”, so I chose the prefix way to do the judgment, the services on the NAS are in the second-level domain name added “nasx” as a prefix, this setup ensures that the other hosts under the main domain name will not conflict with the second-level domain name. This setting ensures that the other second-level domain names under the primary domain name will not conflict with each other.

Of course the little yellow cloud in DNS must be turned on, or it will not take effect.
utilization effect
After these settings, you can access your own private service directly with just the domain name, no problem for either browsers or clients. However, it is important to note that the actual port for accessing through the domain name is 443, not a customized port. For remote Aria downloads or remote database access, the port needs to be 443. For remote desktop access, the domain name can be used to connect directly without a port.
In practice, the DNS access through CloudFlare is a bit slower than AliDNS with port resolution, but it is more stable. In the course of my business trip, I found that some cities through the Ali DNS access will fail, but CloudFlare is not a problem. I haven’t tried Tencent’s DNSPod or Volcano, and I don’t know if other platforms in China support this kind of source rule, so I’d like to hear from those who have used it.