OpenConnect vpnc-script: 実際に動いているのはどのファイルか

OpenConnect はトンネルのハンドシェイクを終えても、プライベートサブネットへのルートがないままにできます。クライアントと、ローカルのネットワーク状態を書き換えるヘルパーは別のプログラムだからです。認証が証明するのはゲートウェイがセッションを受け入れたことだけで、その後にどのインターフェース、どのルート、どのリゾルバ設定が入ったかは何も証明しません。混乱した報告の多くは、古い回答から取ったコピーでヘルパーを置き換えることから生じ、それはマシン上のすべての接続の挙動を変えます。どれかを編集する前に、実行中のクライアントが実際に呼び出しているヘルパーを特定してください。

二つのプログラム、二つの責務

クライアントが持つのは転送、認証、トンネルデバイスです。別のヘルパーが持つのは、トンネルができた後にローカルシステムで起きること、つまりインターフェースのアドレス設定、ゲートウェイが通知したサブネットへのルート、リゾルバの設定です。OpenConnect のヘルパーのドキュメントはその分担と、ヘルパーが受け取る環境を説明しています。この区別は障害時に重要です。パスワードの拒否とルートの欠落は同じ障害ではなく、デスクトップが両方に一つのダイアログを出していても変わりません。

この分担を意識すると、トンネルが上がっているのにプライベート名が解決できない理由も説明できます。どちらの場合もトンネル自体は動作しており、違うのはローカル統合の段階だけです。

実行中のクライアントが使うヘルパーを特定する

パスはパッケージのビルド時に決まり、呼び出しごとに上書きできます。だから別のディストリビューションで覚えたファイルが、この接続と関係ないこともあります。たまたま開いていたドキュメントではなく、実行中のプロセスに尋ねてください。

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

プロセスの行に--script引数があれば、そのファイルがコンパイル時の既定より優先されます。古いパス、たとえば次のようなものは/etc/vpnc/vpnc-script存在していても使われないことがあり、だから消したり編集しても最近のビルドでは何も変わりません。変更日時も確認してください。何年も誰も触っていないヘルパーは、パッケージの既定が仕事をしている強い証拠です。

NetworkManager との統合は三つ目の所有者で、独自のヘルパーとプロファイル設定を持ちます。その統合の上に二つ目のルート用やリゾルバ用のスクリプトを重ねると、ルートが二重になり、二つのプログラムがそれぞれ管理していると主張するリゾルバが残ります。接続ごとに所有者を一つ選び、テストの前に他方を無効にしてください。

最後の警告ではなく、最初に失敗した操作を読む

インターフェース設定、ルートのインストール、リゾルバの選択、古い状態の後片付けは別々の手順であり、最後に表示される警告は接続を壊した障害ではなく後片付けの不満であることがよくあります。最初に失敗した具体的な操作まで遡って読んでください。ファイルやアドレスを名指しするヘルパーのエラーは、十行の後片付けノイズより価値があります。

意図したローカルの結果と観測した結果を比べます。トンネルデバイスが存在し、既知のプライベートアドレスへのルートがそこを通り、リゾルバがプライベート名に答えるかどうかです。最初の二つは成功して三つ目で失敗するヘルパーは、ルーティングではなくリゾルバのポリシーを示します。デバイスをまったく設定しないヘルパーは実行されていない可能性が高く、それはネットワークではなく権限の問題です。ロジックを書き換える前に、実行ビットとサービスアカウントを確認してください。

接続、再接続、切断を検証する

設定は契約の半分にすぎません。同じヘルパーが、トンネルが閉じるときに自分が持つ状態を復元または削除しなければならないからです。ルートを追加して決して削除しないヘルパーは、セッションより長く残る古い経路をマシンに残します。

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

接続中に最初の三行を実行し、切断してからもう一度実行し、ルートとリゾルバのエントリが消えたことを確認します。四行目は、ヘルパーがそもそも呼ばれたかどうかと、サービスがどの実行パスを使ったかを示します。この二つの出力をチケットに残してください。前後の比較こそが後片付けの不具合を明らかにするからです。

ヘルパーはパッケージのまま、サービスアカウントから実行できる状態に保ってください。シェルで動くスクリプトでも、制限されたサービス運用ポリシーの下では拒否されることがあります。本当にカスタマイズが必要なときは、目的と所有者を記録し、更新のたびにパッケージ版と比較してください。説明のないヘルパーのフォークは、一年後に動いていた接続を失敗させ得る数少ないものの一つです。