How to Configure a WireGuard Point-to-Site VPN Server on Debian 12

A WireGuard point-to-site VPN on Debian 12 (Bookworm) is a practical way to let laptops, phones, or remote workstations reach a server or route traffic through it. One important clarification comes first: WireGuard does not have a special “server mode.” Every participant is a peer. In a point-to-site design, one Debian host simply acts as the stable, publicly reachable hub and each remote device gets its own key pair and tunnel address.

This guide uses Debian’s packaged WireGuard tools, wg-quick, IPv4 forwarding, and nftables. It assumes the Debian server has root or sudo access and that UDP port 51820 can reach it. If the server is behind a home or office router, you must forward that UDP port to the Debian host. If the ISP uses carrier-grade NAT (CGNAT), ordinary router port forwarding may not be enough; confirm that you actually have a reachable public address before troubleshooting WireGuard itself.

What will this configuration do?

The example VPN uses 10.8.0.0/24. The server is 10.8.0.1, and the first client is 10.8.0.2. The client can be configured as either a full-tunnel VPN, where IPv4 Internet traffic exits through the Debian server, or a split tunnel, where only selected private networks use WireGuard.

Debian’s own WireGuard documentation confirms that WireGuard is available through the distribution packages, while the official WireGuard quick-start documents key generation, wg-quick, and the optional persistent keepalive behavior. See the Debian WireGuard documentation, the official WireGuard Quick Start, and Debian’s wg-quick manual page.

Step 1: Install WireGuard and nftables

Update package metadata, then install WireGuard and nftables:

sudo apt update
sudo apt install wireguard nftables

A common misconception is that Debian 12 needs an out-of-tree WireGuard kernel module. It does not. WireGuard has been in the Linux kernel for years; Debian’s packages provide the userspace management tools you need. Action: use Debian packages instead of downloading an unverified installation script.

Step 2: Generate the server key pair

Create the key files with restrictive permissions:

sudo -i
install -d -m 700 /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key
cat /etc/wireguard/server_public.key

The private key must remain private. The public key is what you copy into client configurations. Ideally, generate each client’s private key on that client rather than on the server. That way the server never needs to possess client private keys.

Step 3: Enable IPv4 forwarding

VPNトンネルは正常に確立されるものの、ルーティングされたトラフィックは失敗する場合があります。その理由は、LinuxのIPフォワーディングがWireGuard自体とは別のカーネル設定であるためです。永続的なsysctlファイルを作成してください。

echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

最終コマンドは を報告するはずですnet.ipv4.ip_forward = 1。Debian のカーネルドキュメントでは、 はip_forwardIPv4 パケットの転送を有効にするスイッチとして説明されています。対処法: トンネルインターフェイスが自動的にルーティングを有効にすると想定するのではなく、この値を明示的に確認してください。Debianの ip(7) マニュアルとsysctl.conf ドキュメントを参照してください。

ステップ4：サーバー構成を作成する

サーバーの秘密鍵を読み取り、次に以下を作成します/etc/wireguard/wg0.conf。

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

次に、ファイルを保護します。

sudo chmod 600 /etc/wireguard/wg0.conf

AllowedIPsは、ファイアウォールのような許可リストだと誤解されがちですが、ルーティングも制御します。サーバー側では、10.8.0.2/32このピアに を割り当てることで、WireGuard に対して、そのトンネル アドレス宛のパケットはこのクライアントに属すると認識させます。各クライアントに固有のアドレスと個別の[Peer]ブロックを割り当ててください。

SaveConfig = trueもう1つの便利な選択肢は、このファイルを手動で管理する予定がある場合は省略することです。を使用するとSaveConfig、wg-quickシャットダウン時にライブ状態を構成に書き戻すことができ、手動で編集した内容が上書きされる可能性があります。対処法：ライブ状態を明示的に保存したい場合を除き、ファイルは宣言型のままにしてください。

ステップ5：nftablesマスカレードの設定

フルトンネルクライアントがDebianサーバー経由でインターネットにアクセスする場合、最も簡単な構成はIPv4マスカレードです。まず、サーバーの送信インターフェースを特定します。

ip route get 1.1.1.1

devの後に、eth0、ens3、 などのインターフェースを探してくださいenp1s0。常に であるとは限りませんeth0。

既にNATテーブルを管理している場合は/etc/nftables.conf、ファイルを置き換えるのではなく、以下のNATテーブルを既存のルールセットにマージしてください。

table ip wireguard-nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname "eth0" ip saddr 10.8.0.0/24 masquerade
    }
}

eth0実際の送信インターフェースに置き換えてください。ロード前に検証してください。

sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables
sudo nft list ruleset

WireGuardではNATは必須ではありません。宛先LANに既にへの戻りルートがある場合10.8.0.0/24、マスカレードなしでルーティングされたアクセスが機能します。NATは、リモートクライアントにサーバーの既存のインターネットルートを使用させたい場合や、他の場所の戻りルートを制御しない場合に特に便利です。対処法：単純なインターネット出力の場合はマスカレードを使用し、ネットワークを制御し、送信元アドレスを保持したい場合は明示的なルーティングを推奨します。

ファイアウォールルールも必要ですか？

それは、既にインストールされているファイアウォールによって異なります。nftables の入力ポリシーが制限的な場合は、受信 UDP を許可してください51820。フォワードチェーンにデフォルトのドロップポリシーがある場合は、そこから目的の宛先へのトラフィックwg0と確立された戻りトラフィックを許可するルールを追加してください。クラウド VPS プロバイダーは、UDP を許可する必要がある別のセキュリティグループまたはプロバイダーファイアウォールを持っている場合もあります51820。

リモートのSSHサーバーに、まったく新しいデフォルト設定のファイアウォールルールセットを安易に貼り付けないでください。接続が遮断される可能性があります。対策：sudo nft list rulesetWireGuardを既存のファイアウォールに統合し、その設定を確認してください。

ステップ6：クライアントプロファイルを作成する

クライアント側では、WireGuardアプリまたはを使用して独自のキーペアを生成しますwg genkey。フルトンネルIPv4プロファイルは次のようになります。

[Interface]
Address = 10.8.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

vpn.example.comサーバーのパブリック DNS 名またはパブリック IP に置き換えてください。このDNS行はオプションであり、クライアントの実装サポートは異なります。スプリット トンネルの場合は、AllowedIPsVPN を通過するネットワークのみに変更してください。たとえば、10.8.0.0/24プライベート LAN などです192.168.50.0/24。

PersistentKeepalive = 25もオプションです。WireGuardの公式ドキュメントでは、NATまたはステートフルファイアウォールの背後にあるピアがアイドル期間中にマッピングを保持する必要がある場合、25秒が適切な値として推奨されています。これはパフォーマンス設定ではなく、すべてのクライアントで必須ではありません。推奨されるアクション：アイドル時間後に到達不能になるローミングクライアントまたはNATクライアントに主に使用してください。

ステップ7：起動時にWireGuardを開始する

まずnftablesを起動し、次にWireGuardインターフェースを有効にしてください。

sudo systemctl enable --now nftables
sudo systemctl enable --now wg-quick@wg0
systemctl is-active nftables
systemctl is-active wg-quick@wg0

wg-quick@wg0を読み取ります/etc/wireguard/wg0.conf。wg-quickマニュアルでは、この命名規則が、の下に保存されている構成の通常のショートカットであることを確認しています/etc/wireguard。アクション: より複雑なネットワークマネージャ設計がない限り、カスタムブートスクリプトではなくサービスを使用してください。

ステップ8：ハンドシェイクとトラフィックを確認する

クライアントを接続し、サーバーを検査します。

sudo wg show
ip address show wg0
ping -c 3 10.8.0.2

正常なピアであれば、通常、トラフィックがトンネルを通過した後、最近のハンドシェイクとゼロ以外の転送カウンタが表示されます。フルトンネルを設定した場合は、信頼できるIPチェックサービスを使用してクライアントのパブリックIPv4アドレスを確認してください。これはDebianサーバーの送信アドレスと一致するはずです。

よくある問題とその本当の意味

全面トンネルか分割トンネルか：どちらを選ぶべきか？

信頼できない Wi-Fi 上のトラフィックを保護する場合、またはインターネット トラフィックを Debian サーバーから外部に出す場合は、フル トンネルを使用します。サーバー、ホーム ネットワーク、ラボ、または内部アプリケーションへのリモート アクセスのみが必要で、通常のインターネット トラフィックをローカルにとどめたい場合は、スプリット トンネルを使用します。選択は主にクライアントによって制御されますAllowedIPs。

小規模なポイントツーサイト構成の場合、上記の構成で保守可能なベースラインを確立できます。クライアントごとに1つのピアブロック、固有のトンネルアドレス、Debian管理サービス、そして実際に必要なルーティング動作のためのnftablesが必要です。大規模な構成では、WireGuardプロトコル自体はシンプルですが、鍵配布、ピアライフサイクル、DNS、ログ記録、構成管理などが運用上の懸念事項となります。

最終確認チェックリスト

• wg-quick@wg0アクティブであり、wg0持っています10.8.0.1/24。
• サーバーはUDPで待機しており51820、そのポートは上流のファイアウォールまたはルーターを経由してアクセス可能です。
• 各クライアントは、それぞれ独自の鍵ペアと/32サーバー上の固有のエントリを持っています。
• net.ipv4.ip_forward1ルーティングされたアクセスが必要な場合に等しくなります。
• nftablesのマスカレード機能は、意図的にルーティングされたリターンパスを使用しない限り、フルトンネルのインターネットアクセスに存在します。
• wg showクライアントがトラフィックを送信した後、最近のハンドシェイクを表示します。
• クライアントの要望はAllowedIPs、意図された全トンネルまたは分割トンネルの設計と一致しています。

これらの手順は、Debian 12 および Debian で利用可能な標準の WireGuard ツールを対象としています。ネットワーク トポロジ、アップストリーム NAT、クラウド ファイアウォール、プライベート LAN ルーティング、および IPv6 ポリシーは環境固有のものであるため、WireGuard の設定だけではこれらの要素を推測することはできません。接続の問題をすべて WireGuard の障害として扱うのではなく、それぞれを個別に検証してください。