スプリットトンネリングと企業ポリシー：どちらのルールが勝つか

スプリットトンネルクライアントで一つのアプリにチェックを入れるのはローカルな好みのように感じられるが、管理された端末ではポリシーの変更に近い。この例外はトラフィックを承認済みの経路から外す。その経路は、管理された DNS、フィルタリング、サービスが認識する送信元アドレスを運んでいる同じ経路かもしれない。クライアントがあなたの編集を元に戻すのは不具合ではなく、配備が仕事をしているのだ。

チェックボックスを議論する前に、そのポリシーが何を守るために存在するのかを突き止める。

ルールの背景にある性質

すべてを経路制御して全トラフィックを承認済みゲートウェイに通す配備もある。名前解決を重視し、問い合わせをローカルネットワークではなく企業リゾルバに留める配備もある。安定した送信元アドレスを必要とし、内部サービスがそもそも応答するかどうかを判断できるようにする配備もある。

四つ目のグループはエンドポイントの状態を強制する。ディスク暗号化の状態、パッチの水準、エージェントの健全性だ。トンネルを分割してもそれらは変わらないが、エージェント自身のトラフィックを避けるバイパスなら変わりうる。

これは四つの異なる要件であり、それぞれ別の例外によって壊れる。変更を提案する前に要件を読みなさい。書いた人なら、どれが当てはまるかすぐに答えられる。間違った要件を満たす変更は何も買わない。

二つの主張は早めに捨てる価値がある。全トンネルは管理者にすべての平文ページを渡すわけではない。何が見えるかはアプリケーションの暗号化とエンドポイント制御が決めるが、スプリットトンネリングも一律に危険ではない。管理された DNS、アプリごとのポリシー、エンドポイントエージェントは経路にかかわらず成り立つからだ。

チェックを順番に実行する

以下の順序は、例外を実際に失敗した最小のものへ絞り込む。成り立たない最初のチェックで止める。後の修正は前の抜けを補えない。

どのトラフィックが承認済みゲートウェイを外れているかを尋ね、次に名前解決が今も企業リゾルバに届くことを確認する。問題のアプリがキルスイッチを尊重するか、失敗した試行を直接経路で費やしたかを見る。そのうえで共有サービスを見る。文書ビューアや更新ブローカーは、チェックボックスが示すより例外を遠くへ運ぶことがある。最後に、再接続時にポリシーが再適用されるかを記録する。その振る舞いが、ローカルな変更が生き残るかを決める。

どの答えも事実であり、例外の申請に必要なのは事実だ。VPNがうるさいかどうかの議論はその一つではない。会話を始める前に答えを書き留める。

狭い例外を申請する

アプリケーション、宛先、失敗した操作をこの順で報告する。更新プログラム一つを直接経路に残す申請は検討できる。ブラウザ全体でトンネルを迂回する申請は検討できない。

すでに試したこととログが示したことを書き、ヘルプデスクの担当者ではなくプロファイルを所有するチームに宛てる。管理された端末では、プロファイルの所有者が通常、更新後も残るサポートされた除外を作成できる。ローカルの経路編集ではそれができない。

答えがノーなら、それは設計上の決定として扱い、回避すべき障害とは見なさない。次のレビューが再び開く場所であり、失敗した操作を記録し、業務上の理由を添える。回避すれば、例外が本来価値とする以上に危険を冒すことになる。

例外を生き残らせる

承認された変更の後は、壊れていた部分だけでなく、以前から機能していた部分も確認する。内部名は今も企業リゾルバで解決され、プライベートなリソースは応答し、以前失敗した処理は今完了するべきだ。

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

最初のコマンドはリゾルバが内部サフィックスに今も応答することを、二つ目は要求が現在の経路から内部サービスに届くことを証明する。再接続後にもう一度実行する。ポリシーのプッシュは、テスト中は安定して見えた変更を静かに取り消すことがある。チケットと一緒に保存した二行の出力が環を閉じる。それがなければ、例外は一度読み込まれたページについての誰かの記憶に頼ることになる。

例外とその目的、対象となるコンポーネントを、配備のメモと同じ場所に記録する。文書化されていない例外は次の四半期のインシデントになり、文書化された例外は設計が実際の作業負荷に耐える証拠になる。