VPN をホストする前に VPS が許可すべきこと

インスタンスは起動し、パッケージのインストールも成功し、サービスは稼働状態まで報告するのに、何も接続できません。このパターンは仮想プライベートサーバーでよく見られます。快適にインターネットへ出られるゲストでも、プロトコルが求めるインターフェースを作れないことがあるからです。五つの確認が、トンネルを提供できるホストと、単に準備できたように見えるホストを分けます。最初に失敗する確認が、通常その後のすべてを説明します。どれも実行は安価で、メモではなく判断で終わります。

プロトコルが必要とするインターフェースを確認する

OpenVPN TUN 上で動かすには、キャラクターデバイスとその背後のカーネルモジュールが必要です。WireGuard には独自のカーネルサポートか、期待に合ったユーザー空間実装が必要です。管理されたコンテナはデバイスを決して公開しないホストカーネルを共有することがあり、一部のプラットフォームは何がインストールされていてもトンネルインターフェースの作成を全面的に禁じます。

サポートページを読むのではなく能力を試してください。マーケティング上のラベルは土台の制限より速く変わります。あるプラン向けに書かれた機能一覧は、ゲストが実際に動くカーネルを説明していないかもしれません。二つの短いコマンドが一般的なプロトコルについての問いに答え、どちらも後始末をします。以下のコマンドは何も永続的に作らず、すぐに削除されます。

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

最初の組で拒否されれば TUN が使えず OpenVPN の既定モードは起動できません。最後の行で拒否されれば WireGuard のカーネルインターフェースがありません。カーネルの TUN/TAP のドキュメント は、最初の確認が試すデバイスを説明しています。どちらの失敗も VPN パッケージの再インストールでは直りません。

受信経路には二人の所有者がいることを忘れない

プロバイダーのネットワーク規則とゲストのファイアウォールは別のシステムで、通信は両方を通過しなければなりません。ゲストで待ち受けるリスナーは、プロバイダーのセキュリティグループがポートを落とせば無意味です。逆に、プロバイダーの規則が開いていても、ゲストがパケットを拒否すれば何も起きません。リスナー、次にゲストの規則、次にプロバイダーのパネルの順で確認し、ポート番号だけでなくプロトコルも確かめてください。いきなりプロバイダーのパネルへ飛ぶのが、必要のない範囲を開けてしまう原因です。

UDP が典型的な犠牲者です。多くのプラットフォームは既定で TCP を許可し、UDP の規則を別項目として扱います。インスタンスが公開アドレスを持たずプロバイダーの NAT の背後にあるなら、プロバイダー側のポート転送が三つ目の調整すべき設定になります。

出口だけでなく戻り経路を計画する

フルトンネルサービスには、転送の有効化、クライアント通信の変換または経路方式、クライアント群に届く戻り経路が必要です。リスナーを開いても、これらは何も得られません。確立しても有用な通信を運ばないトンネルは、認証ではなく通常ここで失敗します。成功したハンドシェイクを診断の終わりではなく始まりとして扱ってください。

計画を三つの具体的な決定として書く：クライアントが受け取る送信元の範囲、その通信がどのようにインターネットへ出るか、応答がどう戻り経路を見つけるか。そのうえで、クライアントを試す前にカーネルが計画に同意していることを確かめてください。静かな不一致をクライアント側の不具合と取り違えないためです。

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6 の扱いを明示的に決める

IPv6 はゲートウェイにとって挙動の異なるいくつかの仕組みで届きます。インスタンス上のアドレス、経路化されたプレフィックス、あるいは何もなしです。経路化されたプレフィックスだけが、サーバーに通常どおりクライアントへアドレスを配らせます。ホストで動く IPv6 アドレスがあれば利用可能なクライアント用プレフィックスもある、という仮定は、後から半端に壊れた接続として現れる誤りです。IPv4 だけで行うあらゆる試験をすり抜ける種類の不具合です。

プロバイダーがプレフィックスを経路化しないなら、トンネルを IPv4 専用にするか、クライアントにそう伝えるかを決めてください。文書化された不在は、接続済みの利用者に対して IPv6 の宛先を黙って黒穴へ落とす部分的な設定より安全です。

外部クライアントから証明する

ローカルのサービス状態は、一つのホスト上の一つのプロセスを述べるだけです。有用な試験は、別のネットワークにいる承認済みクライアントが、配布しようとしているプロファイルで接続し、そのうえでアプリケーションに到達して名前を解決することです。一度は再接続もしてください。最初の試行だけで機能するトンネルは、実務で最も重要な要件を満たしません。

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

試験と並べて運用の基本を保ってください。更新の余地、上限付きのログ、トンネルに依存しない管理アクセス、復旧コンソール、そしてインスタンスが作り直されて公開アドレスが変わったときにクライアントのプロファイルがどうなるかの記録です。必要なインターフェースや転送の方式がそもそも用意されていないならクライアント側の変更では補えないため、正直な次の一歩は設定を増やすことではなく別の種類のインスタンスです。