Preface
Because of the essential differences between IPv6 and IPv4 protocols, some long-standing traditional technologies on IPv4 will become useless in the future when IPv6 public IP becomes the mainstream: such as port mapping, NAT, etc. In the IPv6 public address export solution for home data centers that I am considering, some functions (such as port mapping) require similar alternative technologies. After all, although IPv6 addresses are unlimited, I cannot expose every device in my home directly to the public Internet. From a security perspective, exposing one 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, it is necessary to upgrade the traditional IPv4 port mapping technology: IPv6-->IPv4 port forwarding function. Unfortunately, except for openwrt, which can be realized by installing lucky or socat, no other routers support it (in fact, openwrt does not support it strictly speaking, but can install supporting software). In addition, there are not many people who use openwrt as the main router (there are many "bypass routers"), so before the router officially supports this function, the protagonist of my IPv6 export solution may have to be changed.
This article takes the Docker version of lucky, one of the protagonists of the solution, as an example to introduce the main functions of lucky.
Build lucky
Deploy lucky
Let me say something off topic first. As I mentioned in my previous article (see:Discussion on the best way to use the docker version of OpenWrt soft router series) said: "I think Docker deployment is most suitable for applications that provide content to the outside world (such as nginx, mysql), rather than those that need to frequently access external networks from within the container (such as lucky, cloudtunnel, openwrt)", especially lucky, which also requires IPv6-->IPv4 conversion and is highly dependent on the underlying operating system. The author of lucky also has a similar statement:
Therefore, if you really want to use lucky as the main tool and run large traffic, other non-docker deployment methods are recommended. Of course, if it is lightly used, the docker method is also OK, but try to use the host method for deployment.
The code for building lucky using the docker run format is very simple, as follows:
docker run -d --name lucky --restart=always --net=host gdy666/luckyInitialize lucky
Use Linkshttp://host ip:16601Log in to lucky's console, the default username and password are both "666":
Configuring the lucky function
Dynamic Domain Name
The domain names supported by lucky basically cover the common domain name providers (lucky only supports 6~~), and also supports customization:
And supports multiple ways to obtain IP:
The last method of obtaining it through odhcpd is a good match with openwrt (openwrt's IPv6 function is implemented through odhcpd).
Note: The way that dynamic domain names obtain public IP addresses in IPv6 is different from that in IPv4. IPv4 actually obtains its own public IP address by accessing an external page (except for dynamic domain names running on routers, which can directly correspond to the wan port IP), while IPv6 is more flexible. It can be obtained through external pages (such as the first method in the above figure) or directly obtain its own address (such as the second and third methods in the above figure). In fact, I recommend the second method, which is to obtain it through its own network card, but there is one thing to note here. There are both private IPv6 addresses and public IPv6 addresses on the network card. In order to ensure accurate identification, you can add IP selection matching rules:
Because I use China Telecom broadband, and China Telecom's IPv6 starts with 240e, so I added "^240e" so that there will be no recognition errors. I have encountered situations where if I don't add ip selection matching rules, sometimes the dynamic domain name will be recognized as a private network address starting with fe, which made me wait for a long time without any errors.
There is also a special case, which is to obtain the IPv6 address of other devices in the intranet. This is actually quite troublesome. In general, if lucky and openwrt are deployed together and lucky is not deployed in docker and other devices are using stateful mode, you can use the fourth method in the above figure 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, AiKuaiBiLucy provides one more way to obtain the IPv6 address based on the other party's MAC address:
However, this method is not very stable and sometimes fails to obtain.
In addition: the default mode is simple mode, there will be more options in the custom mode, you can configure it according to your needs, generally do not need to change:
Web Services
Lucky's web service supports multiple functions:
Enter the web service rule interface, here is to define the listening protocol and port, here we directly check tcp6, 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 implemented by "Add web service sub-rule".
Reverse Proxy
Lucky's web service supports reverse proxy function:
Note: For the front-end domain name/address and back-end address, just fill in the IP or domain name. Lucky will automatically add http://, so unless it is https, just fill in the domain name and ip:port for http.
The above are the configuration items in simple mode, but it is enough for most people. If you have other more detailed requirements, you can turn on the custom mode switch:
To be honest, the function is pretty good.
So if nginx is not deployed, and you need to simply use the reverse proxy function, and lucky happens to be deployed, then using lucky to implement reverse proxy is a good choice.
In addition: Other functions under the web service can use the customized mode to provide more options, so I will not repeat them here.
Redirect or URL jump
Take redirection as an example:
File Services
You can display lucky's local directory as a web page:
I haven't studied this in detail, if you are interested you can try it yourself.
Text Output
It is very simple to publish a piece of text, supporting 3 variables:
Port forwarding
This is the function I care about most, and it is also the core point for me to incorporate lucky into the IPv6 egress solution of the home data center. The operation of lucky is very simple:
Therefore, with the help of lucky, in the IPv6 public IP export environment, you can still access the entire intranet device by publishing a single IPv6 public address, just like the previous IPv4 public address.
Of course, each supported device in the intranet can also have an IPv6 public address, but this does not conflict with the statement "the entire intranet device can be accessed by publishing a single IPv6 public address": the former is aimed at the convenience and security of access from outside to inside, while the latter is mainly for the convenience of internal access to the outside.
STUN intranet penetration
This is mainly for friends who do not have a public network address and need to use STUN for intranet penetration. For specific configuration, please refer to my other article:Docker series Use Docker to build your own stun/turn server based on coturn.
But again, try TailScale and you will know that intranet penetration is just a pipe dream.
In addition: I think the concept of intranet penetration (actually it should be called NAT penetration. The name of intranet penetration is very Chinese, just like link load balancing and web page anti-tampering) is just another function set: a manifestation of the effect of virtual networking. In fact, everyone should choose a better virtual networking solution, rather than choosing an implementation method specifically for the effect of intranet penetration.
Safety Management
If you want to use lucky to implement reverse proxy function, you need to consider the issue of SSL certificate. Although http is available, it is not safe. Secondly, the operator can see your content clearly and it is easy to mess with you (for detailed reasons, please refer to my other article:Home Data Center Series Home Broadband Site Building Considerations with Public IP), so even if you really don’t want to register your domain name, at least use https to take precautions.
Lucky's SSL certificate supports 3 ways to obtain:
1. Documents
If you have an existing certificate, you can directly upload it to lucky as a file. Certificate mapping can specify a local directory of lucky, and the uploaded certificate will be saved in the directory as {remark name}.key {remark name}.pem.
2. Path
This method is actually the same as the file method, except that instead of uploading the certificate, the certificate is uploaded directly to the lucky local directory and the path is directly specified.
3. ACME
If you use the Baota panel to apply for a Let's Encrypt certificate, you will definitely use this.
Other functions
Lucky also has network storage and network wake-up functions:
Friends who are interested can study it on their own.
Summarize
In fact, for me, the most important thing is Lucky's public network IPv6->intranet IPv4 port forwarding function, which fills the last piece of the puzzle for my home data center IPv6 export solution (in fact, I still hope that AiKuai will develop this function ~ there is no way now), and other functions now have other stronger or more convenient implementation methods, such as using nginx for reverse proxy, AiKuai for dynamic domain name, and Tailscale for NAT traversal (I have an IPv4 and IPv6 dual-stack public network environment, but Tailscale is more convenient and secure). However, for general users, if you don’t have a ready-made reverse proxy, dynamic domain name, and NAT traversal solution, then you can solve all the problems by deploying a Lucky (STUN traversal requires a ready-made STUN server), so the title of my article is "Simplified Public Network IPv6 Access Inbound Gateway", and the "Deluxe Edition" is a complete solution, which I need time to think about. . .
In addition, I would like to emphasize that the lucky docker mode can be used for lightweight use, but if it is used heavily, it is recommended to use a non-docker method for deployment.
