クライアントは認証を通過し、ログは接続済みと表示し、パケットはトンネルを通過しません。サーバーは write to TUN/TAP: Invalid argument (code=22) で試行を終えますが、これはドライバーの障害のように見えて、通常はそうではありません。ルーターや小さな Linux サーバーでは、その行は多くの場合、データパケットのフレーミング方法について両端が合意していないことを意味するため、カーネルは渡された復号済みバッファーを拒否します。その時点でルーティングはまだテストされていません。

正しいルーティングテーブルと壊れたフレーミング合意は、クライアントから見ると同じです。接続済みなのに何も機能しません。

トンネルは上がるが、何も通過しない

トンネルデバイスの書き込みエラーは、復号後かつルーティング前に発生します。デーモンはパケットを復号してインターフェースに渡しますが、バッファーがそのデバイスの期待と一致しないため、インターフェースが拒否します。コード 22 は無効な引数に対する一般的な応答なので、有用な情報はレイヤーです。これはハンドシェイクではなくデータ経路です。昨日は通信できていて、構成を変更していないのに今日止まった場合は、ネットワークを疑う前に、既定値を動かしたパッケージやファームウェアの更新を疑ってください。

最初のエラーではなく、データチャネルの設定周辺のログを読んでください。ネゴシエートされた圧縮モード、dev の種類、プッシュされたオプションはすべてより高い詳細度で表示され、三つの不一致のどれなのかを教えてくれます。

圧縮はフレーミングであり、帯域幅ではない

圧縮が有効な場合、各データパケットはどのように符号化されたかを示すヘッダーを運び、両端がそのヘッダーに合意する必要があります。古いサンプル構成から comp-lzo をまだ持つサーバーが、圧縮行のないクライアントと組み合わされると、まさにこのエラーが発生します。サーバーはクライアントが決して書かなかったヘッダーを期待します。comp-lzo と compress lz4-v2 を混在させても同じように失敗します。どちらも圧縮と呼ばれますがアルゴリズムが異なるためです。このオプションは現代のリンクでは帯域幅の機能ではなく、フレーミングの契約です。

バージョンの挙動には罠があります。2.5 系は圧縮オプションに非推奨の警告を出し始め、2.6 は圧縮パケットを拒否することと、データを圧縮しないままにすることの間に線を引きます。そのため、ルーターのファームウェア更新が、誰もトンネルを編集しないまま実効的な合意を変えることがあります。

両端を揃えるか、両方から削除する

すべての圧縮ディレクティブを列挙してください。サーバーファイル、プッシュされたオプション、クライアント固有のファイル、クライアントプロファイルです。サーバーの comp-lzo にはクライアント側でも同じ語が必要で、adaptive は古いビルドで裸のオプションが通常意味する従来の既定値です。ルーターの GUI スイッチで LZO や圧縮と表示されているものも同じオプションを書き込むので、アルゴリズムを混ぜるのではなく一致させて設定してください。似た名前が互換だと仮定しないでください。

圧縮が不要な場合は、両端から意図的に削除してください。サーバーの allow-compression no は圧縮パケットを拒否しますが、クライアントが提供をやめた後に限ります。クライアントがまだ圧縮をプッシュしている間に適用すると、逆方向の不一致を再び生み出します。

プッシュとデバイスの種類を確認する

サーバーはメインファイルまたはクライアント固有ファイルから圧縮ディレクティブをプッシュでき、クライアントは pull-filter でプッシュされたオプションを破棄できます。詳細度 4 で 一つのクライアントを接続し、サーバーが告知した内容とクライアントが受け入れた内容を読み比べ、どのフィルターもそれを削除していないことを確認してください。両側が一致してもエラーが残る場合は、デバイスの種類を確認してください: 一方の端の dev tap と他方の dev tun はフレームを交換できず、カーネルも同様に書き込みを拒否します。

ブリッジされた TAP 配備には、単に別のデバイス名ではなく、サーバー上の実際のブリッジが必要です。インターフェースをブリッジに追加せずに tap0 に名前を変更すると、書き込みを受け入れても何処にも行かないデバイスができます。

次に、一つのクライアントと 一つの宛先で検証します。サーバーのトンネルアドレスに ping し、次にその LAN 上のホストに ping します。前者はデータチャネルを、後者は転送を証明します。

関連記事