OpenVPN の TUN と TAP：決め手となる三つの条件

二つのトンネルが同じファイル転送を運びながら、ワイヤ上に載せるものがまったく違うことがあります。一方は二つのアドレス間で IP パケットを運び、もう一方はイーサネットフレームを運び、セグメントへブリッジできます。この違いが、どのアプリケーションが動くか、どのクライアントが接続できるか、どれだけのネットワーク設計を引き受けるかを決めます。

実際には三つの条件で決まり、順番に確認してください。ふつう最初の条件で議論は終わります。

各インターフェースが実際に運ぶもの

TUN デバイスは第3層のポイントツーポイントインターフェースです。カーネルが IP パケットを渡し、トンネルがそれをピアのアドレスまで運びます。TAP デバイスはイーサネットフレームを運ぶ第2層のインターフェースで、ブリッジをそもそも可能にするのはこれです（カーネルのドキュメントにもそう書かれています）。どちらもペイロードの暗号化方法を変えるものではなく強度の設定でもなく、選択は両端が何を交換しなければならないかについてであり、トラフィックがどれだけ守られているかについてではありません。

ひとつの帰結がすぐに導かれます。両端は一致していなければならず、あるデバイス種別向けに設定されたクライアントは、ほかの条件がどれだけ一致していても、もう一方向けに設定されたサーバーには参加できません。

条件その一：第二層は本当に必要ですか？

ブリッジが複雑さに見合うのは、IP 以外のトラフィック、ルーターを越えられない検出、ひとつのセグメントに居続けることを求めるアプリケーションなど、プロトコルが本当に同じブロードキャストドメインを必要とする場合です。それ以外はすべてルーティングの問題で、ルーティングはずっと少ない仕組みで解決します。セグメントを広域に広げればブロードキャストも広がるため、ループ防止、アドレス計画、障害ドメインがすべて設計の一部になります。ひとつのルートで足りた要件に対して、これは受け入れるものが多すぎます。

テストは具体的で、ルーティングされたトンネルで失敗するアプリケーションを挙げ、その理由を説明してください。ブロードキャストが必要だという答えなら、第二層が正直な答えです。誰かが一つのサーバーに到達できなかったという答えなら、要件はルートかファイアウォール規則です。

条件その二：クライアントは対応できますか？

対応は一様ではありません。デスクトップのクライアントはふつう両方のデバイス種別を提供しますが、モバイルや組み込みのクライアントはルーティングモードだけを実装していることが多く、文句なくインポートできたプロファイルでも、インターフェースを作ろうとした時点で失敗することがあります。プラットフォーム名から機能を推測せず、具体的なクライアントとバージョンを確認してください。

未対応オプションのエラーは、インポートが通るまで見慣れない行を消してよいという誘いではありません。プロファイルとクライアントが何が可能かで一致していないという意味であり、修理はプロファイルを発行した運用者の側にあります。検証者を黙らせるためにオプションを外すと、提供するはずだった性質を静かに落としたまま、動いているように見える接続ができあがることがあります。

条件その三：これは本当にインターフェースの問題ですか？

インターフェースの問題は、隣り合う二つの選択のせいにされます。仮想デバイスはトンネルに何が入るかを決め、UDP か TCP かは外側のトランスポートの振る舞いを決めます。どちらも止まった転送を治すものではなく、大きな転送が止まり小さな転送は通るなら、パケットサイズと MTU にこそ注意を向けるべきです。

接続はできるのに内部のホスト一台に届かないクライアントは、ふつうルーティング、ファイアウォール規則、欠けた戻り経路を見ています。

マネージドサービスでは、サーバー側がすでにそれを前提に組まれているので、運用者のプロファイルが指定するインターフェース構成を使ってください。自前の展開では、アプリケーションの実際の要件から選び、その理由を選択のそばに書き残してください。

問題はどちらの選択肢が強いかではありません。トラフィックが実際にどちらを必要としているかです。