How Tailscale works  Tailscale 如何運作

People often ask us for an overview of how Tailscale works. We’ve been putting off answering that, because we kept changing it! But now things have started to settle down.
人們經常要求我們概述 Tailscale 的運作方式。我們一直拖著不回答，因為我們一直在改變！但現在事情已經開始穩定下來。

Let’s go through the entire Tailscale system from bottom to top, the same way we built it (but skipping some zigzags we took along the way). With this information, you should be able to build your own Tailscale replacement… except you don’t have to, since our node software is open source and we have a flexible free plan.
讓我們從下至上，以我們建立 Tailscale 系統的相同方式（但跳過我們沿途所走的一些之字形路線）來檢視整個 Tailscale 系統。有了這些資訊，您應該可以建立自己的 Tailscale 替換品......只是您不必這樣做，因為我們的節點軟體是開放原始碼的，而且我們有彈性的免費方案。

The data plane: WireGuard®
資料平面：WireGuard

Our base layer is the increasingly popular and excellent open source WireGuard package (specifically the userspace Go variant, wireguard-go). WireGuard creates a set of extremely lightweight encrypted tunnels between your computer, VM, or container (which WireGuard calls an “endpoint” and we’ll call a “node”), and any other nodes in your network.
我們的基礎層是越來越受歡迎且優異的開放原始碼 WireGuard 套件 (特別是使用者空間 Go 變體，wireguard-go)。WireGuard 會在您的電腦、虛擬機器或容器（WireGuard 稱之為「端點」，我們稱之為「節點」）與網路上的任何其他節點之間，建立一組極輕量級的加密隧道。

Let’s clarify that: most of the time, VPN users, including WireGuard users, build a “hub and spoke” architecture, where each client device (say, your laptop) connects to a central “concentrator” or VPN gateway.
讓我們澄清一下：大多數時候，VPN 使用者（包括 WireGuard 使用者）都會建置一個「集線器與辐線」架構，其中每個用戶端裝置（例如您的筆記型電腦）都會連線至中央「集中器」或 VPN 閘道。

Hub-and-spoke networks  樞紐輻射網路

This is the easiest way to set up WireGuard, because each node in the network needs to know the public key, public IP address, and port number of each other node it wants to connect directly to. If you wanted to fully connect 10 nodes, then that would be 9 peer nodes that each node has to know about, or 90 separate tunnel endpoints. In a hub-and-spoke, you just have one central hub node and 9 outliers (with “spokes” connecting them), which is much simpler. The hub node usually has a static IP address and a hole poked in its firewall so it’s easy for everyone to find. Then it can accept incoming connections from nodes at other IP addresses, even if those nodes are themselves behind a firewall, in the usual way that client-server Internet protocols do.
這是設定 WireGuard 最簡單的方法，因為網路中的每個節點都需要知道它想要直接連線的其他節點的公開金鑰，公開 IP 位址和連接埠號碼。如果您想要完全連接 10 個節點，那麼每個節點就必須知道 9 個對等節點，也就是 90 個獨立的隧道端點。在集線器(hub-and-spoke)中，您只需要一個中央集線器節點和 9 個離群節點 (有「spokes」連結它們)，這樣就簡單多了。集線器節點通常有一個靜態 IP 位址，並在防火牆上戳一個洞，這樣大家就很容易找到它。然後，它可以接受來自其他 IP 位址節點的連線，即使這些節點本身也在防火牆後面，就像用戶端伺服器網際網路通訊協定一樣。

Hub-and-spoke works well, but it has some downsides. First of all, most modern companies don’t have a single place they want to designate as a hub. They have multiple offices, multiple cloud datacenters or regions or VPCs, and so on. In traditional VPN setups, companies configure a single VPN concentrator, and then set up secondary tunnels (often using IPsec) between locations. So remote users arrive at the VPN concentrator in one place, then have their traffic forwarded to its final destination in another place.
Hub-and-spoke 運作良好，但也有一些缺點。首先，大多數現代企業都沒有指定一個地方作為樞紐。他們有多個辦公室、多個雲端資料中心或區域或 VPC 等等。在傳統的 VPN 設定中，公司會設定單一 VPN 集中器，然後在各地點之間建立次要通道 (通常使用 IPsec)。因此，遠端使用者會到達一個地方的 VPN 集中器，然後將其流量轉發到另一個地方的最終目的地。

This traditional setup can be hard to scale. First of all, remote users might or might not be close to the VPN concentrator; if they’re far away, then they incur high latency connecting to it. Secondly, the datacenter they want to reach might not be close to the VPN concentrator either; if it’s far away, they incur high latency again. Imagine this case, with a worker in New York trying to reach a server in New York, through the company’s VPN concentrator or BeyondCorp proxy at their head office in San Francisco, not that I’m bitter:
這種傳統設定很難擴充。首先，遠端使用者可能靠近 VPN 集中器，也可能不靠近；如果遠端使用者離 VPN 集中器很遠，連接時就會產生高延遲。其次，他們想要連線的資料中心也可能不在 VPN 集中器附近；如果距離太遠，又會產生高延遲。試想一下這種情況，身在紐約的員工試圖透過公司的 VPN 集中器或 BeyondCorp 代理伺服器連接到位於舊金山總公司的伺服器：

Luckily, WireGuard is different. Remember how we said it creates a “set of extremely lightweight tunnels” above? The tunnels are light enough that we can create a multi-hub setup without too much trouble:
幸好 WireGuard 與眾不同。還記得我們在上面說它會建立「一組極輕量的隧道」嗎？這些隧道非常輕巧，我們可以輕鬆地建立多集線器設定：

The only catch is that now each of the datacenters needs a static IP address, an open firewall port, and a set of WireGuard keys. When we add a new user, we’ll have to distribute the new key to all five servers. When we add a new server, we’ll have to distribute its key to every user. But we can do it, right? It’s only about 5 times as much work as one hub, which is not that much work.
唯一的問題是，現在每個資料中心都需要一個固定 IP 位址、一個開放的防火牆連接埠，以及一組 WireGuard 金鑰。新增使用者時，我們必須將新金鑰分發給所有五台伺服器。當我們新增一台伺服器時，我們必須將它的金鑰分發給每一位使用者。但我們可以做到，對吧？這只不過是一個集線器工作量的 5 倍左右，而一個集線器的工作量並不算多。

Mesh networks  網狀網路

So that’s hub-and-spoke networks. They’re not too hard to set up with WireGuard, although a bit tedious, and we haven’t really talked about safe practices for key management yet (see below).
這就是 hub-and-spoke 網路。使用 WireGuard 設定這些網路並不難，雖然有點繁瑣，而且我們還沒有真正談過金鑰管理的安全作法 (請參閱下文)。

Still, there’s something fundamentally awkward about hub-and-spoke: they don’t let your individual nodes talk to each other. If you’re old like me, you remember when computers could just exchange files directly without going to the cloud and back. That was how the Internet all used to work, believe it or not! Sadly, developers have stopped building peer-to-peer apps because the modern Internet’s architecture has evolved, almost by accident, entirely into this kind of hub-and-spoke design, usually with the major cloud providers in the center charging rent.
儘管如此，hub-and-spoke 仍有一些基本的尷尬之處：它們不會讓您的個別節點彼此交談。如果您跟我一樣年紀老邁，您應該還記得電腦可以直接交換檔案，而無需往返雲端。信不信由你，互聯網以前就是這樣運作的！可悲的是，開發人員已經不再建立點對點的應用程式，因為現代網際網路的架構幾乎是意外地完全演變成這種樞紐(hub)與輻射(spoke)的設計，通常是由位於中心的主要雲端供應商收取租金。

Remember those “extremely lightweight” WireGuard tunnels? Wouldn’t it be nice if you could directly connect all the nodes to all the other nodes? That’s called a mesh network:
還記得那些「極輕量級」的 WireGuard 隧道嗎？如果您可以直接將所有節點連接到所有其他節點，那不是很好嗎？這就是所謂的網狀網路：

That would be very elegant—at least, it would let you design elegant peer-to-peer apps—but it would be tricky. As mentioned above, a 10-node network would require 10 x 9 = 90 WireGuard tunnel endpoint configurations; every node would need to know its own key plus 9 more, and each node would have to be updated every time you rotate a key or add/remove a user.
這將會非常優雅，至少可以讓您設計出優雅的點對點應用程式，但這將會很棘手。如上所述，一個 10 節點的網路需要 10 x 9 = 90 個 WireGuard 隧道端點設定；每個節點都需要知道自己的金鑰以及另外 9 個金鑰，而且每次轉換金鑰或新增/移除使用者時，每個節點都必須更新。

And the nodes would all have to find each other somehow—user devices rarely have static IP addresses—and reconnect whenever one of them moves around.
這些節點都必須以某種方式找到彼此 - 使用者裝置很少有固定的 IP 位址 - 並在其中一個節點移動時重新連線。

Plus, you can’t easily open a firewall port for every single node to allow incoming connections in, say, a cafe, hotel, or airport.
此外，您無法輕易為每個節點開啟防火牆連接埠，以允許咖啡廳、旅館或機場等地的連線進入。

And then, after you’ve done all that, if your company has compliance requirements, you need to be able to somehow block and audit traffic between all the nodes, even though it’s no longer all going through a central location that you can clamp down.
完成所有這些工作之後，如果您的公司有合規要求，您需要能夠以某種方式封鎖並稽核所有節點之間的流量，即使這些流量不再全部經過您可以箝制的中央位置。

Tailscale makes all that work too! Let’s talk about how. This is where things get a bit hairy.
Tailscale 也能讓這一切順利進行！讓我們來談談怎麼做。這就是事情變得有點棘手的地方。

The control plane: key exchange and coordination
控制平面：金鑰交換與協調

Okay, we’ve made it this far. We got WireGuard connecting. We got it connecting to multiple things at a time. We’ve marvelled at its unparalleled reliability and efficiency. Great! Now we want to build a mesh network—everything connected to everything else.
好了，我們到此為止。我們連上了 WireGuard。我們讓它一次連線多個裝置。我們驚嘆於它無與倫比的可靠性和效率。好極了！現在我們要建立一個網狀網路 - 所有東西都連線到其他所有東西。

All those firewalls and dynamic IP addresses are tricky, so let’s leave them aside for the moment. (See further below.) For now, pretend the whole world uses static IPs (dare we say… IPv6?) and that firewalls don’t exist or that it’s easy to open ports.
所有這些防火牆和動態 IP 位址都很棘手，所以我們暫時把它們放在一旁。(請參閱下文。）現在，假設全世界都使用靜態 IP（我們敢說......IPv6？

How do we get all the WireGuard encryption keys (a simplified and more secure form of “certificates”) onto every device?
我們如何將所有 WireGuard 加密金鑰（簡化且更安全的「證書」形式）傳送到每部裝置？

For that, we use the open source Tailscale node software. It talks to what we call a “coordination server” (in our case, login.tailscale.com)—essentially, a shared drop box for public keys.
為此，我們使用開放原始碼的 Tailscale 節點軟體。它會與我們所謂的「協調伺服器」（在我們的例子中，是 login.tailscale.com）進行交談 - 實質上，這是一個共用的公開金鑰投遞箱。

Hold on, are we back to hub-and-spoke again? Not exactly. The so-called “control plane” is hub and spoke, but that doesn’t matter because it carries virtually no traffic. It just exchanges a few tiny encryption keys and sets policies. The data plane is a mesh.
等一下，我們又要回到樞紐輻射嗎？不完全是。所謂的「控制平面」就是集線器和辐線，但這並不重要，因為它幾乎不傳輸任何流量。它只是交換一些微小的加密金鑰和設定政策。資料平面則是網狀。

(We like this hybrid centralized-distributed model. Companies and teams usually want to have central control, but they don’t want a central bottleneck for their data. Traditional VPN concentrators centralize both, limiting performance, especially under stress. Conversely, Tailscale’s data processing power scales up with the number of nodes.)
(我們喜歡這種集中式與分散式的混合模式。公司和團隊通常希望擁有中央控制，但又不希望資料出現中央瓶頸。傳統的 VPN 集中器將兩者都集中起來，限制了效能，尤其是在壓力下。相反地，Tailscale 的資料處理能力會隨著節點數量的增加而擴大 ()。

Here’s what happens:  事情是這樣的

1. Each node generates a random public/private keypair for itself, and associates the public key with its identity (see login, below).
   每個節點都會為自己產生隨機的公開/私人金鑰對，並將公開金鑰與自己的身分相關聯 (請參閱下面的登入)。
2. The node contacts the coordination server and leaves its public key and a note about where that node can currently be found, and what domain it’s in.
   節點會聯絡協調伺服器，並留下它的公開金鑰，以及關於目前在哪裡可以找到該節點，以及該節點所在網域的說明。
3. The node downloads a list of public keys and addresses in its domain, which have been left on the coordination server by other nodes.
   節點下載其網域內的公開金鑰和位址清單，這些金鑰和位址是由其他節點留在協調伺服器上的。
4. The node configures its WireGuard instance with the appropriate set of public keys.
   節點使用適當的公開金鑰集配置其 WireGuard 實例。

Note that the private key never, ever leaves its node. This is important because the private key is the only thing that could potentially be used to impersonate that node when negotiating a WireGuard session. As a result, only that node can encrypt packets addressed from itself, or decrypt packets addressed to itself. It’s important to keep that in mind: Tailscale node connections are end-to-end encrypted (a concept called “zero trust networking”).
請注意，私密金鑰永遠不會離開其節點。這一點很重要，因為在協商 WireGuard 會話時，私密金鑰是唯一可能用來冒充該節點的東西。因此，只有該節點可以加密從自己發出的封包，或解密向自己發出的封包。請務必牢記這一點：Tailscale 節點連線是端對端加密（稱為「零信任網路」的概念）。

Unlike a hub-and-spoke network, unencrypted packets never need to be sent over a wire, and no intermediary can inspect them. (The exception is if you use subnet routes, which are useful for incremental deployment, which Tailscale supports. You can create a hybrid network that combines new-style mesh connections with zero or more old-style “hubs” that decrypt packets, then forward them to legacy physical networks.)
與 hub-and-spoke 網路不同，未加密的封包永遠不需要透過網路傳送，也沒有中間人可以檢查它們。(如果您使用子網路路由則屬例外，這對於 Tailscale 支援的增量部署非常有用。您可以建立混合網路，結合新式網狀連線與零個或更多舊式「集線器」，這些「集線器」會解密封包，然後將封包轉送至傳統的實體網路)。

Login and 2-factor auth (2FA)
登入和雙重認證 (2FA)

But we skipped over a detail. How does the coordination server know which public keys should be sent to which nodes? Public keys are just that—public—so they are harmless to leak to anyone, or even post on a public web site. This is exactly the same situation as an ssh server with an authorized_keys file; you don’t have to keep your public ssh key secret, but you still have to be careful which public keys you put in authorized_keys.
但我們略過了一個細節。協調伺服器如何知道哪些公開金鑰應該傳送給哪些節點？公開金鑰就是公開的，所以洩露給任何人，甚至張貼在公開網站上，都是無害的。這與 ssh 伺服器上的 authorized_keys 檔案情況完全相同；您不需要對您的公開 ssh 金鑰保密，但您仍必須小心將哪些公開金鑰放入 authorized_keys。

There are many ways to make the authentication decision. An obvious way would be to build a username+password system, also known as PSK (pre-shared keys). To set up your node, connect to the server, enter your username and password, then upload your public key and download other public keys posted by either your account or other accounts in your domain. If you want to get fancy, you can add two-factor authentication (2FA, also known as MFA) such as SMS, Google Authenticator, Microsoft Authenticator, and so on.
有許多方法可以做認證決定。一個明顯的方法是建立一個使用者名稱+密碼系統，也稱為 PSK（預先共用金鑰）。要設定節點，請連線到伺服器，輸入您的使用者名稱和密碼，然後上傳您的公開金鑰，並下載您的帳號或網域內其他帳號所張貼的其他公開金鑰。如果您想要花俏一點，可以加入雙因素認證 (2FA，也稱為 MFA)，例如 SMS、Google Authenticator、Microsoft Authenticator 等。

A system administrator could also set up your machine with a “machine certificate” — a key that belongs permanently (or semi-permanently) to the device rather than to the user account. It could use this to ensure that, even with the right username and password, an untrusted device can never publish new keys to the coordination server.
系統管理員也可以使用「機器證書」設定您的機器 - 永久 (或半永久) 屬於裝置而非使用者帳戶的金鑰。系統管理員可以用它來確保，即使有正確的使用者名稱和密碼，不受信任的裝置也無法發佈新的金鑰到協調伺服器。

Tailscale operates a coordination server based around these concepts. However, we don’t handle user authentication ourselves. Instead, we always outsource authentication to an OAuth2, OIDC (OpenID Connect), or SAML provider. Popular ones include Gmail, GSuite, and Office365.
Tailscale 以這些概念為基礎運作協調伺服器。但是，我們不會自行處理使用者驗證。相反，我們總是將驗證外包給 OAuth2、OIDC (OpenID Connect) 或 SAML 供應商。受歡迎的提供商包括 Gmail、GSuite 和 Office365。

The identity provider maintains a list of users in your domain, passwords, 2FA settings, and so on. This avoids the need to maintain a separate set of user accounts or certificates for your VPN — you can use the authentication you already have set up for use with Google Docs, Office 365, and other web apps. Also, because all your private user account and login data is hosted on another service, Tailscale is able to operate a highly reliable central coordination service while holding a minimum of your users’ personally identifiable information (PII). (Read our privacy policy for more.)
身份供應商會維護您網域中的使用者清單、密碼、2FA 設定等。這避免了為您的 VPN 維護一組獨立的使用者帳號或憑證 - 您可以使用您已設定的驗證，以用於 Google Docs、Office 365 和其他 Web 應用程式。此外，由於您所有的私人使用者帳戶和登入資料都託管在另一項服務上，因此 Tailscale 能夠運作高度可靠的中央協調服務，同時持有最少的使用者個人識別資訊 (PII)。(更多資訊請閱讀我們的隱私權政策）。

You also don’t have to change how you do single sign-on, account creation and removal, password recovery, and 2FA setup. It’s all exactly like what you already have.
您也不需要改變單一登入、帳號建立與移除、密碼回復和 2FA 設定的方式。一切都和您現有的一樣。

And because of all that, Tailscale domains can activate instantly the moment you login. If you download our macOS or iOS app from the App Store, for example, and login to your account, this immediately creates a secure key drop box for your domain and lets you exchange public keys with other devices in that account or domain, like a Windows or Linux server.
正因為如此，Tailscale 網域可以在您登入的那一刻立即啟動。舉例來說，如果您從 App Store 下載我們的 macOS 或 iOS 應用程式，並登入您的帳戶，這會立即為您的網域建立安全的金鑰存放箱，並讓您與該帳戶或網域中的其他裝置交換公開金鑰，例如 Windows 或 Linux 伺服器。

And then, as we just saw, the public keys get downloaded to each node, each node configures WireGuard with a super-lightweight tunnel to each other node, and ta da! A mesh network in two minutes!
然後，就像我們剛剛看到的，公開金鑰會下載到每個節點，每個節點會設定 WireGuard 與超輕量級隧道到其他節點，然後，嗒嗒！兩分鐘就能建立一個網狀網路！

NAT traversal  NAT 穿透

…but we’re not quite done yet. Recall that up above, we decided to pretend that every node has a static IP address and an open firewall port for incoming WireGuard traffic. In real life, that’s not too likely. In real life, some of your nodes are in cafes or on airplanes or LTE on the highway with one bar of signal, battery drained, fleeing desperately from the cops across state lines… oh, sorry, wrong movie.
...但我們還沒完全完成。回想上面，我們決定假設每個節點都有一個固定 IP 位址和開放的防火牆連接埠，供 WireGuard 傳入流量使用。在現實生活中，這不太可能發生。在現實生活中，有些節點在咖啡廳或飛機上，或在只有一格訊號、電池耗盡、拚命逃離警察的高速公路上......抱歉，看錯電影了。

Anyway, in the worst case what you have is something like this:
無論如何，在最壞的情況下，您會遇到這樣的問題：

That’s two NATs, no open ports. Historically, people would ask you to enable uPnP on your firewall, but that rarely works and even when it does work, it usually works dangerously well until administrators turn it off.
這是兩個 NAT，沒有開放的連接埠。在過去，人們會要求您在防火牆上啟用 uPnP，但這很少會成功，即使成功了，通常也很危險，直到管理員將其關閉為止。

For now, suffice it to say that Tailscale uses several very advanced techniques, based on the Internet STUN and ICE standards, to make these connections work even though you wouldn’t think it should be possible. This avoids the need for firewall configurations or any public-facing open ports, and thus greatly reduces the potential for human error.
現在，我們只需要說 Tailscale 根據網際網路 STUN 和 ICE 標準，使用幾種非常先進的技術，讓這些連線正常運作，即使您認為不可能。這避免了防火牆設定或任何面向公眾的開放連接埠，因此大大降低了人為錯誤的可能性。

For all the gory details, see my teammate Dave Anderson’s post: How NAT traversal works.
有關所有血淋淋的細節，請參閱我的隊友 Dave Anderson 的文章：NAT 穿越是如何運作的。

Encrypted TCP relays (DERP)
加密 TCP 中繼 (DERP)

Just one more thing! Some especially cruel networks block UDP entirely, or are otherwise so strict that they simply cannot be traversed using STUN and ICE. For those situations, Tailscale provides a network of so-called DERP (Designated Encrypted Relay for Packets) servers. These fill the same role as TURN servers in the ICE standard, except they use HTTPS streams and WireGuard keys instead of the obsolete TURN recommendations.
還有一件事！有些特別殘忍的網路會完全封鎖 UDP，或是嚴格到無法使用 STUN 和 ICE 穿透。針對這些情況，Tailscale 提供了一個所謂 DERP（指定封包加密中繼）伺服器的網路。這些伺服器與 ICE 標準中的 TURN 伺服器扮演相同的角色，但它們使用 HTTPS 串流和 WireGuard 金鑰，而非過時的 TURN 建議。

Relaying through DERP looks like this:
透過 DERP 進行中繼是這樣的：

(Despite how it might look above, we really do have a globally distributed network of relay servers. It’s not just the United States. In the words of our intrepid designer, “I was hoping to include London in there, but finding two SVGs with compatible non-Mercator projections was a disaster.” This is how much we care about technical accuracy. Also, stop using Mercator projections. They’re super misleading.)
(儘管上面看起來如此，我們的中繼伺服器網路確實是分佈在全球各地。不只是美國。用我們無畏的設計師的話來說：「我本來希望把倫敦也包含在裡面，但是要找到兩個有相容的非 Mercator 投影的 SVG 簡直是一場災難」。這就是我們對技術準確性的重視程度。此外，請停止使用墨卡托投影。它們是超級誤導的)。

Remember that Tailscale private keys never leave the node where they were generated; that means there is never a way for a DERP server to decrypt your traffic. It just blindly forwards already-encrypted traffic from one node to another. This is like any other router on the Internet, albeit using a slightly fancier protocol to prevent abuse.
請記住，Tailscale 的私密金鑰從未離開產生金鑰的節點；這表示 DERP 伺服器無法解密您的流量。它只是盲目地將已加密的流量從一個節點轉發到另一個節點。這就像網際網路上的其他路由器一樣，只是使用了稍微高級一點的通訊協定來防止濫用。

Many people on the Internet are curious about whether WireGuard supports TCP, like OpenVPN does. Currently this is not built into WireGuard itself, but the open source Tailscale node software includes DERP support, which adds this feature. Over time, it’s possible the code will be refactored to include this feature in WireGuard itself. (Tailscale has already contributed several fixes and improvements to WireGuard-Go.) We have also open sourced the (quite simple) DERP relay server code so you can see exactly how it works.
網際網路上有許多人好奇 WireGuard 是否像 OpenVPN 一樣支援 TCP。目前 WireGuard 本身並未內建此功能，但開放原始碼的 Tailscale 節點軟體包含 DERP 支援，可增加此功能。隨著時間的推移，程式碼有可能會被重構，以便在 WireGuard 本身加入此功能。(Tailscale 已經為 WireGuard-Go 貢獻了一些修正與改進）。我們也開放了 DERP 中繼伺服器程式碼（相當簡單），讓您可以清楚瞭解其運作方式。

Bonus: ACLs and security policies
獎勵：ACL 和安全政策

People often think of VPNs as “security” software. This categorization seems obvious because VPNs are filled with cryptography and public/private keys and certificates. But VPNs really fit in the category of “connectivity” software: they increase the number of devices that can get into your private network. They don’t decrease it, like security software would.
人們常將 VPN 視為「安全」軟體。這個分類似乎很明顯，因為 VPN 充滿了密碼學、公/私密金鑰和憑證。但 VPN 真正適合「連線」軟體的類別：它們增加了可以進入您私人網路的裝置數量。它們不會像安全軟體一樣減少網路。

As a result, VPN concentrators (remember the hub-and-spoke model from up above) are usually coupled with firewalls; sometimes they’re even sold together. All the traffic comes from individual client devices, flows through the VPN concentrator, then into the firewall, which applies access controls based on IP addresses, and finally into the network itself.
因此，VPN 集中器（還記得上文提到的集線器模式）通常會與防火牆搭配使用；有時甚至會一起出售。所有流量都來自個別用戶端裝置，流經 VPN 集中器，然後進入防火牆，防火牆會根據 IP 位址實施存取控制，最後進入網路本身。

That model works, but it can become a pain. First of all, firewall rules are usually based on IP addresses, not users or roles, so they can be very awkward to configure safely. As a result, you end up having to add more layers of authentication, at the transport or application layers. Why do you need ssh or HTTPS? Because the network layer is too insecure to be trusted.
這種模式可行，但也可能會很麻煩。首先，防火牆規則通常是基於 IP 位址，而不是使用者或角色，因此要安全地設定這些規則可能會很困難。因此，您最後不得不在傳輸層或應用程式層增加更多的驗證層級。為什麼需要 ssh 或 HTTPS？因為網路層太不安全，不值得信任。

Second, firewalls are often scattered around the organization and need to be configured individually. If you have a multi-hub network (for example, with different VPN concentrators in different geographic locations), you have to make sure to configure the firewall correctly on each one, or risk a security breach.
其次，防火牆通常分散在組織各處，需要個別設定。如果您有多個集線器網路 (例如，在不同的地理位置有不同的 VPN 集中器)，您必須確保在每個集線器上正確設定防火牆，否則會有安全漏洞的風險。

Finally, it’s usually a pain to configure some particular vendor’s VPN/firewall device to authenticate VPN connections against some other vendor’s identity system. This is why some identity system vendors will try to sell you a VPN, and some VPN vendors will try to sell you an identity system.
最後，要設定某些特定廠商的 VPN/防火牆裝置，以針對其他廠商的身分系統來驗證 VPN 連線，通常是一件很麻煩的事。這就是為什麼有些身份系統廠商會試圖向你推銷 VPN，而有些 VPN 廠商則試圖向你推銷身份系統。

When you switch to a mesh network, this problem seems to get even worse — there is no central point at all, so where do you even put the firewall rules? In Tailscale, the answer is: in every single node. Each node is responsible for blocking incoming connections that should not be allowed, at decryption time.
當您切換到網狀網路時，這個問題似乎變得更嚴重 - 因為根本沒有中心點，所以您要把防火牆規則放在哪裡？在 Tailscale 中，答案是：每個節點。每個節點都負責在解密時封鎖不該允許的傳入連線。

To make that easier, your company’s security policy is stored on the Tailscale coordination server, all in one place, and automatically distributed to each node. This way you have central control over policy, but efficient, distributed enforcement.
為了讓這一切變得更容易，您公司的安全政策會儲存在 Tailscale 協調伺服器上，全部集中在一個地方，並自動分發到每個節點。如此一來，您可以集中控制政策，但又能有效率地分散執行。

At a less granular level, the coordination server (key drop box) protects nodes by giving each node the public keys of only the nodes that are supposed to connect to it. Other Internet computers are unable to even request a connection, because without the right public key in the list, their encrypted packets cannot be decoded. It’s like the unauthorized machines don’t even exist. This is a very powerful protection model; it prevents virtually any kind of protocol-level attack. As a result, Tailscale is especially good at protecting legacy, non-web based services that are no longer maintained or receiving updates.
在較小的層級上，協調伺服器 (key drop box) 只會提供每個節點應該連線到它的節點的公開金鑰，以保護節點。其他網際網路電腦甚至無法要求連線，因為清單中沒有正確的公開金鑰，它們的加密封包就無法解碼。就好像未經授權的機器根本不存在一樣。這是一個非常強大的保護模型；它幾乎可以防止任何形式的通訊協定層級攻擊。因此，Tailscale 特別擅長保護不再維護或接受更新的傳統、非網路服務。

Bonus: Audit logs  獎勵：稽核日誌

Another concern of companies with tight compliance requirements is audit trails. Modern firewalls don’t just block traffic — they log it. Since Tailscale doesn’t have a central traffic funnel, what can you do?
具有嚴格合規要求的公司所關注的另一個問題是審計追蹤。現代防火牆不僅阻擋流量，還會記錄流量。既然 Tailscale 沒有中央流量漏斗，您能怎麼辦？

The answer is: we allow you to log all internal network connections from each node, asynchronously, to a central logging service. An interesting side effect of this design is that every connection is logged twice: on the source machine and the destination machine. As a result, log tampering is easy to detect, because it would require simultaneous tampering on two different nodes.
答案是：我們允許您從每個節點以非同步的方式，將所有內部網路連線記錄至中央記錄服務。這種設計的一個有趣副作用是，每個連線都會被記錄兩次：在源機器和目的機器上。因此，日誌篡改很容易偵測，因為這需要在兩個不同節點上同時進行篡改。

Because logs are streamed in real time from each node, rather than batched, the window for local log tampering on a node is extremely short, in the order of dozens of milliseconds, making even a single-node tampering attack difficult to achieve.
由於日誌是從每個節點即時串流，而不是分批串流，因此節點上的本機日誌篡改視窗極短，大約只有數十毫秒，即使是單節點篡改攻擊也很難實現。

Tailscale’s central logging service has controllable retention periods and each node just logs some metadata about how your internal mesh is established, not Internet usage or personal information. (Read our privacy policy for more.)
Tailscale 的中央記錄服務有可控制的保留期限，每個節點只記錄一些關於您內部網狀結構建立方式的元資料，而非網際網路使用或個人資訊。(更多資訊請閱讀我們的隱私權政策）。

Rather than providing a complete logs and metrics pipeline, the Tailscale logging service is intended as a real-time streaming data collector that can then stream data out into other systems for further analysis. (You can read my early blog post that evolved into Tailscale’s logs collector architecture.)
Tailscale 日誌服務並不是提供完整的日誌和度量管道，而是要作為即時串流資料收集器，然後將資料串流到其他系統作進一步分析。(您可以閱讀我早期的部落格文章，該文章演變成 Tailscale 的日誌收集器架構）。

Bonus: Incremental deployment
獎勵：遞增式部署

There is one last question that comes up a lot: given that Tailscale creates a mesh “overlay” network (a VPN that parallels a company’s internal physical network), does a company have to switch to it all at once? Many BeyondCorp and zero-trust style products work that way. Or can it be deployed incrementally, starting with a small proof of concept?
最後一個問題經常出現：既然 Tailscale 建立了網狀「覆蓋」網路 (與公司內部實體網路平行的 VPN)，公司是否必須一次過轉換成它？許多 BeyondCorp 和零信任式的產品都是這樣運作的。還是可以從小型的概念驗證開始，逐步部署？

Tailscale is uniquely suited to incremental deployments. Since you don’t need to install any hardware or any servers at all, you can get started in two minutes: just install the Tailscale node software onto two devices (Linux, Windows, macOS, iOS), login to both devices with the same user account or auth domain, and that’s it! They’re securely connected, no matter how the devices move around. Tailscale runs on top of your existing network, so you can safely deploy it without disrupting your existing infrastructure and security settings.
Tailscale 非常適合增量部署。由於您完全不需要安裝任何硬體或任何伺服器，您可以在兩分鐘內開始使用：只要將 Tailscale 節點軟體安裝到兩台裝置 (Linux、Windows、macOS、iOS)，以相同的使用者帳號或授權網域登入兩台裝置，就可以了！無論裝置如何移動，都能安全地連線。Tailscale 在您現有的網路之上執行，因此您可以安全地部署它，而不會擾亂您現有的基礎架構和安全設定。

You can then extend the network by adding subnet routes to one or more offices or datacenters, building up a traditional hub-and-spoke or multi-hub VPN.
然後，您可以透過新增子網路路由到一個或多個辦公室或資料中心來擴展網路，建立傳統的 hub-and-spoke 或 multi-hub VPN。

As you gain confidence, you can install Tailscale on more servers or containers, which allows point-to-point fully encrypted connections (no unencrypted traffic carried over any LAN). This final configuration is called “zero trust networking,” which is gaining fame lately, but so far has been hard to attain.
當您獲得信心時，您可以在更多伺服器或容器上安裝 Tailscale，這樣就可以進行點對點的完全加密連線 (任何區域網路都不會傳輸未加密的流量)。這種最後配置稱為「零信任網路」，最近名聲越來越大，但至今仍難以實現。

With Tailscale, you can build up to “zero trust,” one employee device and one server at a time. After the incremental deployment is done, you can safely shut down your legacy or unencrypted access methods.
有了 Tailscale，您可以一次使用一台員工裝置和一台伺服器，建立「零信任」。增量部署完成後，您就可以安全地關閉傳統或未加密的存取方法。

Thanks to Ross Zurowski, our intrepid designer, for the illustrations :)
感謝我們無畏的設計師 Ross Zurowski 提供的插圖 :)