ウェブホスティングか VPS か：そのプランで VPN サーバーを動かせるか
共用ホスティング、マネージドアプリ、自己管理サーバーでは、得られるネットワーク制御が異なります。購入や移行の前に、四つの能力を比較してください。
動いているウェブサイトは、提供事業者が HTTP を配信できる証拠であって、あなたがマシンを制御している証拠ではありません。共用プラン、マネージドアプリケーション、自己管理サーバーの間には、アカウントがネットワークに対して何をできるかという大きな隔たりがあります。もう一年分を支払う前に、その隔たりのどちら側が VPN の設計に必要かを決めてください。四つの能力が両者を分けており、そのどれも価格表には載っていません。
各プランが実際に与えるもの
有用な比較は価格やディスク容量ではなく、権限です。アカウントが何を起動できるか、どのカーネル機能に届くか、どのポートが受信トラフィックを受け入れるか、許可されたトラフィックが再び別の場所へ出られるかを尋ねてください。
ほとんどのホスティング製品は三つの形に分かれ、汎用サーバーは最後の一つだけです：
| Capability | Website plan | Self-managed server |
|---|---|---|
| Long-running custom process | Usually not permitted | Yours to run under a service manager |
| Virtual network interface | Almost never available | Present when the kernel module and privilege allow it |
| Arbitrary inbound port | Restricted to the web stack | Provider filtering still applies |
| Forwarding for clients | Not offered | Possible once routing and policy are configured |
シェルアカウントはよくある混乱の元です。ファイル転送やスケジュールタスクへのアクセスは管理のように見えても、プロセスは一つのディレクトリと少数の許可された操作に閉じ込められています。
答えを決める四つの能力
最初の段階で失敗すると残りが無意味になるため、順番に確認してください。
第一に、ソフトウェアが保守をまたいで存続する長時間プロセスとして動き、第二に、実装が自身の仮想インターフェースを作れる必要があります。Linux では通常、関連する管理者権限で /dev/net/tun を開くことを意味し、カーネルの TUN/TAP ドキュメントが説明するとおりですが、すべての VPN 設計がこのデバイスを使うわけではありません。第三に、クライアントが公開アドレス上のリスナーに到達でき、意図したトランスポートとポートで届く必要があり、HTTPS を受け付けるウェブリバースプロキシは、同じ番号の無関係なプロトコルについては何も語りません。第四に、許可されたトラフィックが先へ進める必要があり、経路、転送、そして実際にサポートされる変換を備えていなければなりません。
利用規約はその四つの隣にあり、まったく技術的ではありません。無制限の通信量という表現は通常、ウェブリクエストを指し、他人のダウンロードを運ぶトンネルを指すものではありません。それを前提に設計する前に、許容される利用の項目を読み、サービスが起動しない日のために復旧用のアクセスを確保しておいてください。
ウェブサイトのアカウントが行き止まる場所
ウェブサイトのプランは通常、固定のエントリーポイントを持つマネージドランタイムの中でコードを動かします。トンネルのバイナリが存在していても、プロセスにデバイスノードを開く権限、特権ポートを束縛する権限、ルーティングテーブルを変更する権限がないことがあります。これらの制限は製品の仕様であり、見落としではありません。
だから VPN をうたうプラグインは、たいてい別の場所へのプロキシであることが分かります。現在のアカウントがウェブサイトの操作しか提供しないなら、正直な手段は別のサーバーであり、欠けた権限を解放するモジュールを探すことではありません。
一つのホストで両方を動かさなければならないとき
共用は可能で、ときに合理的ですが、便利さではなくセキュリティの判断として扱ってください。アップロードフォームを持つウェブアプリケーションは、トンネルの認証情報と制御ソケットの隣にあり、一方の脆弱性が他方に届きます。アカウント、サービスユニット、ファイルシステムを分ければ、二台目を買わずにその露出を減らせます。
資源の競合も同じくらい重要です。トンネル経由のバックアップと多忙なウェブプロセスは同じ上り回線と同じディスクを奪い合い、障害は飽和したトンネルではなく遅いサイトのように見えます。事故の前にどちらの負荷を優先するかを決め、ウェブサイトが応答し続けるようトンネルに上限を設けてください。
両方のサービスが動いているからといって、どちらの配置も分離されているわけではありません。両方を同じホストに置けることは設計の出発点であり、分離の作業がそれを擁護可能にします。
試験用ホストで四つのコマンドを使って決着をつける
移行する前に、対象製品の最小インスタンスを一時間借りて、四つの能力を直接試してください。機能表から推測するのは、間違ったプランの一年より少ない金額で済みますが、はるかに多くの時間を費やします。
試験用ホストでこれらを実行し、失敗を障害ではなく答えとして読んでください：
ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | head最初の二行は、トンネルデバイスがそもそも存在できるかを示します。三行目はホストがパケットを転送できるかを報告し、四行目はすでに待ち受けているものを示すので、ポートの衝突を早く捕まえられます。二行目で失敗する事業者でもユーザー空間の実装を支えていることがあるので、サポートに尋ねるときは製品の分類ではなく、必要な仕組みを名指ししてください。