概要
WireGuard securely encapsulates IP packets over UDP. You add a WireGuard interface, configure it with your private key and your peers’ public keys, and then you send packets across it. All issues of key distribution and pushed configurations are out of scope of WireGuard; these are issues much better left for other layers, lest we end up with the bloat of IKE or OpenVPN. In contrast, it more mimics the model of SSH and Mosh; both parties have each other’s public keys, and then they’re simply able to begin exchanging packets through the interface.
wireguard
WireGuardは、IPパケットをUDP上にセキュアにカプセル化する。
WireGuardインターフェースを追加して、プライベートキーとPeerのパブリックキーを設定すると、パケットを送ることができる。
キー配布や設定などについては、WireGuardのスコープ外とする。これらは他のレイヤーに任せておいた方が良いもので、IKEやOpenVPNの話でいっぱいにならないようにする。
対照的に、WireGuardは、SSHやMoshのモデルを模倣している。両者はお互いのパブリックキーを持って、インターフェースを通してシンプルにパケットをやり取りし始めることができる。
Simple Network Interface
WireGuard works by adding a network interface (or multiple), like eth0 or wlan0, called wg0 (or wg1, wg2, wg3, etc). This network interface can then be configured normally using ifconfig(8) or ip-address(8), with routes for it added and removed using route(8) or ip-route(8), and so on with all the ordinary networking utilities. The specific WireGuard aspects of the interface are configured using the wg(8) tool. This interface acts as a tunnel interface.
wireguard
WireGuardは、eth0やwlan0のようなwg0と呼ばれる、ネットワークインターフェースを追加することで動く。
このネットワークインターフェースはたいていifconfigやip-addressコマンドを使って設定でき、ルートについては、routeやip-routeコマンドを使って追加削除でき、その他の通常のネットワーキングユーティリティも同様である。
インターフェースの特殊なWireGuardの設定は、wgツールで変更できる。
WireGuard associates tunnel IP addresses with public keys and remote endpoints. When the interface sends a packet to a peer, it does the following:
1. This packet is meant for 192.168.30.8. Which peer is that? Let me look… Okay, it’s for peer ABCDEFGH. (Or if it’s not for any configured peer, drop the packet.)
2. Encrypt entire IP packet using peer ABCDEFGH’s public key.
3. What is the remote endpoint of peer ABCDEFGH? Let me look… Okay, the endpoint is UDP port 53133 on host 216.58.211.110.
4. Send encrypted bytes from step 2 over the Internet to 216.58.211.110:53133 using UDP.
wireguard
WireGuardはトンネルIPアドレスとパブリックキー、リモートエンドポイントを紐づける。
インターフェースがパケットをPeerに送信する際に、以下のような動作をする。
- このパケットが192.168.30.8に向けられている。それはどのPeerか？見てみよう。OK、これは「ABCDEFGH」Peerだ！
※もしくは、どれにも設定されていないPeerだったら、ここでパケットは破棄される - 「ABCDEFGH」のパブリックキーを使って、全てのIPパケットを暗号化する。
- 「ABCDEFGH」Peerのリモートエンドポイントは何だ？見てみよう。OK、エンドポイントはホスト216.58.211.110のUDPポート53133だ！
- 先ほど暗号化されたデータをインターネット経由でUDPを使って216.58.211.110:53133に送ろう。
When the interface receives a packet, this happens:
1. I just got a packet from UDP port 7361 on host 98.139.183.24. Let’s decrypt it!
2. It decrypted and authenticated properly for peer LMNOPQRS. Okay, let’s remember that peer LMNOPQRS’s most recent Internet endpoint is 98.139.183.24:7361 using UDP.
4. Once decrypted, the plain-text packet is from 192.168.43.89. Is peer LMNOPQRS allowed to be sending us packets as 192.168.43.89?
4. If so, accept the packet on the interface. If not, drop it.
Behind the scenes there is much happening to provide proper privacy, authenticity, and perfect forward secrecy, using state-of-the-art cryptography.
wireguard
インターフェースがパケットを受信する際は、以下のような動作をする。
- ちょうどホスト98.13.9.183.24のUDPポート7361からパケットを受け取ったところだ。復号（化）しよう！
- 「LMNOPQRS」Peerで適切に復号、認証できた。OK、「LMNSOPRS」Peerの直近のインターネット側のエンドポイントは98.139.183.24のUDPポート7361を覚えておこう！
- 一旦復号すると、プレーンテキストパケットは192.168.43.89からのものだった。「LMNSOPQRS」Peerは192.168.43.89として我々にパケットを送れるように許可していたっけ？
- もしそうであれば、インターフェースはパケットを受け入れて、そうでないなら破棄される。
この裏では、最先端の暗号化技術を使って、適切なプライバシーや認証情報送って、セキュリティを完全にしたりと、もっといろいろなことが起こっている。
Cryptokey Routing
At the heart of WireGuard is a concept called Cryptokey Routing, which works by associating public keys with a list of tunnel IP addresses that are allowed inside the tunnel. Each network interface has a private key and a list of peers. Each peer has a public key. Public keys are short and simple, and are used by peers to authenticate each other. They can be passed around for use in configuration files by any out-of-band method, similar to how one might send their SSH public key to a friend for access to a shell server.
wireguard
WireGuardの中心は、「Cryptokey」ルーティングと呼ばれるコンセプトで、パブリックキーとトンネル内で許可されたIPアドレスのリストを関連づけることで動作する。
各ネットワークインターフェースはプライベートキーとPeerのリストを持っている。
各Peerはパブリックキーを持っている。パブリックキーは短くてシンプルで、Peerでお互いを認証するために利用される。SSHパブリックキーをシェルサーバにアクセスする友人に送るのと同じように、Out-of-Band方式で設定ファイル内で使いまわされる。
For example, a server computer might have this configuration:
wireguard
例として、サーバ側の設定ファイルを以下に記載する。
[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820
[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
[Peer]
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
AllowedIPs = 10.192.122.4/32, 192.168.0.0/16
[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs = 10.10.10.230/32
And a client computer might have this simpler configuration:
wireguard
クライアント側が以下のよりシンプルな設定。
[Interface]
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841
[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0
In the server configuration, each peer (a client) will be able to send packets to the network interface with a source IP matching his corresponding list of allowed IPs. For example, when a packet is received by the server from peer
wireguardgN65BkIK..., after being decrypted and authenticated, if its source IP is 10.10.10.230, then it’s allowed onto the interface; otherwise it’s dropped.
上記サーバ設定では、送信元IPが対応する許可IPのリストとマッチすれば、それぞれのPeerがネットワークインターフェースにパケットを送れる。
一例として、「gN65BkIK…」Peerからパケットを受け取った場合、復号して認証された後は、その送信元IPが10.10.10.230ならインタフェースで許可され、それ以外は破棄される。
In the server configuration, when the network interface wants to send a packet to a peer (a client), it looks at that packet’s destination IP and compares it to each peer’s list of allowed IPs to see which peer to send it to. For example, if the network interface is asked to send a packet with a destination IP of 10.10.10.230, it will encrypt it using the public key of peer
wireguardgN65BkIK..., and then send it to that peer’s most recent Internet endpoint.
上記サーバ設定では、ネットワークインターフェースがPeerにパケットを送信したい場合は、そのパケットの宛先IPを見て、それぞれの許可IPと比べて、どのPeerに送信するかがわかる。
一例として、ネットワークインターフェースが10.10.10.230にパケットを送信するよう依頼されたなら、「gN65BkIK…」Peerのパブリックキーで暗号化して、直近のインターネット側のエンドポイントに送信する。
In the client configuration, its single peer (the server) will be able to send packets to the network interface with any source IP (since 0.0.0.0/0 is a wildcard). For example, when a packet is received from peer
wireguardHIgo9xNz..., if it decrypts and authenticates correctly, with any source IP, then it’s allowed onto the interface; otherwise it’s dropped.
上記クライアント設定では、1つのPeer（サーバ）がどの送信元IPからでもネットワークインターフェースにパケットを送信できる。
一例として、「HIgo9xNz…」Peerからパケットを受け取る際には、正しく、復号、認証されたなら、どの送信元IPだとしてもインタフェースでは許可される。
In the client configuration, when the network interface wants to send a packet to its single peer (the server), it will encrypt packets for the single peer with any destination IP address (since 0.0.0.0/0 is a wildcard). For example, if the network interface is asked to send a packet with any destination IP, it will encrypt it using the public key of the single peer
wireguardHIgo9xNz..., and then send it to the single peer’s most recent Internet endpoint.
上記クライアント設定では、ネットワークインターフェースが1つのPeer（サーバ）にパケットを送信したい場合、パケットを暗号化し、どの宛先IPにも送信できる。
一例として、ネットワークインターフェースがどの宛先IPにでもパケットを送信することを依頼されたなら、「HIgo9xNz…」Peerのパブリックキーで暗号化して、そのPeerの直近のインターネット側エンドポイントに送信できる。
In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list.
wireguard
This is what we call a Cryptokey Routing Table: the simple association of public keys and allowed IPs.
Any combination of IPv4 and IPv6 can be used, for any of the fields. WireGuard is fully capable of encapsulating one inside the other if necessary.
言い換えるなら、パケットを送信する際には、許可IPリストがルーティングテーブルとして振る舞い、パケットを受信する際には、IPリストがアクセスコントロールリストとして振舞う。
これが「Cryptokey」ルーティングテーブルと呼ばれる所以で、シンプルなパブリックキーと許可IPの紐付けである。
どのようなフィールドにも、IPv4とIpv6のどのような組み合わせも利用できる。WireGuardは、必要であれば、他のものの中にそれをカプセル化する完全な能力を有している。
Because all packets sent on the WireGuard interface are encrypted and authenticated, and because there is such a tight coupling between the identity of a peer and the allowed IP address of a peer, system administrators do not need complicated firewall extensions, such as in the case of IPsec, but rather they can simply match on “is it from this IP? on this interface?”, and be assured that it is a secure and authentic packet. This greatly simplifies network management and access control, and provides a great deal more assurance that your iptables rules are actually doing what you intended for them to do.
weireguard
WireGuardインターフェイスに送られた全てのパケットは暗号化、認証されるので、またPeerの一意性とIPアドレスがこのように厳しくカップリングされるので、システム管理者はIPSecのような複雑なファイアウォール拡張を必要としないが、シンプルに「このIPから？このインターフェイスに？」をマッチさせるだけで、セキュアで正しいパケットだということが保証される。
このおかげでネットワーク管理やアクセスコントロールを非常に単純化させ、大きなやりとりでも自分で意図した通りにIPテーブルのルールが実際に動くことを保証する。
Built-in Roaming
The client configuration contains an initial endpoint of its single peer (the server), so that it knows where to send encrypted data before it has received encrypted data. The server configuration doesn’t have any initial endpoints of its peers (the clients). This is because the server discovers the endpoint of its peers by examining from where correctly authenticated data originates. If the server itself changes its own endpoint, and sends data to the clients, the clients will discover the new server endpoint and update the configuration just the same. Both client and server send encrypted data to the most recent IP endpoint for which they authentically decrypted data. Thus, there is full IP roaming on both ends.
wireguard
クライアントの設定では、1つのPeer（サーバ）の初期エンドポイントを含むので、暗号化データを受信する前に、暗号化したデータをどこに送るべきかを知っている。
サーバの設定では、Peer（クライアント）のどの初期エンドポイントも持っていない。それはサーバが正しく認証されたデータがどこから派生されたかを検査することでPeerのエンドポイントを発見するからである。
サーバ自身が自分のエンドポイントを変更できるなら、データをクライアントに送って、クライアントが新しいサーバのエンドポイントを発見し、同じように設定を更新する。
クライアントとサーバはともに暗号化データを直近のIPに送り、正しくデータを復号する。そうやって、完全なIPローミングを両者間で行っている。
