wireguard docs
1.0.0
WireGuard の API リファレンス ガイド (セットアップ、構成、使用法と例を含む)。
すべての功績は、WireGuard プロジェクト、zx2c4、およびオリジナル ソフトウェアのオープン ソース貢献者に与えられます。
これは、より包括的なドキュメント、API リファレンス、サンプルを提供するという私の単独の非公式な試みです。
これらのドキュメント、サンプルコード、および問題トラッカーのソース: https://github.com/pirate/wireguard-docs より優れた HTML ページのバージョン: https://docs.sweeting.me/s/wireguard
WireGuard は、Jason Donenfeld らによって C で書かれたオープンソース VPN ソリューションで、IPSec/IKEv2、OpenVPN、L2TP などの他の最新のサーバー間 VPN 製品を悩ませている多くの問題を解決することを目的としています。これは、Tinc や MeshBird などの他の最新の VPN 製品といくつかの類似点、つまり、優れた暗号スイートと最小限の構成を共有しています。 2020 年 1 月の時点で、Linux カーネルの 5.6 バージョンに統合されており、ほとんどの Linux システムにそのまま出荷されることになります。
公式リンク
wg 、 wg-quickワイヤーガードの目標
コード例とドキュメントのソースについては、https://github.com/pirate/wireguard-docs を参照してください。
万里の長城の後ろに住んでいる場合でも、単にサーバー間でネットワークを形成しようとしている場合でも、WireGuard は優れたオプションであり、ネットワークを構築するための「レゴ ブロック」として機能します (ZFS がファイルシステムを構築するためのレゴ ブロックであるのとほぼ同じです) ）。
WireGuard が実行しないこと:
ただし、内部で WireGuard (Tailscale や AltheaNet など) を使用して、これらの問題に対する独自のソリューションを作成できます。
これらは、ドキュメントと設定例で使用されるデモのホスト名、ドメイン名、IP アドレス、および範囲です。独自のセットアップを行う場合は、これらを好みの値に置き換えてください。
example-vpn.devは、管理するパブリックにアクセス可能な任意のドメインに置き換えることができますpublic-server1 、 public-server2 、 home-server 、 laptop 、 phoneデバイスのホスト名に変更できます。192.0.2.1/24 、 192.0.2.3 、 192.0.2.3/32 、 2001:DB8::/64 、好みのサブネットとアドレスに置き換えることができます (例: 192.168.5.1/24 )。以下のこれらの文字列は、例を説明するためのプレースホルダー値として使用されているだけであり、特別な意味はありません。
構成内の IP アドレスを必ず変更してください。これらのドキュメントで使用されているブロックは、IETF によって例として予約されており、実際のネットワーク設定では決して使用しないでください。
192.0.2.0/24 (TEST-NET-1) IPv4 範囲例 RFC57372001:DB8::/32 IPv6 範囲例 RFC3849独自のセットアップに必要なプライベート範囲 (たとえば、 10.0.44.0/24を使用できますが、ピアが存在する LAN サブネット範囲と競合しないことを確認してください。
VPN に接続し、それ自体の VPN サブネット アドレス ( 192.0.2.3など) を登録するホスト。オプションで、カンマ区切りの CIDR 表記でサブネット範囲を指定することで、独自のアドレス以外のトラフィックをルーティングすることもできます。
NAT の背後にある他の VPN ピアのトラフィックを中継するためのフォールバックとして機能する、パブリックに到達可能なピア/ノード。バウンス サーバーは特別なタイプのサーバーではなく、他のピアと同様に通常のピアです。唯一の違いは、パブリック IP があり、カーネル レベルの IP 転送がオンになっていて、トラフィックを VPN にバウンスできることです。他のクライアントに。
詳細はこちら: https://tailscale.com/blog/how-nat-traversal-works/ (Tailscale は内部で Wireguard を使用しています)
公共のインターネットから独立した IP のグループ (例: 192.0.2.1-255 または 192.168.1.1/24)。通常、オフィスのインターネット LAN や家庭の Wi-Fi ネットワークなど、ルーターによって提供される NAT の背後にあります。
「マスク」を使用してサブネットとそのサイズを定義する方法。マスクが小さいほど、サブネットで使用できるアドレス ビットが増加し、範囲内の IP 数が増加します。最も一般的なもの:
192.0.2.1/32 (単一の IP アドレス、 192.0.2.1 ) ネットマスク = 255.255.255.255192.0.2.1/24 ( 192.0.2.0 ～ 192.0.2.255の 255 IP) ネットマスク = 255.255.255.0192.0.2.1/16 ( 192.0.0.0 ～ 192.0.255.255の 65,536 IP) ネットマスク = 255.255.0.0192.0.2.1/8 ( 192.0.0.0 ～ 192.255.255.255の 16,777,216 個の IP) ネットマスク = 255.0.0.00.0.0.1/0 ( 0.0.0.0 ～ 255.255.255.255の 4,294,967,296 個の IP) ネットマスク = 0.0.0.02001:DB8::/64https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
始めたばかりの人にとって、 192.0.2.1/32単一の IP を参照する奇妙でわかりにくい方法のように思えるかもしれません。ただし、この設計は、ピアが必要に応じて複数の表記を必要とせずに複数の IP を公開できるため、優れています。 192.0.2.3/32ような文字が表示される場合は、実際には192.0.2.3意味するだけであることに注意してください。
ネットワーク アドレス変換を実行する前にあるルーターによって提供されるプライベート IP を持つサブネット。個々のノードはインターネットから公的にアクセスできません。代わりにルーターが発信接続を追跡し、応答を正しい内部 IP (標準的なオフィス ネットワークなど) に転送します。 、ホーム Wi-Fi ネットワーク、無料の公衆 Wi-Fi ネットワークなど）
ノードのパブリックにアクセス可能なアドレス:ポート、たとえば123.124.125.126:1234またはsome.domain.tld:1234 (パブリック インターネット経由でアクセスできる必要があります。通常、そうでない限り、 192.0.2.1や192.168.1.1のようなプライベート IP は使用できません)同じサブネット上の他のピアは、そのアドレスを使用して直接アクセスできます)。
単一ノードの WireGuard 秘密キー。wg wg genkey > example.keyで生成されます (生成されたノードから離れることはありません)。
単一ノードの WireGuard 公開キーwg pubkey < example.key > example.key.pub (他のピアと共有) で生成されます。
ドメイン ネーム サーバー。DNS リクエストが VPN の外部に漏洩してトラフィックが明らかになるのを許可するのではなく、VPN クライアントのホスト名を IP に解決するために使用されます。リークは http://dnsleak.com でテストできます。
パブリック リレーは、NAT の背後にある VPN クライアント間の中間リレー サーバーとして機能する単なる通常の VPN ピアであり、受信した VPN サブネット トラフィックをシステム レベルで適切なピアに転送できます (WireGuard はこれがどのように行われるかを気にしません) 、カーネルnet.ipv4.ip_forward = 1および iptables ルーティング ルールによって処理されます)。
すべてのピアがパブリックにアクセスできる場合、そのうちの 1 つをリレー サーバーにするための特別な処理について心配する必要はありません。NAT の背後から接続するピアがある場合にのみ必要になります。
各クライアントは、その設定でパブリックにアクセス可能なサーバー/ピアを定義するだけで済みます。NAT の背後にある他のピアにバインドされたトラフィックは、パブリック リレーのAllowedIPsルート内のキャッチオール VPN サブネット (例: 192.0.2.1/24 ) に送られ、それに応じて転送されます。中継サーバーに到達すると。
要約すると、クライアント間の直接接続のみを設定する必要があります。バウンスする必要がある接続はピアとして定義しないでください。接続は最初にバウンス サーバーに向かい、そこから VPN を通って正しいクライアントにルーティングされる必要があるからです。
より複雑なトポロジも確実に実現可能ですが、一般的な WireGuard セットアップで使用される基本的なルーティング方法は次のとおりです。
Endpointアドレスとポートを使用して直接アクセス可能なノードを定義します。public-server2に接続する場合)、パブリックにアクセス可能なノードをハードコードされたEndpointで定義し、NAT ノードをハードコードなしで定義します。接続は NAT クライアント -> パブリック クライアントの順に開かれ、NAT クライアントからの発信PersistentKeepalive ping によって接続が維持されている限り、トラフィックはそれらの間で両方向に直接ルーティングされます。public-server1への接続を開く必要があり、接続が確立されている限り、トラフィックは中間バウンス サーバー経由で転送されます。生かされている。他のピアによって提供されるより具体的な (通常はより直接的な) ルートが利用可能な場合は優先されます。そうでない場合、トラフィックは最も具体性の低いルートにフォールバックし、 192.0.2.1/24キャッチオールを使用してトラフィックをバウンス サーバーに転送します。リレー サーバーのシステム ルーティング テーブル ( net.ipv4.ip_forward = 1 ) によって、VPN を経由して、そのトラフィックのルートを受け入れている特定のピアにルーティングされます。 WireGuard は、最速のルートを自動的に検索したり、まだ定義されていない場合はピア間の直接接続の形成を試行したりすることはなく、 [Peers]で最も具体的なルートから最も具体的でないルートに進むだけです。
ping 時間を測定して各ホップの一意の長さを把握し、次の出力を検査することで、特定のアドレスに対して WireGuard がどのルーティング方法を使用しているかを把握できます。
wg show wg0WireGuard はすべてのトラフィックに暗号化された UDP パケットを使用しますが、パケットの配信や順序付けは暗号化されたトンネル内の TCP 接続によって処理されるため、保証はありません。
さらに読む:
WireGuard は、他のほとんどの競合 VPN ソリューションよりも高速なパフォーマンスを主張していますが、正確な数値については議論があり、特定の暗号にハードウェア レベルのアクセラレーションが利用できるかどうかに依存する可能性があります。
WireGuard のパフォーマンスの向上は、カーネル レベルでルーティングを処理し、すべてのコアで実行される最新の暗号スイートを使用してトラフィックを暗号化することによって実現されます。また、WireGuard は、配信/順序保証のない UDP を使用することで、大きな利点を獲得します (TCP 上で実行される、または独自の配信保証メカニズムを実装する VPN と比較して)。
さらに読む:
WireGuard は、次のプロトコルとプリミティブを使用してトラフィックを保護します。
WireGuard の暗号化は、本質的に Trevor Perrin の Noise フレームワークをインスタンス化したものです。モダンでありながら、やはりシンプルです。他の VPN オプションはすべて、ネゴシエーションとハンドシェイクの混乱と複雑なステート マシンです。 WireGuard は VPN の Signal/Axolotl に似ていますが、ダブル ラチェット メッセージング プロトコルよりもはるかにシンプルで推論が (この場合は暗号的に) 簡単です。基本的にはVPNソフトのqmailです。コードは約 4000 行あります。競合他社よりも数桁小さいです。
https://news.ycombinator.com/item?id=14599834
さらに読む:
両方向の認証は、各ピアの単純な公開キーと秘密キーのペアを使用して実現されます。各ピアはセットアップ フェーズ中にこれらのキーを生成し、公開キーのみを他のピアと共有します。
各ノードの公開鍵/秘密鍵以外に、他の証明書や事前共有鍵は必要ありません。
キーの生成、配布、取り消しは、Ansible や Kubernetes Secrets などの別のサービスを使用して大規模なデプロイメントで処理できます。
キーの配布と展開に役立ついくつかのサービス:
wg0.confでキーをハードコーディングしたくない場合は、ファイルまたはコマンドを介してキーを読み取ることもできます。これにより、サードパーティのサービスを介したキーの管理がはるかに簡単になります。
[Interface]
...
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(cat /some/path/%i/privkey)技術的には、クライアントが同じキーを持つ 2 つのサーバーに同時に接続しない限り、複数のサーバーが同じ秘密キーを共有できます。これが適切な設定となるシナリオの例としては、ラウンドロビン DNS を使用して、単一サーバーを装っている 2 つのサーバー間の接続の負荷分散を行っている場合が挙げられます。ただし、ほとんどの場合、ピアが相互にトラフィックを読み取れず、個別に取り消すことができるように、各ピアは独自の公開鍵/秘密鍵ペアを持つ必要があります。
一般的なプロセスの概要:
apt install wireguardまたはpkg/brew install wireguard-toolsインストールします。wg genkey + wg pubkeywg0.conf WireGuard 構成ファイルを作成します。[Interface]サーバーがルートを受け入れるアドレスを定義するときは、VPN サブネット全体の CIDR 範囲を指定してください。 Address = 192.0.2.1/24[Peer]対応するリモート公開キーを使用して、VPN に参加するすべてのクライアントのピア セクションを作成します。wg0.conf作成する[Interface]トラフィックを中継しないクライアント ピアには必ず単一の IP を指定してくださいAddress = 192.0.2.3/32 。[Peer] NAT の背後にないパブリック ピアごとにピア セクションを作成します。バウンス サーバーとして機能するリモート ピアを定義するときは、VPN サブネット全体の CIDR 範囲を必ず指定してくださいAllowedIPs = 192.0.2.1/24 。トラフィックを中継せず、単純なクライアントとしてのみ機能するリモート ピアの個別の IP を必ず指定してくださいAllowedIPs = 192.0.2.3/32 。wg-quick up /full/path/to/wg0.confを使用して、メインリレーサーバーで WireGuard を開始します。wg-quick up /full/path/to/wg0.confを使用して、すべてのクライアント ピアで WireGuard を開始します。ping 192.0.2.3 、まず、 AllowedIPs = 192.0.2.3/32を持つピアへの直接ルートを確認し、その後、IP を受け入れているリレー サーバーにフォールバックします。サブネット全体で # install on Ubuntu
sudo add-apt-repository ppa:wireguard/wireguard
apt install wireguard
# install on macOS
brew install wireguard-tools
# install on FreeBSD
pkg install wireguard
# install on iOS/Android using Apple App Store/Google Play Store
# install on other systems using https://www.wireguard.com/install/#installation # to enable the kernel relaying/forwarding ability on bounce servers
echo " net.ipv4.ip_forward = 1 " | sudo tee -a /etc/sysctl.conf
echo " net.ipv4.conf.all.proxy_arp = 1 " | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
# to add iptables forwarding rules on bounce servers
sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADEnano wg0.conf # can be placed anywhere, must be referred to using absolute path (usually placed in /etc/wireguard/wg0.conf on most Linux systems) # generate private key
wg genkey > example.key
# generate public key
wg pubkey < example.key > example.key.pubwg-quick up /full/path/to/wg0.conf
wg-quick down /full/path/to/wg0.conf
# Note: you must specify the absolute path to wg0.conf, relative paths won't work
# If wg0.conf is in /etc/wireguard you can use the simpler:
wg-quick up wg0 # start/stop VPN network interface
ip link set wg0 up
ip link set wg0 down
# register/unregister VPN network interface
ip link add dev wg0 type wireguard
ip link delete dev wg0
# register/unregister local VPN address
ip address add dev wg0 192.0.2.3/32
ip address delete dev wg0 192.0.2.3/32
# register/unregister VPN route
ip route add 192.0.2.3/32 dev wg0
ip route delete 192.0.2.3/32 dev wg0 # show system LAN and WAN network interfaces
ip address show
# or if ip is not available:
ifconfig
# show system VPN network interfaces
ip link show wg0
# or
ifconfig wg0
# show WireGuard VPN interfaces
wg show all
wg show wg0 # show public IP address
ip address show eth0
# or
ifconfig eth0
# or
dig -4 +short myip.opendns.com @resolver1.opendns.com
# show VPN IP address
ip address show wg0 # show WireGuard routing table and peer connections
wg show
wg show wg0 allowed-ips
# show system routing table
ip route show table main
ip route show table local
# show system route to specific address
ip route get 192.0.2.3追加のログ記録を有効にするには、次の手順を実行します。
modprobe wireguard
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/controlログを追跡するには:
dmesg -wH最新のカーネルとセーフ ブートを備えたシステムでは、カーネル ログへのアクセスを許可するために、セキュア ブート DKMS 署名検証を無効にする必要がある場合があります。
mokutil --disable-verification
reboot # check that the main relay server is accessible directly via public internet
ping public-server1.example-vpn.dev
# check that the main relay server is available via VPN
ping 192.0.2.1
# check that public peers are available via VPN
ping 192.0.2.2
# check that remote NAT-ed peers are available via VPN
ping 192.0.2.3
# check that NAT-ed peers in your local LAN are available via VPN
ping 192.0.2.4 # install iperf using your preferred package manager
apt/brew/pkg/opkg install iperf
# check bandwidth over public internet to relay server
iperf -s # on public relay server
iperf -c public-server1.example-vpn.dev # on local client
# check bandwidth over VPN to relay server
iperf -s # on public relay server
iperf -c 192.0.2.1 # on local client
# check bandwidth over VPN to remote public peer
iperf -s # on remote public peer
iperf -c 192.0.2.2 # on local client
# check bandwidth over VPN to remote NAT-ed peer
iperf -s # on remote NAT-ed peer
iperf -c 192.0.2.3 # on local client
# check bandwidth over VPN to local NAT-ed peer (on same LAN)
iperf -s # on local NAT-ed peer
iperf -c 192.0.2.4 # on local client http://dnsleak.com を使用するか、ルックアップでリゾルバーをチェックして、DNS リークを確認します。
dig example.com AWireGuard 設定は INI 構文であり、通常はwg0.confというファイルで定義されます。システム上のどこにでも配置できますが、多くの場合は/etc/wireguard/wg0.confに配置されます。
構成パスは、 wg-quickコマンドを実行するときに引数として指定されます。例:
wg-quick up /etc/wireguard/wg0.conf (常に完全な絶対パスを指定します)
構成ファイル名は${name of the new WireGuard interface}.confの形式である必要があります。 WireGuard インターフェイス名には通常、 wgという接頭辞が付けられ、 0から始まる番号が付けられますが、正規表現^[a-zA-Z0-9_=+.-]{1,15}$に一致する任意の名前を使用できます。
設定ファイルは、WireGuard の起動にどのコマンドが優先されるかに応じて、 wg config オプションの限定されたセットを使用するか、より拡張されたwg-quickオプションを使用するかを選択できます。これらのドキュメントでは、より強力でユーザーフレンドリーな構成エクスペリエンスを提供するwg-quickを使用することを推奨しています。
定義にジャンプ:
¶ [Interface]
¶ # Name = node1.example.tld
¶ Address = 192.0.2.3/32
¶ ListenPort = 51820
¶ PrivateKey = localPrivateKeyAbcAbcAbc=
¶ DNS = 1.1.1.1,8.8.8.8
¶ Table = 12345
¶ MTU = 1500
¶ PreUp = /bin/example arg1 arg2 %i
¶ PostUp = /bin/example arg1 arg2 %i
¶ PreDown = /bin/example arg1 arg2 %i
¶ PostDown = /bin/example arg1 arg2 %i
¶ [Peer]
¶ # Name = node2-node.example.tld
¶ AllowedIPs = 192.0.2.1/24
¶ Endpoint = node1.example.tld:51820
¶ PublicKey = remotePublicKeyAbcAbcAbc=
¶ PersistentKeepalive = 25
[Interface]ローカル ノードの VPN 設定を定義します。
例
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.5/32
PrivateKey = <private key for phone.example-vpn.dev> [Interface]
# Name = public-server1.example-vpn.tld
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = <private key for public-server1.example-vpn.tld>
DNS = 1.1.1.1# Nameこれは、どの構成セクションがどのノードに属しているかを追跡するために使用される INI 構文の標準コメントです。WireGuard では完全に無視され、VPN の動作には影響しません。
注: # Nameを含むすべてのコメントは、特定の操作およびアプリケーションによって .conf ファイルから削除されます。ピアを識別する必要がある場合は、wireguard-vanity-keygen や Wireguard-vanity-address などの Wireguard バニティ キー ジェネレーターの使用を検討してください。これにより、ホストの公開キーにホスト名を含めることができます。キーの生成には数分 (4 文字)、数時間 (5 文字)、またはそれ以上かかる場合があるため、長い名前のホストには省略形を使用することを検討してください。
Addressローカル ノードがトラフィックをルーティングするアドレス範囲を定義します。ノードが VPN サブネットに参加する単純なクライアントであるか、複数のクライアント間でトラフィックを中継するバウンス サーバーであるかに応じて、これをノード自体の単一の IP (CIDR 表記で指定) に設定できます (例: 192.0.2.3/32)。 )、またはノードがトラフィックをルーティングできる IPv4/IPv6 サブネットの範囲。
例
ノードはそれ自体のトラフィックのみをルーティングするクライアントですAddress = 192.0.2.3/32
ノードは、トラフィックを他のピアに中継できるパブリック バウンス サーバーです。
ノードがパブリック バウンス サーバーとして機能する場合、ノード自体の単一の IP だけでなく、トラフィックをルーティングできるサブネット全体にこれを設定する必要があります。
Address = 192.0.2.1/24
Address = 192.0.2.1/24,2001:DB8::/64ListenPortノードがパブリック バウンス サーバーとして機能している場合、パブリック インターネットからの着信 VPN 接続をリッスンするポートをハードコーディングする必要があります。リレーとして機能しないクライアントは、この値を設定しないでください。
例
ListenPort = 51820ListenPort = 7000PrivateKeyこれはローカル ノードの秘密キーであり、他のサーバーと共有されることはありません。トラフィックを中継するパブリック バウンス サーバーであるか、VPN に参加する単純なクライアントであるかに関係なく、すべてのノードには秘密キー セットが必要です。
このキーはwg genkey > example.keyで生成できます。
例
PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=
DNSDHCP 経由で VPN クライアントに通知する DNS サーバー。ほとんどのクライアントは VPN 経由の DNS リクエストにこのサーバーを使用しますが、クライアントはノード上でこの値をローカルにオーバーライドすることもできます
例
DNS = 1.1.1.1DNS = 1.1.1.1,8.8.8.8Tableオプションで、WireGuard ルートに使用するルーティング テーブルを定義します。ほとんどのセットアップでは構成する必要はありません。
2 つの特別な値があります。「off」はルートの作成を完全に無効にし、「auto」（デフォルト）はルートをデフォルト テーブルに追加し、デフォルト ルートの特別な処理を有効にします。
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
例
Table = 1234MTUオプションで、ピアに接続するときに使用する最大伝送単位 (MTU、別名パケット/フレーム サイズ) を定義します。ほとんどのセットアップでは構成する必要はありません。
MTU は、エンドポイント アドレスまたはシステムのデフォルト ルートから自動的に決定されます。これは通常、賢明な選択です。
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
例
MTU = 1500PreUp必要に応じて、インターフェイスが起動される前にコマンドを実行します。このオプションは複数回指定でき、コマンドはファイル内に出現する順序で実行されます。
例
PreUp = ip rule add ipproto tcp dport 22 table 1234 PostUp必要に応じて、インターフェイスが起動された後にコマンドを実行します。このオプションは、PreUp と同様に複数回表示できます。
例
ファイルまたはコマンドの出力から構成値を読み取ります。
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command here)
行をファイルに記録するPostUp = echo "$(date +%s) WireGuard Started" >> /var/log/wireguard.log
別のサーバー上の Webhook をヒットするPostUp = curl https://events.example.dev/wireguard/started/?key=abcdefg
システムルーティングテーブルにルートを追加します。
PostUp = ip rule add ipproto tcp dport 22 table 1234
iptables ルールを追加して、WireGuard インターフェイスでのパケット転送を有効にします。
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
WireGuard にピア ドメインの IP アドレスを強制的に再解決させるPostUp = resolvectl domain %i "~."; resolvectl dns %i 192.0.2.1; resolvectl dnssec %i yes
PreDown必要に応じて、インターフェイスがダウンする前にコマンドを実行します。このオプションは、PreUp と同様に複数回表示できます。
例
行をファイルに記録するPostDown = echo "$(date +%s) WireGuard Going Down" >> /var/log/wireguard.log
別のサーバー上の Webhook をヒットするPostDown = curl https://events.example.dev/wireguard/stopping/?key=abcdefg
PostDown必要に応じて、インターフェイスがダウンした後にコマンドを実行します。このオプションは、PreUp と同様に複数回表示できます。
例
行をファイルに記録するPostDown = echo "$(date +%s) WireGuard Stopped" >> /var/log/wireguard.log
別のサーバー上の Webhook をヒットするPostDown = curl https://events.example.dev/wireguard/stopped/?key=abcdefg
WireGuard インターフェイスでパケットを転送する iptables ルールを削除します。
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]1 つ以上のアドレス (それ自体および/または他のピア) のトラフィックをルーティングできるリモート ピアの VPN 設定を定義します。ピアは、他のピアにトラフィックを中継するパブリック バウンス サーバー、または NAT の背後になく、自分自身のトラフィックのみをルーティングする LAN/インターネット経由で直接アクセス可能なクライアントのいずれかになります。
すべてのクライアントは、パブリック バウンス サーバー上でピアとして定義される必要があります。自分自身のトラフィックのみをルーティングする単純なクライアントは、パブリック リレーと直接アクセス可能なその他のノードのピアを定義するだけで済みます。個別の NAT 間には直接ルートが利用できないため、個別の NAT の背後にあるノードをパブリック サーバー構成の外部でピアとして定義しないでください。代わりに、NAT の背後にあるノードは、パブリック リレー サーバーと他のパブリック クライアントのみをピアとして定義し、VPN サブネットのルートを受け入れ、リモート NAT へのトラフィックをバウンスするパブリック サーバー上で、 AllowedIPs = 192.0.2.1/24を指定する必要があります。仲間たち。
要約すると、すべてのノードはメイン バウンス サーバー上で定義する必要があります。クライアント サーバーでは、ノードから直接アクセスできるピアのみをそのノードのピアとして定義する必要があります。バウンス サーバーによって中継される必要があるピアは除外され、中継サーバーのキャッチオール ルートによって処理されます。
以下のドキュメントで概要が説明されている構成では、単一サーバーpublic-server1パブリックにアクセス可能なクライアントと NAT 接続されたクライアントの混合に対するリレー バウンス サーバーとして機能し、それに応じて各ノードでピアが構成されます。
public-server1 wg0.conf (バウンスサーバー)
[peer]リスト: public-server2 、 home-server 、 laptop 、 phone
public-server2 wg0.conf (単純なパブリッククライアント)
[peer]リスト: public-server1
home-server wg0.conf (NAT の背後にある単純なクライアント)
[peer]リスト: public-server1 、 public-server2
laptop wg0.conf (NAT の背後にある単純なクライアント)
[peer]リスト: public-server1 、 public-server2
phoneのwg0.conf (NAT の背後にある単純なクライアント)
[peer]リスト: public-server1 、 public-server2
例
[Peer]
# Name = public-server2.example-vpn.dev
Endpoint = public-server2.example-vpn.dev:51820
PublicKey = <public key for public-server2.example-vpn.dev>
AllowedIPs = 192.0.2.2/32 [Peer]
# Name = home-server.example-vpn.dev
Endpoint = home-server.example-vpn.dev:51820
PublicKey = <public key for home-server.example-vpn.dev>
AllowedIPs = 192.0.2.3/32 [Peer]
# Name = public-server1.example-vpn.tld
Endpoint = public-server1.example-vpn.tld:51820
PublicKey = <public key for public-server1.example-vpn.tld>
# routes traffic to itself and entire subnet of peers as bounce server
AllowedIPs = 192.0.2.1/24
PersistentKeepalive = 25# Nameこれは、どの構成セクションがどのノードに属しているかを追跡するために使用される INI 構文の標準コメントです。WireGuard では完全に無視され、VPN の動作には影響しません。
Endpointリモート ピアのパブリックにアクセス可能なアドレスを定義します。これは、NAT の背後にあるピア、または安定したパブリックにアクセス可能な IP:PORT ペアを持たないピアでは省略する必要があります。通常、これはメイン バウンス サーバーでのみ定義する必要がありますが、以下の設定例のpublic-server2ような安定した IP を持つ他のパブリック ノードでも定義できます。
例
Endpoint = 123.124.125.126:51820 (IPv6 もサポートされています)Endpoint = public-server1.example-vpn.tld:51820AllowedIPsこれにより、ピアがトラフィックをルーティングする IP 範囲が定義されます。単純なクライアントでは、これは通常、単一のアドレス (単純なクライアント自体の VPN アドレス) です。バウンス サーバーの場合、これはリレー サーバーがトラフィックをルーティングできる IP またはサブネットの範囲になります。複数の IP およびサブネットは、カンマ区切りの IPv4 または IPv6 CIDR 表記を使用して指定できます (単一の /32 または /128 アドレスから、すべてを送信するデフォルト ルートを示す0.0.0.0/0および::/0まで)。そのピアを経由するインターネットと VPN トラフィック）。このオプションは複数回指定できます。
パケットのルーティング方法を決定するとき、システムは最も具体的なルートを最初に選択し、その後、より広範なルートにフォールバックします。したがって、 192.0.2.3宛てのパケットの場合、システムはまず192.0.2.3/32をアドバタイズするピアを探し、次に192.0.2.1/24または0.0.0.0/0などのより大きな範囲をアドバタイズするピアにフォールバックします。最後の手段。
例
ピアは、それ自体との間のトラフィックのみを受け入れる単純なクライアントです。
AllowedIPs = 192.0.2.3/32
ピアは、VPN トラフィックを他のすべてのピアにバウンスできるリレー サーバーです。
AllowedIPs = 192.0.2.1/24
ピアは、IPv6 を含むすべてのインターネットおよび VPN トラフィック (プロキシなど) をバウンスするリレー サーバーです。
AllowedIPs = 0.0.0.0/0,::/0
ピアは、それ自身と他の 1 つのピアのみにルーティングするリレー サーバーです。
AllowedIPs = 192.0.2.3/32,192.0.2.4/32
ピアは、それ自体とローカル LAN 上のすべてのノードにルーティングするリレー サーバーです。
AllowedIPs = 192.0.2.3/32,192.168.1.1/24
PublicKeyこれはリモート ノードの公開キーであり、すべてのピアと共有できます。すべてのノードには、トラフィックを中継するパブリック バウンス サーバーであるか、VPN に参加する単純なクライアントであるかに関係なく、公開キー セットが必要です。
このキーはwg pubkey < example.key > example.key.pubで生成できます。 (秘密キーexample.key生成する方法については上記を参照してください)
例
PublicKey = somePublicKeyAbcdAbcdAbcdAbcd=
PersistentKeepalive接続が NAT ピアからパブリック ピアに向かう場合、NAT ルータの接続テーブルで双方向接続を維持するために、NAT の背後にあるノードは定期的に発信 ping を送信する必要があります。
例
ローカルパブリックノードからリモートパブリックノードへ
永続的な ping は必要ないため、この値は未定義のままにする必要があります。
ローカルのパブリック ノードからリモートの NAT ノードへ
タイムアウトになった場合、サーバーはクライアントへの切断された接続を再度開くことができないため、接続を維持するのはクライアントの責任であるため、この値は未定義のままにする必要があります。
ローカル NAT ノードからリモート パブリック ノードへPersistentKeepalive = 25場合、ローカル NAT ルーターの接続テーブルで接続を開いたままにして 25 秒ごとに ping を送信します。
これらのドキュメントの例は主にIPv4を使用していますが、WireGuardはIPv6 CIDR表記をネイティブにサポートし、IPv4をサポートするあらゆる場所でアドレスして、他のサブネット範囲またはアドレスと同じように追加します。
例
[Interface]
Address = 192.0.2.3/24, 2001:DB8::/64
[Peer]
...
AllowedIPs = 0.0.0.0/0, ::/0サーバーからサーバーへのサブネットとして使用するだけでなく、すべてのインターネットトラフィックをVPNを介して転送したい場合は、パイプするピアのAllowedIPs定義に0.0.0.0/0, ::/0を追加できます。あなたの交通。
VPNの外側でIPv6パケットの漏れを避けるためにIPv4トラフィックのみを転送する場合でも、IPv6キャッチオールも指定してください。
https://www.reddit.com/r/wireguard/comments/b0m5g2/ipv6_leaks_psa_for_anyone_here_using_wireguard_to/
例
[Interface]
# Name = phone.example-vpn.dev
Address = 192.0.2.3/32
PrivateKey = <private key for phone.example-vpn.dev>
[Peer]
# Name = public-server1.example-vpn.dev
PublicKey = <public key for public-server1.example-vpn.dev>
Endpoint = public-server1.example-vpn.dev:51820
AllowedIPs = 0.0.0.0/0, ::/0WireGuardは、パブリックリレーサーバーを必要とせずにNATの背後にある2つのクライアント間でネイティブに接続することがありますが、ほとんどの場合、これは不可能です。 Nat-to-Nat接続は、少なくとも1つのホストに安定した、公開されているIPアドレスを持っている場合にのみ可能です。それが動的DNSで更新されたFQDNを使用しているか、静的なパブリックIPを使用しているかどうかにかかわらず、事前にハードコードできるポートペア発信パケットによって開かれた非ランダム化されたNATポートは、すべてのピアが事前に通信できる限り、何でも機能し、接続が開始されても変更されません。
WireGuardには、他のホストを動的に検索するために使用できるシグナルレイヤーまたはパブリックスタンサーバーがないため、既知のポートとアドレスを事前に構成する必要があります。 WeBRTCは、2つのNAT間の接続を動的に構成できるプロトコルの例ですが、これを実行して、帯域外シグナリングサーバーを使用して各ホストのIP：ポートコンボを検出します。 WireGuardにはこれがないため、ハードコーディングされたEndpoint + ListenPortでのみ動作します（および不活動後にドロップしないでPersistentKeepalive ）。
TailscaleのNat Traversalの聖書から詳細をご覧ください：https：//tailscale.com/blog/how-nat-traversal-works/
Endpointを定義する必要があります。安定したIPアドレスのないNATの後ろにいる場合は、少なくとも1つのピアに安定した公開可能なドメイン/IPを使用するには、動的DNSまたは別のソリューションを使用する必要があります。ListenPortが定義されている必要があります。これは、NATルーターがUDPソースポートランダム化を行わないでください。そうしないと、リターンパケットはハードコードされたListenPortに送信され、ルーターによってドロップされます。発信パケットのNATPersistentKeepalive有効になっている必要があります。そうすれば、NATのルーティングテーブルで接続を保持するために継続的に発信pingを送信する必要があります。 拒否される初期パケットを送信するこのプロセスは、ルーターが応答を受け入れるための転送ルールを作成したという事実を「UDPホールパンチ」と呼びます。
UDPパケットを送信すると、ルーター（通常）は、ソースアドレスとポートを宛先アドレスとポートにマッピングする一時的なルールを作成します。宛先アドレスとポート（および他のポートはありません）から戻ってくるUDPパケットは、元のソースアドレスとポート（他にはありません）に渡されます。これは、ほとんどのUDPアプリケーションがNAT（Bittorrent、Skypeなど）の背後で機能する方法です。このルールは数分の不活動の後にタイムアウトするため、NATの背後にあるクライアントは、通常の発信パケットを送信して開いたままにしなければなりません（ PersistentKeepaliveを参照）。
両方のエンドポイントがNATまたはファイアウォールの背後にある場合、これを機能させるには、両方のエンドポイントがほぼ同時にパケットを各他の人に送信する必要があります。これは、双方が事前にそれぞれのパブリックIPアドレスとポート番号を事前に知る必要があることを意味します。これは、 wg0.confの両側のハードコーディング事前定義されたポートによって達成されます。
2019年の時点で、使用されていた作業に使用されていた古いホールパンチ方法の多くはもはや効果的ではありません。 1つの例は、ICMP時間を偽造したPWNATによって開拓された新しい方法で、NATの外側からの応答を超えて、パケットをNATのピアに戻し、それによって独自のソースポートを漏らしました。 NAT-NAT接続の両側（上記のように）のハードコードUDPポートとパブリックIPSは、まだわずかな割合のネットワークで動作します。一般に、ネットワークが「企業」が多いほど、パブリックUDPポートを穴を開ける可能性が低くなります（たとえば、商業的なパブリックWi-Fiおよびセルデータはしばしば機能しません）。
すべてのエンドポイントがNATの背後にある場合、NATからナットへの接続は不可能です（例：ほとんどのセルラーデータネットワークなど）。どちらの側もListenPortをハードコードし、発信Ping後にNATがそのポートのトラフィックを受け入れることを保証することができないため、ピアと接続の間の最初のホールパンチのポートを調整することはできません。このため、通常、LTE/3Gネットワークで電話間接続を行うことはできませんが、オフィスや家に安定した公共のIPを持っていて、携帯電話や携帯電話への接続を行うことができるかもしれません。ソースポートランダム化を行います。
厳密なソースポートランダム化を備えたNATからNATへの接続が可能です。両側に相手のIP：ポートタプルを伝えるためにシグナリングサーバーが必要です。 WireGuardでこれを達成するいくつかの実装を次に示します。
多くのユーザーは、起動時のホスト名のみを解決するため、動的IPが変更されるたびにワイヤガードを再起動する必要があると報告しています。 WireGuardにダイナミックDNS Endpointホスト名をより頻繁に再分解するように強制するには、 PostUpフックを使用して数分または時間ごとにワイヤガードを再起動することをお勧めします。
クライアントとサーバーのNetCatを使用して、双方向接続を開くためにどのポートと接続順序が機能するかを確認することでnc -v -u -p 51820 <address of peer2> 51820ホールパンチのセットアップが実行可能かどうかを確認できます。 PEER1）およびnc -v -u -l 0.0.0.0 51820 （PEER2）、両方のWindowsを入力して、双方向トラフィックを取得できるかどうかを確認します行く。どのピアが最初のパケットを送信するかに関係なく機能しない場合、ワイヤーガードはパブリックリレーサーバーなしでピア間で動作することができません。
Nat-to-Nat接続は、多くの場合、より不安定であり、他の制限があります。そのため、フォールバックパブリックリレーサーバーを持つことは依然としてアドバイスされています。
例
PEER1：
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer2.example-vpn.dev:12000
PersistentKeepalive = 25PEER2：
[Interface]
...
ListenPort 12000
[Peer]
...
Endpoint = peer1.example-vpn.dev:12000
PersistentKeepalive = 25注：このセクションは、動的なパブリックEndpointアドレスではなく、VPNサブネット内の動的なピアIPに関するものです。
ピアIPの動的割り当て（固定ピアのみを持つのではなく）が開発されています。WIP実装はhttps：//github.com/wireguard/wg-dynamicで入手できます。
また、 PostUpを使用して、実行時にファイルからIP値を読み取ることにより、動的割り当てシステムを自分で構築することもできます（以下を参照）。
例
[Interface]
...
PostUp = wg set %i allowed-ips /etc/wireguard/wg0.key <(some command)https://git.zx2c4.com/wireguard-go/about/
GOで書かれた準拠のユーザーランドワイヤガードの実装。
https://git.zx2c4.com/wireguard-rs/about/
Rustで書かれたWireGuardの不完全で安全なユーザースペースの実装（一般のために準備ができていません）。
https://git.zx2c4.com/wireguard-hs/about/
Haskellで書かれたWireGuardの不完全で不安定なユーザースペースの実装（一般に準備ができていません）。
https://github.com/cloudflare/boringtun
Rust（CloudFlareによって書かれた別のフォーク）で書かれた、非準拠、独立したワイヤーガードの実装。 https://blog.cloudflare.com/boringtun-userspace-wireguard-rust/を参照してください
プラットフォーム固有のワイヤーガードアプリ
https://git.zx2c4.com/wireguard-ios/about/
https://git.zx2c4.com/wireguard-android/about/
https://git.zx2c4.com/wireguard-windows/about/
すべてのユーザースペースの実装は、カーネルランドで実行されるネイティブCバージョンよりも遅くなりますが、ユーザーランドで実行することで他の利点を提供します（例：容易なコンテナ化、互換性など）。
これらは、構成、展開、キー管理、および接続を支援するためにワイヤガードをラップするGUIおよびCLIツールです。
これらのショートカットのクレジットは、https：//www.ericlight.com/new-things-i-didnt-know-about-wireguard.htmlに送信されます
WireGuardは、公開キーがインターフェイスの秘密鍵と一致するピアを無視します。そのため、どこにでもピアの単一のリストを配布し、各サーバーで[Interface]個別に定義することができます。
参照：https：//lists.zx2c4.com/pipermail/wireguard/2018-december/003703.html
これをこのようにwg addconfと組み合わせることができます。
各ピアには、 [Interface]セクションのみが含まれる[独自の/etc/wireguard/wg0.confファイルがあります。
各ピアには、すべてのピアを含む共有/etc/wireguard/peers.confファイルもあります。
wg0.confファイルにはPostUp = wg addconf /etc/wireguard/peers.conf PostUpフックもあります。
適切なオーケストレーションプラットフォームを介して、Dropboxのようなはるかに歩行者、またはCephのような野生のものを介して、 peers.confをどのように共有したいかを決定するのはあなた次第です。私は知らないが、インターフェイスと同じかどうかを心配することなく、ピアセクションを乱暴に投げつけることができるのはとても素晴らしいことです。
任意のコマンドからの構成値を設定するか、ファイルから値を読み取ることで設定できます。これにより、Kubernetes SecretやAWS KMSのようなサードパーティサービスから実行時にキーを読み取ることができるため、キー管理と展開がはるかに簡単になります。
参照：https：//lists.zx2c4.com/pipermail/wireguard/2018-december/003702.html
例
次のようなことをすることで、ファイルとしてPrivateKeyとして読むことができます。
PostUp = wg set %i private-key /etc/wireguard/wg0.key <(some command)
WireGuardは、さまざまな程度の簡単でDockerで実行できます。最も単純な場合、 --privilegedおよび--cap-add=all引数をDockerコマンドに追加して、カーネルモジュールの負荷を有効にすることができます。
セットアップはやや複雑になり、達成しようとしていることに大きく依存しています。 WireGuard自体をコンテナで実行し、ネットワークインターフェイスをホストに公開するか、ホストでワイヤーガードを実行して特定のコンテナにインターフェイスを公開することもできます。
Dockerコンテナvpn_testの例については、WireGuardリレーサーバーを介してすべてのトラフィックをルーティングする例については、以下を参照してください。
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
ports :
- 51820:51820/udp
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro wg0.conf ：
[Interface]
# Name = relay1.wg.example.com
Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey = oJpRt2Oq27vIB5/ UVb7BRqCwad2YMReQgH5tlxz8YmI =
DNS = 1.1.1.1,8.8.8.8
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT ; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT ; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
# Name = peer1.wg.example.com
PublicKey = I+hXRAJOG/UE2IQvIHsou2zTgkUyPve2pzvHTnd/ 2Gg =
AllowedIPs = 192.0.2.2/32この例では、 speedtestコンテナ内からのすべてのトラフィックがWireGuard VPNを通過します。いくつかのトラフィックのみをルーティングするには、以下のwg0.confの0.0.0.0/0 、VPNを介してルーティングするサブネット範囲に置き換えます。
docker-compose.yml ：
version : ' 3 '
services :
wireguard :
image : linuxserver/wireguard
cap_add :
- NET_ADMIN
- SYS_MODULE
volumes :
- /lib/modules:/lib/modules
- ./wg0.conf:/config/wg0.conf:ro
vpn_test :
image : curlimages/curl
entrypoint : curl -s http://whatismyip.akamai.com/
network_mode : ' service:wireguard ' wg0.conf ：
[Interface]
# Name = peer1.wg.example.com
Address = 192.0.2.2/32
PrivateKey = YCW76edD4W7nZrPbWZxPZhcs32CsBLIi1sEhsV/ sgk8 =
DNS = 1.1.1.1,8.8.8.8
[Peer]
# Name = relay1.wg.example.com
Endpoint = relay1.wg.example.com:51820
PublicKey = zJNKewtL3gcHdG62V3GaBkErFtapJWsAx+ 2um0c0B1s =
AllowedIPs = 192.0.2.1/24,0.0.0.0/0
PersistentKeepalive = 21詳細については、以下のDockerセクションを参照してください。
より詳細な手順については、上記のQuickStartガイドとAPIリファレンスを参照してください。 https://github.com/pirate/wireguard-exampleの完全なサンプルセットアップをここからダウンロードすることもできます。
変更を提案する：https：//github.com/pirate/wireguard-docs/issues
