Preface

At present, newly installed home broadband connections with IPv4 public IP addresses are becoming fewer and fewer, replaced by an increasing number of IPv6 public IP addresses. However, because IPv6 addresses are difficult to remember and many people lack solutions for dynamic binding of IPv6 public IP addresses and dynamic domain names at home, IPv6 public IP addresses are "practically useless even if you have them." Furthermore, accessing an IPv6 public IP address has another potential requirement: the accessing client must also have an IPv6 address, which also stumps many people (although accessing via mobile data through the cellular networks of the three major operators does support IPv6, not everyone is willing to use mobile data to access home applications, especially high-traffic ones like watching videos). Therefore, under these circumstances, whether or not you have an IPv6 public IP address (which actually also applies to cases with an IPv4 public IP address), the most convenient way to access your home devices from the outside is still through various “intranet penetration” technologies (operators certainly provide IPv4 addresses, they are just not public IP addresses; in the future, IPv6 public IP addresses might be added, forming a dual-stack structure of "private IPv4" + "public IPv6").

Intranet penetration without a public IPv4 address (the reason for emphasizing intranet penetration without a public IPv4 is that normal port mapping with a public IPv4 can also be considered a type of intranet penetration technology) must rely on a relay server with a public IPv4 (equivalent to an intermediary) and various “black magic” hole punching technologies. If "hole punching" succeeds, direct communication is possible; if "hole punching" fails, traffic can only be routed through the relay server.

There are two ways to obtain a relay server: either buy a ready-made one or build your own. Buying a ready-made one is simple, with a ton of paid options, so I won't say much. If you build your own, you have to choose a solution from the many virtual networking technologies available today. I am currently using Tailscale; I haven't used others, so I won't comment on them.

You can search online for Tailscale deployment methods; there are many excellent articles, so I won't waste words. If you need to build your own Tailscale DERP server, you can refer to my other article:Debian Series: Building a Tailscale DERP Server (Relay Server)。

The focus of this article is not on which solution to use to implement virtual networking, but on how to use virtual networking in a home data center environment (finally getting to the point, so tiring).

Virtual networking

Virtual networking technology is one of the very important underlying technologies in my home data center solution.

Literally speaking, virtual networking technology means virtualizing a network of your own, where all devices in this network can communicate freely. From the perspective of specific technical implementation, it means adding a virtual network card to each of your devices, with each virtual network card assigned an IP address (or one v4 and one v6 address each). The devices can communicate freely with each other through the assigned IPs, regardless of whether these devices are on the external or internal network.

Currently, the mainstream virtual networking technology is WireGuard. However, building and configuring WireGuard yourself is very tedious, requires a certain technical foundation, and also requires a host with a public IP. Therefore, for individuals, the most hassle-free way is to choose a mature solution based on WireGuard technology, such as Tailscale.

When choosing a specific virtual networking solution, an important technical indicator is cross-platform support. After all, clients need to be installed on devices, and there are various types of devices (Windows, Linux, macOS, iOS, Android devices). Therefore, the chosen virtual networking solution should also support these common client types.

In addition, if the virtual networking solution is provided by a foreign product and the official server-side function is already provided (meaning you only need to register an account on the official website, download the client, and log in directly), you also need to consider the connectivity between the client and the server. You can try this yourself first; it cannot be ruled out that some logins may require "magic" assistance.

Practical Applications of Virtual Networking

Intranet Penetration

For most people, virtual networking technology is just a last resort when home broadband lacks a public IPv4 address but they need to access home devices. For home broadband with a public IPv4 address, people might prefer to use dynamic DNS + port mapping for access. But for me, even when my home broadband has a public IP, I am unwilling to use port mapping unless absolutely necessary: first, because I have too many applications to map them one by one; second, the applications are deployed via Docker and only provide HTTP access, and running HTTP in plain text over the internet is too dangerous; third, publishing applications directly through public IPv4 port mapping is simply too risky (IPv6 addresses are much better, after all, there are many addresses and they change frequently, so they aren't as afraid of scanning, but you need to solve the binding with dynamic DNS and the issue that the accessing end might not support IPv6).

Although when home broadband has a public IPv4 address, you only need to do port mapping once to publish all applications through a reverse proxy plus dynamic DNS (theoretically, it can also be used directly for operation and maintenance management), for security reasons, I blocked sensitive operations from external requests (such as WordPress's /wp-admin) on the WAF. Therefore, during actual operations, I still prefer to access directly using the internal IP when I am at home, and when I am not at home, I can use the IP allocated by virtual networking to access (I used to like using OpenVPN, but as operators' negative optimization of OpenVPN became more and more excessive, I was forced to switch to a more secure method).

Therefore, in theory, regardless of whether home broadband has public IPv4 and IPv6 addresses, virtual networking is the best way for intranet penetration. Of course, there is a prerequisite: the virtual networking software must have an efficient and “black magic” “hole punching” method, allowing devices to access each other directly in most cases, rather than transmitting data through a “relay” server. For many paid intranet penetration software in China, you need to pay a high price to buy "relay" server bandwidth to get a good experience. It depends on whether everyone can accept the convenience brought by this price.

Serving as an "Origin Site"

If you have a website to publish, the most cost-effective way is to build the application using home devices (NAS, computer, etc.) and use them as the origin site, allowing domestic CDNs to access it (with a registered domain name), or using a cloud host as a reverse proxy to call it. This way, you don't need to buy expensive, high-performance cloud hosts and databases. However, this method has a prerequisite that the home broadband must have a public IP address (specifically required by domestic CDNs; if Cloudflare is used, a public IP address is not required).

If home broadband does not have a public IP address, can home devices still serve as the origin site? The answer is yes, but this requires the help of virtual networking technology.

The prerequisite for this method is that you must first have a cloud host (it's impossible not to have one, right? To register a domain name, you at least need to buy a cloud host, the cheapest one is fine, about 10 yuan a month). By deploying the client of the virtual networking software on both the cloud host and home devices, and joining both the cloud host and home devices to the virtual network, you can configure a reverse proxy on the cloud host to point the upstream server to the application deployed on the home device through the IP address allocated by the virtual network. If you feel that the bandwidth of the cloud host is insufficient, you can also point the origin site to the cloud host through a CDN (the cloud host acts as a reverse proxy pointing to the home device, so ultimately the application on the home device becomes the final origin site).

This method even allows accessing the home database through the virtual networking IP... However, based on internet latency, this experience is very poor. Use with caution, unless it is for certain applications that do not access the database frequently.

Secure Proxy

If there is a device at home that can use "magic", this is often only usable by devices at home; it cannot be used when you are not at home. Before using virtual networking, if home broadband had a public IPv4 address, those who were brave enough might try their luck with port mapping, while those without a public address had no way at all. But after using virtual networking, even when you are out, any device that can install the virtual networking client (laptop, phone, tablet) can directly access the home device that can use "magic" through the virtual networking IP.

Another use case is for cloud hosts. Once the virtual networking client is also deployed on the cloud host, the proxy can be directly pointed to the home device that can provide "magic" through the virtual networking IP, or local proxies can be used in certain ways (see article:Tips and Tricks Series: Powerful Local Proxy Tool: proxychains）。

Using SMB to access the shared directory of home NAS

One reason for using OpenVPN in the past was because I wanted to directly use the "//" method on Windows systems to access the shared directory of my home NAS. Now, virtual networking can also achieve this function, allowing me to organize movies downloaded on the NAS every day even when I am away from home (why mention Windows systems? Because I need to use Everything. Currently, I am using a Windows virtual machine on a MacBook, mainly because organizing resources relies on Everything).

Cross-device file transfer

Achieving seamless and efficient cross-device file transfer between your different devices (phones, tablets, computers) regardless of location and distance (see article:Nifty Tricks Series: Recommended Cross-Device Text and File Transfer Solutions
http).

Summary

Finally, simply put, virtual networking is just a technology that provides this functionality; the key is how you use it.