OpenVPN Connect が fragment を拒否する:プロファイルの取得元を直す
OpenVPN Connect は fragment に対応していないため、解析できるプロファイルでも失敗することがあります。そのクライアント向けに作られたプロファイルを入手するか、サーバー側を意図的に変えてください。
エラーはインポート時、まだ何のネゴシエーションも始まる前に出て、クライアントが受け付けないディレクティブを名指しします。OpenVPN Connect は OpenVPN 3 ライブラリのコードを動かしており、コミュニティクライアントの fragment オプションをまったく実装していません。そのためこれはパケットサイズの調整ではなく、二つの端点の互換性の問題になります。
その行を消せばクライアントが解析できるファイルにはなりますが、サーバーはその行が示していた形式を依然として期待しているかもしれません。何かを編集する前に、インポート画面から外へ向かって確認してください。
インポートが止まる場所
インポーターはサーバーに接続する前にディレクティブを解析するので、そこでの拒否は構文についてのローカルな判断であり、ネットワークの結果ではなく、OpenVPN の未対応ディレクティブ一覧にも同じ制約が記されています。これで、同じファイルが同じマシン上でコミュニティクライアントでは動き、Connect では失敗する理由が説明できます。メッセージからディレクティブ名を読み取り、その文言がクライアントの反対理由を示す唯一の証拠なので、元のファイルを保管してください。インポートのエラーと接続タイムアウトは別の段階から来るので、対応も分けるべきです。
メッセージが fragment を名指ししているなら、残る問いはサーバーもそれに依存しているかどうかです。渡されたプロファイルに触る前に、そこへ答えてください。
fragment がコミュニティクライアントで変えるもの
コミュニティクライアントでは、このディレクティブが OpenVPN 自身のデータグラム分割を有効にし、ペイロードが外側の IP 層に届く前に分割します。大きな UDP データグラムを捨てる経路を通り抜けるため、また経路 MTU の探索を信頼できない場所でトンネルを使える状態に保つために存在します。これはインターフェイスの MTU を下げることの同義語ではなく、OS が行う IP レベルの分割でもありません。この仕組みを持たないクライアントは、数値を下げても手に入りません。
この設定はサーバー側の構成にもあるため、手元のコピーから外しても変わるのは自分の側だけです。サーバーはそのオプションを理解する相手を依然として期待しているかもしれませんし、解析できるプロファイルはまだ確立するセッションではありません。この二点が、編集したファイルがつながってから止まるという紛らわしい中間状態を説明します。
このクライアント向けのプロファイルを依頼する
きれいな道は、OpenVPN Connect 向けに文書化された二つ目のプロファイルです(サービスが公開していれば)。多くの事業者が公開しており、違いは通常、向け先の端点ではなく省かれているディレクティブにあります。サポート窓口は削られたファイルを診断するよりプロファイルをクライアントに突き合わせるほうがはるかに速いので、エラーを説明するのではなくクライアント名で依頼してください。
サーバーを自分で運用しているなら、判断は自分のクライアントより広くなります。分割を切ると、劣悪な経路でつながり続けるためにそれが必要だった相手を含め、すべてのピアに影響します。影響を受けるクライアント向けに二つ目のリスナーや二つ目の構成を公開すれば、既存の利用者は動かしたまま、新しいクライアントには解析できるものを渡せます。どちらを選んでも、その対応はすぐに失われるので、どの構成がどのクライアントに使われるかを書き留めてください。
接続を検証する — インポートだけではない
インポートの成功は、パーサーがファイルを受け入れたことしか証明しません。自分が管理するマシンでコミュニティクライアントを使い、同じプロファイルでトンネルを張り、ログでトランスポートと暗号のネゴシエーションを確認してください。下のコマンドはデスクトップアプリを介さずにそれを行います。
openvpn --config client.ovpn --verb 3
ip -4 addr show tun0
curl -sS --interface tun0 -o /dev/null -w '%{http_code}\n' --max-time 8 https://example.com/
ログを見れば、オプションのエラーが TLS のやり取りより前に現れ、認証や暗号の失敗がその後に現れるので、試行がどこで止まったか分かります。トンネルが上がってなお要求が失敗するなら、問題は互換性からルーティングへ移っています。サーバーについて何かを結論づける前に、同じネットワークでの Connect の挙動と比べてください。
動いたプロファイルとクライアントのバージョンをメモのそばに残してください。将来のクライアント版がディレクティブへの対応を加えれば、誰もサーバーに触れないまま答えが変わります。