OpenVPN：ローカルアドレスとトンネルアドレスは別のソケット

クライアントは起動を拒み、ローカルアドレスを bind できないと訴え、明白な修正は受け取るはずのトンネルアドレスを指すことのように見えます。それは機能しません、そして理由を理解する価値があります：トンネルが存在する前は内側のアドレスは存在せず、サーバーに接続するソケットが先に存在しなければなりません。関与するアドレスは二つあり、そのうちローカルで選べるのは一つだけです。

bind エラーが指すのはローカルアドレス

OpenVPN がローカルアドレスを bind できないと報告するとき、それはトランスポートソケット、つまりピアへの暗号化接続を運ぶ UDP または TCP の終端点の話です。

明示的な local ディレクティブは、そのソケットを特定のローカルアドレスに bind するようデーモンに求めます。アドレスはプロセスが動くネットワーク名前空間に存在し、クライアント起動の時点で割り当て可能でなければなりません。

ルーターやクラウドのエッジで変換されるパブリックアドレスは、デーモンが bind できるローカルアドレスではありませんが、サーバーが見るのはそのアドレスです。この区別が、あるプロファイルが自宅では動きクラウドインスタンスでは失敗する理由を説明します。パブリックアドレスを loopback インターフェースに足しても役に立たないのも同じ理由で、その場合トランスポートはネットワークが応答を返せないアドレスから出て行くからです。プロファイルを編集する前にインターフェース一覧を読んでください。

local と remote が実際に選ぶもの

remote は接続先のピアを指定します。local は同じソケットの手前側を bind します。nobind はローカルアドレスとポートの両方を OS に選ばせ、だから自宅ルーターの内側のクライアントは、どちらのディレクティブもなしで動くのが普通です。

どちらのディレクティブも、トンネル内のアドレスとは関係ありません。

コンテナやネットワーク名前空間では同じ規則がより狭い境界で当てはまり、ホストのアドレスは内側に存在しないため、ホスト設定からコピーした local 行は、間違ったアドレスとはまったく別の理由で失敗します。

ip -brief address show
ip route get 203.0.113.10

内側のアドレスはサーバーから来る

トンネル内のアドレスは、制御チャネルが確立した後に交渉または割り当てされます。動的プールでは接続時にサーバーが決め、クライアント固有の設定では識別子ごとに固定されることがあります。

内側のアドレスで local を書いても、サーバーにそのアドレスの割り当てを求めることにはなりません。最良の場合は bind が失敗し、最悪の場合はクライアントが同じ値の無関係なホストアドレスを見つけ、それをトランスポートに使い始めます。

読むべきインターフェースも違います。ifconfig のパラメータとプール設定は内側を表し、remote・local・proto・nobind は外側を表します。二つの一覧を分けておくと、フォーラムで見かける混乱した例のほとんどが説明できます。OpenVPN 2.6 のマニュアル が別々の節で記述しているのも同じ理由です。

罠：自分のトランスポートを捕まえるフルトンネル

トンネルが上がり既定ルートを運ぶようになると、それを支えるパケットをトンネル内へルーティングしてはいけません。これはアドレスの問題ではなくルーティングの問題で、デーモンは元のゲートウェイ経由でサーバー自身のアドレスへのより具体的なルートを入れて対処します。

トランスポートを特定のローカルアドレスに固定し、後でそのアドレスが使う経路を変えると、内側が設定されたまま外側の接続だけが道を見失うことがあります。内側は正常なので、トンネルは接続済みと報告し続けます。壊れているのはトランスポートだけで、だからログは矛盾のように読めるのです。

症状は、接続して固まるトンネル、あるいは役に立つエラーなしにループで再接続するトンネルに見えます。トンネル内を確認する前にピアのアドレスへのルートを確認し、bind したローカルアドレスが今も想定したインターフェースに属していることを確かめてください。

混乱を防ぐ習慣

プロファイルの各アドレスを読み、編集する前にどの層に属するかを決めてください。

トランスポートの遠い端を指定している、あるいは手前の端を bind しているなら、それは外側のアドレスであり、起動前に存在していなければなりません。トンネル内で起きることを述べているなら、それはサーバーかトポロジーから来るもので、ローカルのディレクティブで代用はできません。

二つの一覧をプロファイルの隣の配備メモに書いておきます。次のトラブルシューティングは、推測ではなく層から始まります。