ルーターでも小型のコンピューターでも VPN を終端できますが、判断はスループットで決まることはほとんどありません。決め手になるのは、深夜二時に誰が更新を当てるのか、その機器が再起動したときに他に何が止まるのか、そして壊れたのがトンネルそのものだったときにコンソールへ到達できるのかという点です。候補ごとにこの三つの問いに答えると、たいてい選択は自然に決まります。以下の手順は、その比較を、契約前に確認できる事柄の短いリストに変えます。

トンネルが落ちたときに動き続けるべきものから考える

設計すべき障害は、VPN プロセスが死んでもホストには到達しなければならないという状況です。ルーターでは、トンネルとインターネットゲートウェイが運命を共にします:設定変更をひとつ誤るだけで両方が落ち、復旧の道は多くの場合、物理的なリセットです。別のコンピューターなら、ゲートウェイは動き続け、ホストは LAN 経由でまだ到達できます。どちらの結果を許容できるかが、どんな機能一覧よりも多くを決めます。

VPN ホストが再起動したら、家庭やオフィスは何を失うのかを一文で書いてください。答えにインターネットアクセス全体が含まれるなら、共有された障害ドメインを受け入れたことになり、後から気づくのではなく、意識してそう言うべきです。

同じ機器上の二つ目のサービスは予備のコンソールではありません。電源、ファームウェア、管理者アカウントを共有します。

各ホストが増やす保守の対象を数える

ルーターは独自のリリース周期を持つベンダーのファームウェアを伴い、VPN 機能は通常、はるかに大きなイメージの中の一モジュールです。コンピューターは OS、パッケージマネージャー、カーネル、そして今やあなたが所有する一連のサービスを伴います。どちらもパッチが必要で、本当の問いは、目新しさが消えた後にどの周期を維持するかです。

Linux ホストでは、その周期を期待するのではなく見える形にしてください。systemctl list-timers は予定されたジョブを、apt list --upgradable は待機中のものを示します。VPN ホストの再起動は計画していない限り停止なので、どの更新に再起動が必要かを記録してください。無人更新の経路がないルーターには、代わりにカレンダー登録が必要で、それは弱い統制ですが正直な統制です。

アカウントも数えてください。VPN ホスト上の管理者ログインが増えるたびに、ローテーションすべき資格情報と、取り消すべき経路が一つずつ増えます。

箱のラベルではなく、プライベートネットワークの経路をたどる

クライアントはサーバーがどこで動くかを気にせず、保護対象のプレフィックスに到達できるか、戻りの経路があるかを気にします。サーバーは経路が最も単純な場所、つまり通常はリソースを持つセグメントの直上に置いてください。ルーターの後ろのコンピューターには依然としてポート転送が必要で、その LAN のリソースには依然としてトンネルサブネットへの戻り経路が必要です。

クライアントを責める前に、ホスト側の転送を確認してください。sysctl net.ipv4.ip_forward は 1 を報告するはずで、nft list ruleset や iptables -S はトンネルのインターフェースに転送が許可されているかどうかを示します。masquerade ルールの欠落は、クライアント側から見ると壊れたトンネルとまったく同じに見えます。

トンネルが到達してはいけない範囲も決めてください。ルーター上に置いたサーバーは、そのルーターが経路を持つすべてのサブネットを見ることができ、それはアクセス方針の意図より大きいことがよくあります。別のホストなら、同じ分離はファイアウォール規則一つ分の距離にあり、侵害されたクライアントの影響範囲は小さくなります。RFC 7296 の IPsec ゲートウェイの説明 はこれをルーティングとポリシーの問題として扱い、ハードウェアの問題とはせず、方針を書き留めるまでどちらの形も既定で安全ということはありません。

トンネルに依存しない復旧用コンソールを確保する

VPN を修理するためのコンソールが VPN 自身であってはなりません。トンネルが落ちている間も使える LAN アドレス、シリアルコンソール、またはプロバイダーのコンソールを用意し、必要になる前に少なくとも一度は使ってください。一度も訓練していないアウトオブバンド経路は、能力ではなく計画です。

ホスト自身が削除できない場所に設定をバックアップしてください。tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn は鍵とサービス定義を取得し、コピーはマシンの外へ出す必要があります。ピア一覧なしで鍵を復元すると誰も参加できないサーバーができあがるので、ファイアウォール規則とクライアント一覧も含めてください。アーカイブは、復旧用コンソールが到達できる場所に保存してください。

ロールバック手順を同じメモに書いてください。文書化された逆手順のない設定変更は、意図が何であれ恒久的な変更です。

再起動と更新で選択を検証する

うまくいく日ではなく、失敗するときのやり方で構成を試してください。ホストを再起動し、保留中の更新を適用し、手作業なしでトンネルが戻ることを確認します。

再起動後に、最もよく壊れる三点を確認してください。systemctl is-active wg-quick@wg0 はインターフェースが戻ったか、ss -lunp はポートで何かが待ち受けているか、wg show はハンドシェイクが完了したピアを一覧します。ハンドシェイクなしで有効なサービスは、デーモンではなくファイアウォールか経路が誤っていることを意味します。

設定したネットワークとは別のネットワークのクライアントから、同じ確認を繰り返してください。再起動、更新、クライアントのネットワーク変更をトンネルが乗り越えれば、ホストの選択は当面決着します。そうでなければ、欠けているのは別の箱ではなく、多くの場合、文書化された手順です。

関連記事