Linux での WireGuard サーバーの設定（wg0、NAT、ピア）

管理用ポートをパブリックインターネットに公開することなく、ホストされたインフラストラクチャへのプライベートアクセスを確保したい場合は、WireGuardサーバーを実行してください。WireGuardは公開鍵認証を採用しており、Linuxカーネル5.6以降ではカーネル内部で動作し、一度起動すればバックグラウンドで静かに動作し続けます。この記事では、WireGuardサーバーを使用すべき場面、起動方法 wg0、そしてピア間の接続を日常的に維持する方法について解説します。

WireGuardサーバーの使用場面

設定のほとんどは、リモートアクセス、サーバー間接続、サイト間ルーティングの3つのパターンに分類されます。

リモートアクセスの場合は、VPSまたは専用ホスト上でサーバーを実行し、管理用トラフィックをトンネル経由でルーティングします。各ピアで AllowedIPs 各ピアでプライベート管理サブネット（例： 10.0.0.0/24）に設定し、内部システム向けのトラフィックのみがトンネルを経由するようにします。それ以外のトラフィックはすべて、ユーザーのローカル接続上で処理されます。ユーザーが自宅やモバイルネットワークから接続する場合は、NATセッションが切断されないように、クライアント側で PersistentKeepalive = 25 をクライアント側に追加し、NATセッションが切断されないようにします。

サーバー間接続の場合、 AllowedIPs を狭く保ってください。通常は単一の /32 または小規模なバックエンドサブネットに限定します。これにより、無関係なトラフィックがトンネルに引き込まれるのを防ぎ、ルーティングを予測可能な状態に保つことができます。

サイト間接続の場合は異なります。WireGuardホストはサブネット間のゲートウェイとして機能するため、IP転送を有効にし、NATルールで返信トラフィックを適切なインターフェースから送信するように設定する必要があります。

サーバーの設定

サーバーは秘密鍵を保持し、デフォルトでUDP 51820 でリスニングし、トンネルを終了させます。上記の 3 つのパターンすべてで、同じ基本設定が機能します。

鍵と wg0.conf

サーバーの鍵ペアを生成します:

wg genkey | sudo tee /etc/wireguard/server_private.key | wg pubkey | sudo tee /etc/wireguard/server_public.key

秘密鍵を安全に保管します：

sudo chmod 600 /etc/wireguard/server_private.key

秘密鍵はサーバー上に残します。公開鍵はピアに提供するものです。

作成 /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o <PUBLIC_IFACE> -j MASQUERADE
 
[Peer]
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.8.0.2/32

ドロップする送信インターフェースを特定し、 <PUBLIC_IFACE> 以下の設定で:

ip -o -4 route show to default | awk '{print $5}'

転送、ファイアウォール、およびNAT

リスニングポートを開く:

sudo ufw allow 51820/udp

次の行を追加してIP転送を有効にする /etc/sysctl.conf:

net.ipv4.ip_forward = 1

再起動せずに適用するには：

sudo sysctl -p

以下の PostUp および PostDown 行を wg0.conf の行は、インターフェースが起動または停止した際にNATマスカレードルールを追加・削除します。これらがなければ、LANからの返信トラフィックはピアに決して到達しません。

トンネルの起動

wg-quick を実行することで、インターフェース、ルーティング、および PostUp/PostDown フックを1つのコマンドで処理します：

sudo wg-quick up wg0

再起動後の自動起動を行うには、systemd ユニットを有効にします:

sudo systemctl enable --now wg-quick@wg0

ステータスを確認するには：

sudo wg show

最近の latest handshake 行が、トンネルが正常に動作していることを確認します。古い情報や空の行が表示される場合は、ファイアウォール、両側の鍵、およびピアの AllowedIPs.

ピアの追加と削除

各ピアには独自の鍵ペアが必要です。クライアント側で鍵ペアを生成し、そのピアの公開鍵を wg0.conf 新しい [Peer] ブロックに AllowedIPs エントリでトンネルIPを割り当てた新しい

単一のデバイスについては /32 を使用します：

AllowedIPs = 10.8.0.3/32

これにより、あるピアが別のピアに割り当てられたアドレスを要求するのを防ぎます。スプリットトンネルアクセスでは、トンネルを経由させるべきプライベートサブネットのみをリストアップしてください。例： AllowedIPs = 10.8.0.0/24.

アクティブなセッションを切断せずに設定変更を適用するには：

sudo wg syncconf wg0 <(wg-quick strip wg0)

ピアの削除も同様の方法で行います。その [Peer] ブロックを wg0.conf から削除し、 syncconf を再度実行します。

トラブルシューティング

ピアが接続しているにもかかわらず、相手側のリソースに到達できない場合、その原因は通常、以下の4つのいずれかです：

• IPフォワーディングがオフになっている
• NATマスカレードルールが設定されていない
• NATルール内の送信インターフェースが間違っている
• AllowedIPs 宛先が含まれていない

転送設定を確認してください：

cat /proc/sys/net/ipv4/ip_forward

以下の結果が返されるはずです 1。もし 0が返された場合は、sysctlの変更が反映されていないか、保存されていません。

NATルールと送信インターフェースを確認してください:

sudo iptables -t nat -L POSTROUTING
ip route get 1.1.1.1

2番目のコマンドは、実際のアウトバウンドインターフェース名（例： ens3, enp1s0、あるいは eth0などです。これは、MASQUERADEルール内のインターフェースと一致している必要があります。

ハンドシェイク自体が確立されていない場合は、UDP 51820 がファイアウォールおよび上流のプロバイダで開放されているか、また双方が相手側の正しい公開鍵を持っているかを確認してください。

アイドル状態の UDP セッションを切断する家庭用またはモバイル NAT の背後にあるピアについては、 PersistentKeepalive = 25 を設定してください。

鍵のローテーションと事前共有鍵

数ヶ月間接続が維持されるトンネルの場合、鍵は年に1回程度ローテーションしてください。新しい鍵ペアを生成し、両端点を更新した上で、 wg syncconf。2つのピア間で秘密鍵を再利用しないでください。そうするとルーティングの競合が発生し、両者間の通信が途絶えてしまいます。

公開鍵認証に加えてセキュリティ層を追加するには、ピアごとに事前共有鍵を追加します：

wg genpsk

結果を PresharedKey = <PSK> に [Peer] ブロックに追加してください。WireGuardはPSKをハンドシェイクに組み込むため、何らかの方法で非対称鍵の1つを侵害されたとしても、攻撃者はPSKなしではトラフィックを復号できません。

日常的に役立つコマンド：

WireGuardトンネルを終了させ、プライベートトラフィックをインフラストラクチャ内にルーティングするための、安定した、外部からアクセス可能なホストが必要な場合は、FDCのデータ転送量無制限のVPSプランをご検討ください。