サーバー管理者向けのWireGuard VPNを安全に設定する

一般に公開された管理用ポートの代わりに、メンテナンス用ネットワーク

外部からアクセス可能な管理用ポートは、サーバーの攻撃対象領域を拡大します。SSHログインの試行、管理インターフェースの設定ミス、誤って公開されてしまった監視サービスなどが、外部ネットワークから直接アクセス可能になってしまうからです。 WireGuard 経由のアクセスでは、暗号化されたトンネル用に定義された 1 つの UDP ポートのみにアクセス可能にしておけばよいだけであるため、この可視性が低減されます。ただし、WireGuard はトラフィックを HTTPS として偽装せず、TCP 転送モードも提供していません。

VPN管理における理想的な構成は、多くの場合、ハブ・アンド・スポーク型ネットワークです。サーバーがインターフェースを運用します。 wg0 これにより、例えば内部アドレス 10.77.0.1 が割り当てられます。権限を持つユーザーのノートパソコンは、独立したピアとして接続し、例えば 10.77.0.10 を使用します。SSH、内部Webコンソール、または監視エンドポイントは、公開サーバーアドレスではなく、トンネルネットワーク経由でのアクセスを受け付けます。

これは、デバイスのウェブトラフィック全体を迂回させることを目的としたエンドユーザー向けVPNではありません。メンテナンスの目的では、より限定的なアクセスモデルの方が適切です。トンネルは、明確に指定された管理対象への経路としてのみ機能します。 フルトンネルを意図的に使用することも可能ですが、その場合はルーティングやDNSの利用、外部サービスへの到達可能性にも影響を及ぼします。こうした副作用は、純粋なメンテナンスアクセスにおいては通常、必要とされません。

仝 メンテナンスネットワーク これはあくまでネットワークの境界に過ぎません。どのLinuxアカウントがログインできるか、そのアカウントがどのコマンドを実行できるか、あるいはOSが最新かどうかについては決定しません。 これに加え、SSH鍵と個人アカウント、適切に制限されたsudo権限、ファイアウォールルール、セキュリティアップデート、ログ記録、そして適切に管理された緊急アクセス手段が必要です。そうすることで、単一の保護層における不具合が、アクセスに関する唯一の決定要因となることを防ぐことができます。

キー、ピア、および許可IPを正しく分類する

各WireGuardピアは、独自の鍵ペアを保有しています。秘密鍵は、対応するサーバー、ノートパソコン、または管理デバイスにのみ保存され、相手側にはそこから導出された公開鍵のみが保存されます。 オプションのプリシェアードキー（PresharedKey）は、公開鍵暗号に追加の対称鍵要素を補完するものです。これは追加のセキュリティ層ですが、秘密鍵や適切な鍵管理に取って代わるものではありません。

1つ置こう 1台あたり1ピア であり、チーム全体の共通のピアではありません。これにより、紛失したワークステーションや、もはや不要になったサービスプロバイダーの機器を、対象を絞って削除することができます。 WireGuardの鍵は、メンテナンスネットワークへのアクセスを許可します。これとは別に、SSH鍵はSSHサービスに対して個人またはデバイスを認証するものです。したがって、鍵の無効化は両方のレベルで計画する必要があります。

特に重要なのは、 許可されたIPアドレス サーバー上で。これらはWireGuardにおいてクリプトキー・ルーティング・テーブルを構成します。送信パケットについては、宛先アドレスに基づいて適切なピアを決定します。 また、受信側で既に認証済みのパケットについては、そのピアが使用できる内部送信元アドレスを制限する役割も果たします。したがって、この設定は単なる通常のルーティング指定以上の意味を持ちます。

管理用ノートPCにアドレス 10.77.0.10 が割り当てられた場合、サーバー上には、まさにこのピアに対応する AllowedIPs = 10.77.0.10/32. /32の割り当ては、このピアに単一のトンネルアドレスを紐付けます。もしすべての管理ピアに一律で 10.77.0.0/24 を割り当てると、この紐付けが曖昧になり、設定が不必要に広範囲なものになってしまいます。 また、選択したVPNネットワークが、拠点ネットワーク、コンテナネットワーク、ホームネットワークのいずれとも競合しないことを確認してください。

ネットワーク境界とアクセスモデルの計画

インストール前に、VPNのアドレス空間を計画してください。既存のLAN、クラウドネットワーク、DockerやKubernetesのネットワーク、および一般的に使用されるホームネットワークと重複しないプライベート範囲を選択してください。 トンネル経由でアクセス可能にするシステム（ゲートウェイサーバーのみ、限定された管理ネットワーク、または個別のサービスなど）を明確に定義してください。これに基づいて、後でクライアントのルーティング、ファイアウォールルール、および必要に応じて逆ルーティングが決定されます。

各デバイスについて、担当ユーザー、WireGuardの公開鍵、固定トンネルIP、利用目的、およびアクセス権の取り消し方法を記録してください。グループ分けは、「VPNなら何でもOK」という一律的な基準ではなく、運用、データベース運用、外部サポートといった業務内容に基づいて行うべきです。 また、プロバイダーのコンソールなど、独立した緊急用アクセス手段を確保しておいてください。ファイアウォール、SSH、ルーティングの設定を変更する前には、誤ったルールによってアクセスが遮断されないよう、必ずこの緊急用アクセス手段で確認を行ってください。

仝 ファイアウォール これはプライマリネットワーク境界です。パブリックインターフェースでのWireGuard UDPポートへのアクセスを許可しますが、SSH接続は入力インターフェース経由でのみ受け付けます。 wg0 あるいは、実際に使用されているWireGuardインターフェースを指定します。VPNの送信元ネットワークに対する追加の検証を行うことで、ルールをさらに絞り込むことは可能ですが、インターフェースの紐付けに代わるものではありません。したがって、ファイアウォールは、単にVPNの送信元アドレスであると主張されているという理由だけで、パブリックインターフェースに到達したパケットを受け入れることはありません。 WireGuardは、認証済みの内部アドレスをピアに紐付けます。この保証は、トンネルインターフェースを介して受け入れられたパケットに適用されます。

SSHレベルでは、パスワード認証の代わりに鍵認証が採用され、個人アカウントが設定され、sudoのルールは可能な限り制限されます。OpenSSHは AllowUsers アカウントを、送信元アドレスやCIDRネットワークにも紐付ける。この2つ目の制限は、 wg0 ファイアウォールルールを紐付けますが、置き換えるわけではありません。

公開Webアプリケーションについては、引き続きHTTPSによる独自の通信セキュリティ対策と、適切な証明書が必要となります。 ウェブサイトのTLSセキュリティ対策ガイド このレイヤーはブラウザからのアクセスに対応しています。一方、WireGuardはプライベートな管理ネットワークへのアクセスを保護するものであり、パブリックサービス向けのTLSや、それらのログイン、権限検証、保守に代わるものではありません。

ルーティングの落とし穴のない「wg-quick」を用いた基本構成

単一のメンテナンスサーバーの場合、密接なポイント・ツー・ポイントの構成で十分です。このサーバーは wg0 トンネルアドレスを使用して 10.77.0.1/24, 管理用ノートパソコンには常時 10.77.0.10/32. パブリックサーバーは、WireGuard に対して UDP のみを受け付けます。以下のファイルは、 wg-quick; これらは意図的に実際の鍵を含んでいません。

サーバー上では、あるピアがノートパソコンの公開鍵を、そのノートパソコンのトンネルアドレスと正確に紐付けます。サーバーの秘密鍵は、ローカルファイル内にのみ保存されます。設定ファイルは、例えば以下の場所に配置してください。 /etc/wireguard/wg0.conf …とし、読み取りアクセスは管理コンテキストに限定する。その中には秘密鍵が含まれているためである。一方、公開鍵はそれぞれの相手先向けに用意されている。

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

ノートパソコン上では、 Endpoint 公開サーバーアドレスと指定されたUDPポート。純粋なサーバーメンテナンスの場合は、クライアント側として 許可されたIPアドレス たいていはただ 10.77.0.1/32 が必要です。これにより、サーバーのVPNアドレスへのトラフィックのみがトンネルにルーティングされ、ノートパソコンからのインターネットへのアクセスは通常の経路のままとなります。

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

記載内容 0.0.0.0/0 一方、クライアント側では、トンネルを経由するIPv4のデフォルトルートは、次のようなものです： フルトンネル. wg-quick AllowedIPs からルートを導出し、デフォルトルートに対して追加のポリシールーティングロジックを適用します。これは、意図的にそのように計画されたアクセス環境であれば可能ですが、外部のデータトラフィックに影響を与えるほか、DNS や到達可能性に関する問題を顕在化させる可能性があります。

この例はIPv4のみを対象としています。サーバーがIPv6のパブリック接続を持っている場合、TCPポート22をIPv6ファイアウォールで明示的にブロックするか、SSHサービスを適切にバインドする必要があります。 IPv4のポート開放を閉じていても、IPv6のリスナーが引き続き外部からアクセス可能な状態であれば、防御にはなりません。IPv6のトンネルアドレスとクライアント側のプレフィックスは、個別に計画してください。 ::/0 その場合は、IPv6用のデフォルトルートも設定され、IPv4の設定に中立的な追加が行われるだけではありません。

まずトンネルを有効にし、VPNアドレスへの接続を確認してから、別のセッションでSSH経由でそのアドレスにログインしてください。この方法が確実に機能し、独立したコンソールまたは緊急アクセス手段が確保されてから初めて、公開SSHアクセスを無効にしてください。 その際、IPv4だけでなく、必要に応じてIPv6も確認してください。秘密鍵は、チケットやチャットログ、バージョン管理システムには一切含めないでください。

ルーティングモデルとファイアウォールルールの比較

ファイアウォールは、指定されたアクセスモデルを適用します。パブリックインターフェースでは、指定されたWireGuard UDPポートの受信を許可しますが、TCPポート22については、一般的な管理用アクセスとして開放しないものとします。その代わり、SSHは、受信インターフェースが wg0 あるいは、使用されているWireGuardインターフェースです。追加の送信元ネットワークチェックを行うことで、許可されるVPN範囲をさらに絞り込むことは可能ですが、送信元アドレスのみに基づいてルールを設定するだけでは不十分です。

入力インターフェースへのバインディングにより、パブリックインターフェースに到達したパケットが、VPN領域からの偽の送信元アドレスという理由だけでSSHの許可条件を満たすことを防ぎます。 WireGuardによるピアと内部アドレスの暗号的なマッピングは、トンネルインターフェース上の認証済みパケットに対して有効です。具体的なファイアウォールの構文は、使用しているソフトウェアに適合し、インターフェースとアドレスファミリーの両方を明確に指定する必要があります。

パブリックIPv6接続については、特に注意を払ってください。TCP 22のIPv4開放のみを解除した場合でも、IPv6経由のSSHはインターネットから引き続きアクセス可能となる可能性があります。 したがって、IPv6ルールでもこのポートをブロックするか、SSHサービスがパブリックIPv6アドレスでリスニングしないように設定してください。IPv4ルールとIPv6ルールは個別に確認する必要があります。

ステートフルファイアウォールの場合、単に希望する「行き」の経路だけを考慮するだけでは不十分です。許可された接続の応答パケットもクライアントに到達する必要があります。ゲートウェイの背後からのアクセスについては、さらに宛先ネットワークからの「帰り」の経路も考慮する必要があります。 VPNサブネット全体をすべてのサービスに対して一律に開放してしまうと、メンテナンス用ネットワークが不必要に広範囲な内部アクセスネットワークとなってしまいます。

単一のサーバーのメンテナンスにおいては、最初のモデルが最も分かりやすい。クライアントから 10.77.0.1/32 これで十分であり、ファイアウォールはWireGuardインターフェース経由で到着するパケットに対してのみSSHを許可できます。UDPポートは外部から見えるままですが、対応するピアキーがなければ、そこから管理アクセスが行われることはありません。

2つ目のモデルでは、明確な分離が求められます。この場合、VPNサーバーは単なるエンドポイントではなく、ルーターとしての役割も果たします。 ファイアウォールでは、例えば、定義された管理サーバーへのSSHや内部コンソールへのHTTPSを許可すべきですが、それぞれをWireGuardの入力インターフェースに限定し、具体的な宛先ネットワークとポートに制限する必要があります。ユーザーがすでに接続しているという理由だけで、データベースのポートをVPN全体で開放すべきではありません。

フルトンネルの場合、VPNサーバーはインターネット上の宛先へのゲートウェイとしても機能します。そのため、VPNサーバーはIPv4パケットを wg0 そしてそのアップリンクへ転送します。また、応答にはVPNネットワークへの戻り経路が必要です。多くのサーバー構成では、アップストリームネットワークがVPNプレフィックスへのルートを知らない場合、このためにアップリンクで特定のソースNATルールが使用されます。 これらのルールは慎重に計画し、対象となるトンネルネットワークに限定するようにしてください。

フルトンネルは、WireGuardのセキュリティ要件ではなく、クライアント側でのルーティングに関する決定です。なぜなら、 wg-quick AllowedIPs からのデフォルトルートは特別に処理されるため、この設定は、名前解決が計画的に行われ、ゲートウェイの容量が十分であり、適切な送信ルールが設定されている場合にのみ使用すべきです。通常の VPNの管理 多くの場合、必要以上に広範囲に設定されています。IPv6については、同じ計画上の課題が別途適用されます： ::/0 すべてのIPv6トラフィックをトンネル経由で転送します。

社内ネットワークへのアクセスを適切に許可する

VPNゲートウェイの背後に存在するその他のプライベートシステムに管理者がアクセスする必要がある場合、そのタスクは単なるサーバーへのアクセスから、ルーティングされた管理ネットワークへのアクセスへと変化します。 まず、対象となるネットワークとサービスを計画します。例えば、管理セグメント内のサーバーへのSSHや、内部コンソールへのHTTPSなどです。追加される経路はそれぞれ信頼領域を拡大することになるため、具体的な業務上の必要性に基づいて正当化されるべきです。

最初の技術的な要件として、ゲートウェイがIPv4パケットを転送できる必要があります。カーネルの設定 net.ipv4.ip_forward この動作を有効にします。これは、何の影響もない単なる一行のコードとして扱うべきではありません。カーネルのドキュメントによると、 ip_forward その他のIPv4設定パラメータは、ホストまたはルーターのデフォルト値に戻ります。そのため、変更の前後で、既存のネットワークおよびセキュリティのガイドラインを確認してください。

第二に、ファイアウォールには明示的な 乗り継ぎに関する規則 双方向。ある規則は、単にすべての交通を wg0 LANへのアクセスを許可する。その代わりに、VPNの送信元ネットワーク、指定された宛先アドレス、および必要なプロトコル（例えば、管理サーバーへのTCP 22やコンソールへのTCP 443など）にアクセスを制限する。正当な理由がない限り、データベースはこの許可範囲外とする。

第三に、宛先ネットワークには、VPNネットワークへの戻り経路、例えば次のようなルートが必要です。 10.77.0.0/24 ゲートウェイの内部アドレスを経由して。この戻り経路がない場合、行き方向の通信は機能しても、応答が管理者に戻ってこないことがあります。宛先ネットワークでルーティングが不可能な場合、ゲートウェイでのソースNATが技術的な代替手段となり得ますが、これにより元のVPNクライアントアドレスが隠蔽され、宛先側でのログ記録やより詳細なルールの設定が困難になります。

VPNのアドレス空間は、管理者のローカルネットワークや、既存の拠点ネットワーク、クラウドネットワーク、コンテナネットワークと重複しないように選択してください。 重複があると、経路選択が曖昧になり、WireGuardやファイアウォールの問題のように見えるエラーが発生する可能性があります。また、追加のピアや宛先ネットワークを有効化する前に、固定トンネルアドレスとそれに対応するデバイスを記録しておいてください。

運用と変更を確実に管理する

各デバイスに固有のピア、鍵ペア、および固定のトンネルIPが割り当てられて初めて、メンテナンスネットワークを管理可能な範囲に保つことができます。したがって、資産台帳には、少なくともトンネルアドレス、デバイス名、担当者、用途、発行日、および点検日を記載する必要があります。 10.77.0.10/32 を特定の管理用ノートパソコンに割り当てることで、アクセスの追跡が可能になり、複数のデバイスが同じ VPN 識別子を使用することを防ぐことができます。

鍵の交換は、インシデントへの対応としてではなく、通常の運用プロセスとして計画してください。 機器の交換を行う際は、新しいアドレスまたは明確に文書化された後継アドレスを持つ新しいピアを作成し、接続を確認した上で、古いピアを削除してください。WireGuardのプライベート鍵は、各端末にのみ保存されるべきであり、チケットや中央管理のインベントリリストには含めてはなりません。

ノートパソコンを紛失した場合や、外部関係者が退職した場合は、サーバーの設定から該当するピアを削除してください。これにより、他の管理者の鍵を交換することなく、そのピアが管理ネットワークにアクセスするのを阻止できます。 ピア・アブステイン ただし、これはSSH鍵の無効化とは異なります。WireGuard鍵はネットワーク経路を制御するのに対し、SSH鍵は宛先アカウントへのログインを制御するものです。

ピアを削除すると、WireGuardはそのピアを介して既存のSSH接続のパケットをこれ以上やり取りできなくなるため、接続は停止するか、切断またはタイムアウト後に終了する。ただし、この削除によって、アプリケーションレベルで既に確立されているSSHログインが自動的に取り消されるわけではなく、以前に起動されたプロセスが終了するわけでもない。 したがって、インシデント発生時には、SSH認証、実行中のプロセス、アカウント、および必要に応じてsudo権限についても追加で確認してください。

特定の変更を行うには、 wg syncconf 既存のWireGuard設定と具体的な相違点を照合する。マニュアルによると、この方法の方がピアセッションへの影響が少ないとのことである。 setconf. とはいえ、これは承認プロセス、二重チェック、あるいはメンテナンスウィンドウの代わりにはなりません。変更を行う前には必ず、正常に動作している設定をバックアップし、その設定を復元する方法を記録しておいてください。

ハンドシェイクからSSHアクセスまでの診断

障害が発生した場合は、トランスポート、ルーティング、アプリケーションを徹底的に分離してください。SSHの設定を変更する前に、外部からアクセス可能なUDPポートとハンドシェイクの確認から始めてください。コマンドは wg show 設定済みのピアについて、AllowedIPs、最後のハンドシェイクの時刻、転送カウント数などを表示します。値が欠落している、あるいは変化がない場合は、実際のSSHアクセス以前に問題が発生していることを示唆しています。

ハンドシェイクが成立したら、クライアントとサーバーの両方で、実際に設定されたトンネルアドレスと宛先への経路を確認します。 純粋なゲートウェイ管理の場合、クライアントはWireGuardインターフェース経由で宛先10.77.0.1に到達できる必要があります。内部の宛先の場合は、ファイアウォールのカウンター、許可された逆方向トラフィック、および宛先ネットワークへの逆ルートが追加の要件となります。ハンドシェイクが成功しただけでは、これらの要件が満たされていることを証明するものではありません。

ネットワーク経路が正しいことが確認できて初めて、SSHサービスの検証に進みます。ログインおよびソース制限に関連する sshd_config、特に次のようなユーザー共有など AllowUsers, そして、お使いのディストリビューションのツールを使ってサービスの状態やログを確認してください。その後、ユーザーアカウントや authorized_keys およびsudoのルールは別個のものとして扱われます。設定ドキュメントだけでは、ログインに成功したこと、あるいはサービスにアクセス可能であることを証明するものではありません。

同一または重複するAllowedIPsは、単なるドキュメント上の誤りではありません。 送信時、WireGuardはこれらのプレフィックスに基づいて宛先アドレスをピアに割り当てます。受信時には、これらが認証済みピアの内部送信元アドレスを制限します。したがって、重複または矛盾するホストプレフィックスは、一意で確実に追跡可能な ピアの割り当て. このような構成を適用した際に、管理ツールが具体的にどのような結果を出力するかは、あらかじめ想定すべきではありません。その代わりに、インベントリや構成チェックの段階で、競合を未然に防ぐようにしてください。

修正は慎重に適用し、診断は利用可能な緊急アクセス経路がある場合にのみ実行してください。そうすることで、ピア設定、ルーティング、またはファイアウォールの変更に誤りがあった場合でも、修復のための経路が同時に遮断されることを防げます。 変更を適用するたびに、ハンドシェイク、転送カウンター、ルート、および具体的に許可された管理サービスへのアクセスを再度確認してください。

wg show
ip route

工具の選定と安全限界が決め手となる

管理方法の選択は、いわゆる「汎用的なWireGuardの手法」ではなく、既存のサーバー管理体制に基づいて行われます。 wg-quick 小規模な構成に適しています。この補助スクリプトは、インターフェース、アドレス、およびAllowedIPsから導出されたルートを設定します。一方、複雑なネットワークについては、ドキュメントではより専門的なツールや、 wg およびIPツール。

ホストがすでにsystemd-networkdを介してネットワークを宣言的に管理している場合、.netdevファイルおよび.networkファイルが適切な代替手段となります。 systemd-networkdはWireGuard固有の設定をサポートしており、Credentialsから秘密鍵を取得することも可能です。機密情報については、ドキュメントでは保護策として、暗号化されたCredentialsの使用、あるいは少なくとも厳格なファイル権限の設定が推奨されています。これは、自動展開されるサーバーに特に適しています。

からの直接呼び出し wg そして ip 自動化、ポリシールーティング、および特殊なファイアウォール処理において最大の制御性を提供しますが、明確に管理された運用モデルが求められます。同一のインターフェースを、wg-quick、systemd-networkd、および独自のスクリプトで同時に管理することは絶対に避けてください。 複数の管理主体が存在すると、ルート、アドレス、またはピア設定が互いに上書きし合う可能性があり、信頼性の高いロールバックが困難になります。

PersistentKeepalive は、NAT やステートフルファイアウォールの背後にあり、自らデータを送信することはほとんどないものの、着信接続には常に応答できる状態を維持する必要があるピアに対してのみ有効です。指定がない場合は無効になっています。ドキュメントでは、25 秒はあくまで一例として挙げられているだけで、一般的なデフォルト値として指定されているわけではありません。 モバイルクライアントは、WireGuardが正しく認証されたパケットに基づいてエンドポイントを更新できるため、ローミングの恩恵を受けることがよくあります。

ローミングとエンドポイントの固定制限は、トレードオフの関係にあります。既知の送信元ネットワークからのUDPのみを受け入れるファイアウォールは、攻撃対象領域を限定できますが、外出先での柔軟な利用を妨げてしまいます。 また、WireGuardは、悪意のある攻撃者が外部の送信元アドレスをリダイレクトすることで、暗号化されたコンテンツを読み取ったり改ざんしたりすることなく、サービス拒否（DoS）攻撃を助長する可能性があるとも指摘しています。

WireGuardトンネルは、ID管理、権限チェック、更新、バックアップ、ログ記録の代わりにはなりません。また、通信をHTTPSとして偽装することもなく、TCPモードも提供しません。したがって、公開Webアプリケーションには引き続き独立したTLSによるセキュリティ対策が必要です。その要件と実装については、こちらの記事で解説しています。 HTTPSを安全に設定する. この保護層を、管理用のVPNアクセスとは明確に区別してください。