Preface
Due to the fundamental differences between the IPv6 and IPv4 protocols, in the future trend where IPv6 public IPs become mainstream, some long-standing traditional technologies that existed on IPv4 have lost their utility: such as port forwarding, NAT, etc. In the home data center IPv6 public IP egress solution that I am currently conceiving, some of these functions (such as port forwarding) require similar alternative technologies. After all, although IPv6 addresses are infinite, I cannot allow every device at home to be directly exposed to the public network. From a security perspective, exposing a single point and then accessing other points through this point is a more normal logic, and it is also more conducive to the formulation of security policies.
To achieve the above functions, an upgraded alternative to traditional IPv4 port mapping technology is required: the IPv6->IPv4 port forwarding function. Unfortunately, currently, apart from OpenWrt which can achieve this by installing Lucky or socat, I haven't seen any other routers that support it (actually, strictly speaking, OpenWrt doesn't natively support it either, it just allows installing software that supports it). In addition, not many people use OpenWrt as their main router nowadays (though there are quite a few using it as a "bypass router"). Therefore, before routers officially support this function, the main protagonist of my IPv6 egress solution might have to change...
This article will take the Docker version of Lucky, one of the main protagonists of the solution, as an example to introduce the main functions of Lucky.
Setting up Lucky
Deploying Lucky
First, as a side note, just as I mentioned in my previous article (see:OpenWrt Soft Router Series: Discussion on the Best Way to Use the Docker Version of OpenWrt): ”I think the Docker deployment method is best suited for applications that provide content to the outside (such as Nginx, MySQL), rather than those that need to frequently access the external network from inside the container (such as Lucky, cloudtunnel, OpenWrt)“, especially for Lucky, which also involves IPv6->IPv4 conversion and heavily relies on the underlying operating system. The author of Lucky has made similar statements:
Therefore, if you really want to use Lucky as your main tool and run high traffic, other non-Docker deployment methods are more recommended. Of course, for light use, the Docker method is also fine, just try to deploy it using the host mode.
The code to set up Lucky using the docker run format is very simple, as follows:
docker run -d --name lucky --restart=always --net=host gdy666/luckyInitializing Lucky
Use linkhttp://宿主机ip：16601Log in to the Lucky console, the default username and password are both "666":
Configuring Lucky functions
Dynamic Domain Name
Lucky's built-in supported domain names basically cover common domain name providers (iKuai only supports 6~~), and it also supports customization:
And it supports multiple ways to obtain the IP address:
Among them, the last method of obtaining via odhcpd is a good match with OpenWrt (OpenWrt's IPv6 function is implemented through odhcpd).
Note: The way dynamic domain names obtain public IP addresses in IPv6 is different from that in IPv4. In IPv4, it is actually obtained by accessing an external page to get its own public address (except for dynamic domain names running on routers, which directly correspond to the WAN port IP), while IPv6 is more flexible. It can be obtained either through an external page (such as the first method in the figure above) or directly from its own address (such as the 2nd and 3rd obtaining methods in the figure above). Actually, I highly recommend the 2nd method, which is obtaining it through its own network card. However, one thing to note here is that the network card has both private IPv6 addresses and public IPv6 addresses. To ensure accurate identification, you can add IP selection matching rules:
Since I use China Telecom broadband, and Telecom's IPv6 starts with 240e, I added "^240e" so that it won't be misidentified. I have encountered situations where, without adding IP selection matching rules, the dynamic domain name would sometimes be identified as a private address starting with fe, which caused me to spend a long time troubleshooting~~~.
There is also a special case, which is obtaining the IPv6 addresses of other devices on the intranet. This is actually quite troublesome. Generally, if Lucky and OpenWrt happen to be deployed together, Lucky is not deployed via Docker, and other devices use stateful configuration, you can use the 4th method in the figure above to obtain it; similarly, for iKuai, if the other party is stateful, you can query the corresponding DUID on its own DHCP server:
If it is stateless, iKuai provides an additional way to obtain the IPv6 address based on the other party's MAC address compared to Lucky:
However, this method is not very stable and sometimes fails to obtain the address.
Note: The default is simple mode. In custom mode, there will be more options. You can configure them according to your own needs; generally, you don't need to change them:
Web service
Lucky's Web service supports multiple functions:
Enter the Web service rules interface, where the listening protocol and port are defined. Here, we directly check tcp6 and fill in the port you want to listen to:
The above service rules are only used to define the listening protocol and port. The specific functions are all implemented by "Add Web Service Sub-rule".
Reverse proxy
Lucky's Web service supports the reverse proxy function:
Note: For the frontend domain name/address and backend address, directly fill in the IP or domain name. Lucky will automatically add http://, so unless it is https, for http you can just directly fill in the domain name and ip:port.
The above are the configuration items in simple mode, which are sufficient for most people. If you have other more detailed requirements, you can turn on the custom mode switch:
Honestly, the functions are quite good.
Therefore, if you have not deployed Nginx, need to use a simple reverse proxy function, and happen to have deployed Lucky, then using Lucky to implement reverse proxy is a good choice.
Note: Other functions under the Web service can provide more options in custom mode, so I won't repeat the introduction.
Redirect or URL jump
Taking redirection as an example:
File service
You can display Lucky's local directory as a web page:
I haven't studied this in detail, so if you are interested, you can try it yourself.
Text output
You can very easily publish a piece of text, supporting 3 variables:
Port forwarding
This is the function I am most concerned about, and it is also the core point of my integrating Lucky into the home data center IPv6 egress solution. Lucky's operation is very simple:
Therefore, with the help of Lucky, in an IPv6 public IP egress environment, you can still access the entire intranet device by publishing a single public IPv6 address, just like in the days of public IPv4 addresses.
Of course, each supported device on the intranet can also have a public IPv6 address, but this does not conflict with the statement "accessing the entire intranet device by publishing a single public IPv6 address": the former targets the convenience and security of access from the outside in, while the latter is mainly about the convenience of internal-to-external access.
STUN intranet penetration
This is mainly set up for friends who do not have a public IP address and need to use STUN for internal network penetration. For specific configuration, please refer to my other article:Docker Series: Using Docker to Build Your Own STUN/TURN Server Based on Coturn。
But as the saying goes, try Tailscale, and you will realize that any internal network penetration is just a fleeting cloud.
P.S. I think the concept of internal network penetration (which should actually be called NAT traversal; the term "internal network penetration" is very characteristic of China, just like link load balancing and webpage tamper-proofing) is originally just an effect of another feature set: virtual networking. Everyone should actually choose a better virtual networking solution, rather than choosing an implementation method specifically for the effect of internal network penetration.
Security management
If you want to use lucky to implement the reverse proxy function, then you need to consider the issue of SSL certificates. Although HTTP is usable, first, it is insecure, and second, ISPs can see your content clearly, making it easy to mess with you (for detailed reasons, please refer to my other article:Home Data Center Series: Precautions for Building a Website with Home Broadband Having a Public IP), so even if you really don't want to file your domain name, at least use HTTPS as a precaution.
lucky's SSL certificates support 3 ways of acquisition:
File
If there is an existing certificate, you can directly use the file method to upload it to lucky. Certificate mapping can specify a local directory of lucky, and the uploaded certificate will be saved in that directory as {remark_name}.key {remark_name}.pem.
Path
This method is actually the same as the file method, except that instead of uploading, you directly upload the certificate to lucky's local directory and then directly specify the path.
ACME
If you know how to use the BT Panel to apply for Let's Encrypt certificates, you will definitely know how to use this.
Other Features
lucky also has network storage and Wake-on-LAN functions:
Interested friends can research this on their own.
Summary
Actually, for me, the most important thing is lucky's public IPv6 -> internal network IPv4 port forwarding function, which completes the last piece of the puzzle for my home data center IPv6 egress solution (actually, I still prefer iKuai to develop this function ~ but there's no way now). Other functions now have other stronger or more convenient implementation methods, such as using Nginx for reverse proxy, iKuai for dynamic domain names, and Tailscale for NAT traversal (I have a dual-stack public IP environment with both IPv4 and IPv6, but Tailscale is more convenient and secure). However, for general users, if you don't have an existing solution for reverse proxy, dynamic domain name, or NAT traversal, then just deploying a lucky can solve everything (STUN traversal requires an existing STUN server). That's why the title of my article is "Simple Version of Public IPv6 Inbound Access Gateway", as for the "Deluxe Version", it will be a complete solution, which I need some time to think through...
In addition, to emphasize again, for lightweight use, you can use lucky's Docker mode, but if it is for heavy use, it is still recommended to use the non-Docker method for deployment.