VPN設定でIPv6エンドポイントを書く方法

IPv6アドレスはコロンだらけで、ポートも運ぶエンドポイントフィールドには、アドレスがどこで終わるかを示す手段が要ります。ここを誤ると、クライアントはプロファイルの解析を拒否するか、黙って別の何かに接続します。正しい形式は普遍的ではなく、フィールドがアドレスとポートを持つのか、アドレスだけなのか、ホスト名なのかで変わります。クライアントの出力を読み始めた時点で構文の修正と到達性の修正はまったく別物に見えるので、手順書は順番どおりに進めてください。

アドレスを入力する前にフィールドの種類を確認する

たとえば WireGuard Endpoint フィールドでは、ポート付きのIPv6リテラルはアドレスを角括弧で囲み、[2001:db8::10]:51820 のように書きます。この例のドキュメント用プレフィックスは公開サーバーではなく、角括弧は構文の一部であってアドレスの一部ではありません。

他の形式には独自の規則があります。URIはIPv6リテラルを角括弧に入れて運べますが、VPN設定が必ずURIとは限りません。アドレスとポートの欄が別々のクライアントは一方にリテラルだけ、他方に番号を期待するかもしれませんし、そこに角括弧を足すのは統合フィールドで省くのと同じくらい誤りです。

ポートが同じフィールドを共有する場合はリテラルを角括弧で囲む

覚えておくべき規則は単純です。同じ文字列でポートが続くときに角括弧が現れ、ポートのないフィールドにアドレスが単独で置かれるときは現れません。

一つのプロトコルのエンドポイント文字列を丸ごとあらゆるクライアントにコピーすることが、この誤りの通常の原因です。 OpenVPN やIPsecプロファイルやアプリケーションの画面はそれぞれ独自の構文を文書化しており、あるものに正しい文字列が別のものでは拒否されたり誤解されたりします。編集しているフィールドについては、クライアント自身のドキュメントを読んでください。ドキュメント用プレフィックスや例のアドレスはコメントに残し、誰も実際のホストとして送らないようにし、マニュアルが二つの形式を示す場合は、目の前のフィールドの種類に合うほうを使ってください。

アドレス欄とポート欄を分ける

クライアントが欄を二つ用意している場合は、アドレスを一方に、ポートをもう一方に入れます。統合形式をアドレス欄に貼り付けると解析エラーになるか、さらに悪ければ意図しない何かに解決されるアドレスになります。

値が正しく見えるときは、末尾の空白と不可視文字を確認してください。コピーしたアドレスには、改行しない空白やゼロ幅文字が付いていて、クライアントが解析できず画面にも表示されないことがよくあります。エラーに意味がない場合は、貼り付けずに入力し直してください。

ゾーン識別子は慎重に扱う

リンクローカルリテラルは、インターフェースに結び付いたゾーン識別子を必要とすることがあり、パーセント記号とインターフェース名で書きます。その形式はインターフェースを持つホストで有効であり、一般に到達可能なリモートエンドポイントの代わりにはなりません。

解析が成功したあとも、スコープとルーティングは重要です。クライアントが受け入れるゾーン修飾アドレスに、そのマシンからの経路がないことがあります。インターネット越しに到達するリモートエンドポイントはローカルのゾーンにまったく依存すべきではないので、ハンドシェイクが失敗してからではなく、ゾーンを書く前に、パケットがどのインターフェースから出るべきかを決めてください。

解析を確認し、次に到達性を確認する

二つの失敗を明確に分けてください。壊れたアドレスは解析エラーか即時の拒否を生みますが、正しく形成されたエンドポイントが認証を拒否したり応答しない場合は、別の解決策を要する別の問題です。

サポートされた修正のあと、トンネルが折衝し、意図したアプリケーションが動くことを確認してください。ハンドシェイクだけでは経路を証明しませんし、エンドポイントへのpingもトンネルを証明しません。運用者がホスト名を提供する場合は、対応している名前とその身元確認を維持し、別の場所で見つけた数値アドレスに置き換えないでください。

変更メモに、正確なフィールド、使った値、クライアントの応答を記録してください。そうしなければ次にプロファイルを編集する人が角括弧の実験を繰り返しますが、答えはすでにチケットの中にあります。