VPS 上の OpenVPN：開くべき /dev/net/tun デバイスがない

初回起動は /dev/net/tun、または開けない TUN/TAP デバイスについてのメッセージで失敗します。証明書はまだ読まれていないので、プロファイル側に原因はありません。デーモンは、このゲストが持っていないオブジェクトをカーネルに要求しています。

そのオブジェクトは tun モジュールが支えるキャラクタデバイスです。作成できるかどうかは、カーネルを誰が所有しているかで決まります。

デーモンがカーネルに要求するもの

OpenVPN は /dev/net/tun を開き、ドライバにインターフェースを要求します。ドライバが tun モジュールで、デバイスノードはユーザー空間がそこへ到達するためのハンドルです。モジュールが読み込まれていなければ、ノードが存在しないか、開く操作が失敗します。どちらの状態も server.conf の編集では直りません。

まずこのエラーをプラットフォーム側の問いとして読んでください。設定エラーはデバイスが開いた後に現れ、その前に現れることはありません。

VM か、カーネル共有のゲストか

KVM、Xen などの完全な仮想マシンではカーネルを自分で制御できます。モジュールを読み込み、ノードを作成できます。OpenVZ、Virtuozzo、LXC 系のコンテナでは、ゲストはホストのカーネルを共有するため、内部の root でもホストが読み込んでいないモジュールは読み込めません。

したがって同じ障害でも、責任の所在はまったく異なります。前者ならインスタンスの内側から直せます。後者では、何かを公開するようホストまたはプロバイダに求めていることになります。

どちらのケースかを判断する前に、ls -l /dev/net/tun、lsmod | grep tun、ip -brief link show を実行してください。

VM では起動時にモジュールを読み込む

仮想マシンでは、modprobe tun で通常はデバイスノードが作成されます。作成されたことを確認したら、一度だけ打ったコマンドに頼らず、ディストリビューションのモジュール設定で読み込みを永続化してください。再起動で消えるノードは、来月も同じチケットになります。

起動したカーネルにそのモジュールが用意されているかも確認してください。そぎ落とされたベンダーカーネルには無いことがあります。

ノードはあるのに開く操作が失敗するなら、次に疑うのはパーミッションとデバイスのメジャー番号・マイナー番号です。これらはローカルな修正で、プロバイダへの依頼ではありません。

コンテナではデバイスはホストのもの

コンテナでは、デバイスとケイパビリティは別々の要件です。ランタイムが /dev/net/tun を渡す必要があり、コンテナ側にはインターフェースを作るためのネットワークケイパビリティが必要です。どちらも与えない rootless ランタイムでは、プロファイルをどう書いても同じ開くエラーが出続けます。多くの OpenVZ ホストは顧客パネルに TUN/TAP の切り替えを用意しており、それを有効にして再起動するだけで解決することがよくあります。

プロバイダには、ホストで tun モジュールが読み込まれているか、このインスタンス内でデバイスが利用できるかを具体的に尋ねてください。曖昧なチケットには曖昧な回答しか返りません。

モジュールを再ビルドしても解決しない理由

ゲスト内でモジュールをビルドしても、ほとんど役に立ちません。コンパイルには実行中カーネルの正確な設定が必要で、/proc/config.gz は任意であり、最小構成のイメージでは存在しないことがよくあります。たとえ動くモジュールができても、コンテナが所有していないカーネルに挿入することはできません。

デバイスが現れたら、サービスを再起動し、通信を試す前にインターフェースを確認してください。tun0 が見えることは、デーモンがデバイスを開いた証拠です。転送やファイアウォール規則、クライアントが受け取るルートについては、まだ何も語っていません。

これらは別々の証拠を要する別々の問いです。デバイスが無いのは前提条件の失敗であり、トンネルが存在しても何も運ばないのはポリシーの失敗です。