Netgear OpenVPN: TUN と TAP が別のポートで待ち受ける

スマートフォンは何の問題もなくルーターの VPN に接続するのに、同じダウンロードページのプロファイルを使うノートパソコンはタイムアウトします。この二つの試行の間で証明書は何も変わっていないのは、ノートパソコンが証明書が問題になる段階にすら達していなかったからです。ルーターは TUN と TAP に別々のリスナーを公開しており、動作するプロファイルは自分のデバイスの種類に対応する方を選ばなければなりません。

三つの候補障害、つまりポートか、デバイスの種類か、データチャネルの暗号ネゴシエーションかのどれを追うかを見極めることが、ここでの仕事のすべてです。

一致していなければならない三つのこと

デバイスの種類、プロファイルのインターフェース行、リスナーのポートは三つではなく一つの選択です。dev tun を宣言しながら TAP リスナーを狙うプロファイルはセッションを完了できず、逆も同じように失敗します。お使いの機種とファームウェアについて、ポートは、番号がビルド間で変わるため、ガイドではなくルーター自身の VPN ページから読んでください。その番号の隣に機種とファームウェアのバージョンを書いておけば、次の人が検証できます。

現場からの報告には、あるファームウェアでは TUN が 12973、TAP が 12974 という組があり、別のファームウェアでは違う番号だという例があります。これはビルドが違う証拠として読み、コピーする定数とは考えないでください。次にプロファイルには距離に適したホスト名、つまり変わり続ける WAN アドレスではなくルーターの動的 DNS 名が必要です。

ポートとインターフェース行を直すと、プロファイルは remote 行が一つ、dev 行が一つだけの普通のクライアント設定に見えます。この二つが食い違っていれば、何度試してもセッションはできません。

ログは出力された順に読む

OpenVPN クライアントは出来事を起きた順に報告するので、沈黙する直前の行が調べるべき層を示します。TLS Error: TLS key negotiation failed で終わる場合や、最初の応答を待ったまま諦める場合は、証明書の比較は一度も行われていません。それは到達性か、リスナーか、背後に何もないポートを指します。どれも CA ファイルを差し替えても直りません。

VERIFY OK まで進んでから失敗する実行は、まったく別の場所にあり、原因も別です。この二つの結果をファイルに触る前に切り分ければ、一度も参照されていない証明書バンドルを回り道する定番の遠回りを避けられます。ハンドシェイクは完了したのにトンネルが上がらない場合は、到達性ではなく暗号ネゴシエーションを見てください。

現代のクライアントが期待する暗号リストを追加する

最近の OpenVPN クライアントは、家庭用ファームウェアが今も提示する古い既定値を拒否し、症状はハンドシェイク成功直後のネゴシエーション失敗です。修正は、クライアントが何を受け入れるかを示すプロファイルの一行で、data-ciphers を AES-256-GCM、AES-128-GCM、CHACHA20-POLY1305、AES-128-CBC の順に設定します。ルーターが実装していないアルゴリズムは単に選ばれないので、リストを長くしても交渉が少し長くなる以外のコストはありません。

暗号を列挙しても、ルーターが持っていない暗号を教えられるわけではありません。それでもネゴシエーションが失敗する場合は、ルーターのページに独自の暗号設定があるか、その設定にクライアントが受け入れる項目が少なくとも一つあるかを確認してください。共通の要素がない二つのリストは間違ったポートとまったく同じ失敗を生むので、両端を見る価値があります。

コピーを手で編集するのではなく、一度だけインポートする

修正したファイルを NetworkManager にインポートすれば、少しずつ違うプロファイルでフォルダが埋まるのを避けられます（nmcli connection import type openvpn file client.ovpn を実行し、その後は名前で起動します）。インポートしたプロファイルを、編集する唯一のコピーとして保ち、繰り返しのダウンロードでたまる重複を削除してください。

次に LAN の外からテストします。同じネットワークから接続しても、通信がトンネルをまったく通らない可能性があるため、ほとんど証明になりません。要求が本当にルーターから外へ出ていることを確認し、クライアントが接続済みと表示しているだけでは不十分です。

警告にどう対応するかを決める

家庭用ファームウェアは通常、独自の認証局を作り、クライアントはファームウェアが抑えられない形で検証について不平を言います。すべての警告を致命的と扱うのではなく、その不平が守ろうとしているものにとって重要かを判断し、一つのメッセージを黙らせるために検証を全体で切らないでください。評価した警告は文書化されたリスクであり、無効にした検証設定は文書化されていないリスクです。

ファームウェアが、本当に重要な警告を直すためのサポートされた方法を提供しないなら、その欠落は VPN を別の場所でホストする理由になります。プロファイルを直すか、警告を受け入れるか、エンドポイントを移すかの選択は、その証明書をどれだけ信頼するかという判断です。ダイアログをクリックしてアイコンが緑になるまで待つのではなく、意図的に決め、どの選択をしたかを書き留めてください。