すべてのOpenVPNピアにremote行は必要か？そうとは限らない

二つのピア設定が並べて比較され、一方にはremote行があり、もう一方にはない。そして結論は、どちらかが壊れているというものだ。その推論は十分に頻繁に誤りであり、分解する価値がある。このディレクティブは最初のパケットをどこへ送るかを記述する。プロセスが開始するクライアントとして振る舞うのか、待機するゲートウェイとして振る舞うのかを選ぶものではなく、どちらの側が相手に身元を証明するかも決めない。

remoteが実際に指定するもの

remoteエントリはホストを指定し、任意でポートとトランスポートを、さらに任意で順に試す複数のそのようなエントリを指定する。

それが無いことは未定義ではなく、定義された意味を持つ。プロセスは待機し、そのピアが認証しない限り、あるアドレスからのパケットに作用しない。したがって、ローミング利用者にサービスするゲートウェイが、彼らの誰かを事前に名指しする理由はない。

このエントリはアドレスの関係として読むべきだ。遠端が信頼できるかは証明書と検証オプションが答えるものであり、アドレスが書かれているという事実ではない。

三つの構成が答えを決める

ローミングクライアントには宛先が必要だ。開始しなければならず、宛先がなければゲートウェイがどこにあるか分からないからだ。多クライアントゲートウェイには利用者ごとの宛先は不要だ。クライアントが到着して認証するからだ。既知の端点を持つ意図的な二ピア接続では、どちらの側が開始するかによって、片側だけ、両側、あるいはどちらにも宛先を持たないことがある。

固定のクライアントアドレスを汎用ゲートウェイに貼り付けるのは、そうした分類を無視した結果の誤りだ。アドレスが記録された唯一のピアには効くが、それ以外の全員を誤導する。

このディレクティブが設定を多クライアントサーバーに変えることはなく、その存在がサーバーの役割を妨げることもない。OpenVPN 2.6のリファレンスは、任意引数とremoteがない場合の動作を別々に記述しており、これは両者がいかに独立しているかの手がかりだ。

トランスポートの役割は別の軸

TCPでは片側が待機し、もう片側が発信する。これらは宛先とは別のディレクティブであり、混ぜると両方が待機するか両方が発信する組になる。

TCPの送信元フィルタという役割もあり、サーバーが決してremoteを含んではならないという平板な断定が誤りである理由はそこにある。

UDPでは確立すべき接続がないため、両端は対応するUDPトランスポートを使い、ディレクティブはどこを狙うかだけを言う。認証済みピアによるアドレス変更は、エントリを増やすのではなく専用の動作で扱われる。トランスポートを正しくすることが宛先を意味あるものにする前提であり、両者を混同すると、もっともらしく見えてハンドシェイクを決して完了しない設定が生まれる。

remoteがないことが開いた扉でない理由

宛先のないプロセスでも、認証しないピアからのトラフィックは拒否する。人々が欠けている行を誰にでも開かれたリスナーと読むときに見落とすのはこの部分だ。

認証と宛先は独立しており、信頼にとって重要なのは前者だ。

逆の誤りのほうが危険だ。固定の送信元アドレスは具体的で確認しやすいため、アクセス制御のように感じられる。しかし、相手が誰であるかについては何も証明しない。証明書の検証を保ち、証明書をその役割に結びつける身元確認も保つべきだ。それらをアドレスの一致で置き換えることは、実際の制御をその見かけと引き換えにすることになる。

設定が何を前提にしているかを書き出す

各側について三つを記録する。最初のパケットがどうピアに届くか、どちらの側がトランスポートを受け入れられるか、各側が相手について何を検証するか。

その前提が設計だ。ディレクティブはその綴りにすぎない。

二つのファイルが異なるなら、どちらかが誤りだと決めつけるのではなく、異なる前提を表しているかを確認する。対称なファイルの組は動作するトンネルに必要でも十分でもなく、非対称性こそがトポロジーを機能させる部分であることが多い。