スプリットトンネルのルールがサービスと一致しなくなった理由

スプリットトンネリングは通常、二つのうちどちらかの形で失敗します。トンネル内にあるべき通信がトンネルを迂回するか、外に留まるべき通信が内側に引き込まれるかです。古いルールによる失敗は前者で、しかも紛らわしいのは、ルールが書かれたとおりに適用されているからです。変わったのは宛先であり、サービスはルールが決して名指ししなかったアドレスで応答するようになり、トンネル自体には何も問題がありません。

ルールが固定するものと DNS が返すもの

スプリットトンネルのルールは宛先についての静的な宣言で、通常はプレフィックス、ルート、またはアドレス一覧として表されます。送信時にパケットの宛先に対して評価されます。ホスト名は、生存時間とキャッシュを伴うアドレスの集合を返す検索であり、その答えはリゾルバー、クエリ種別、そして分によって変わり得ます。

その二つの対象は互いに交渉しません。ルールは与えられたプレフィックスに一致し続け、サービスは払い出すアドレスを変え続け、両者の隙間は静かに広がります。だから症状は設定変更の後ではなく、プロバイダーの移転や証明書の更新の後に現れます。誰もトンネルを編集していないので、誰もトンネルを見ず、診断はポリシーではなくアプリのほうへ流れます。

一致が壊れる三つの経路

明らかなのはサービスが移転した場合で、運営者が新しいアドレスを与え、DNS は追随し、例外は追随しませんでした。二つ目はルールが決して網羅しなかったアドレスファミリーで、名前が IPv4 専用の例外が無視する AAAA レコードを返し始めると起こります。三つ目はリゾルバーの違いであり、内部向けと公開向けのビューが同じ名前に異なるアドレスを返すことがあるため、アプリが使うアドレスはテストに使ったものとは限りません。

キャッシュされた接続は四つ目の変種で、見落としやすいものです。アプリは一時間前に解決したアドレスとまだ通信しているかもしれず、その場合、新しい検索結果と開いたままのソケットは、サービスの所在について一致していません。

アプリが実際に使う宛先を読む

ブラウザーのタブではなく、オペレーティングシステムとソケット表に問い合わせてください。検索は名前が今何に解決されるかを答え、ソケット表はプロセスが接続しているアドレスを示しますが、それは古い可能性があります。両者の違いがおよそ半分のケースでは答えそのものなので、理論を立てる前に両方を実行してください。

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

次に、ルールが何を覆っているかと比べます。現在のアドレスが例外の外にあり、それでも要求が失敗するなら、トンネルの設定に触れずに原因を突き止めたことになります。アプリがルールに一致するアドレスに接続していて、それでも要求が失敗するなら、問題はトンネルの先にあり、この調査は筋違いです。

症状ではなく仕組みを修復する

製品が保守されるドメインベースの誘導に対応しているなら、それを使い、文書化された更新と適用範囲の挙動に従ってください。静的な推測が保守される答えに置き換わりますが、機能が文書どおりに動くことに依存するという代償があります。

設計が静的な一覧に依存しているなら、所有者と更新計画を定めてください。計画には、アドレスをどう発見するか、誰が変更を承認するか、一覧がプロバイダーの移転にどれだけ速く追随することを期待するかを書くべきです。所有者のない一覧は、原因の分かっている将来の障害です。

短いテストで見たすべてのアドレスを捕まえるためだけに、例外を大きな隣接ネットワークへ広げないでください。それは修正ではなく、セキュリティ境界の恒久的な変更であり、ルールが存在する限り無関係なサービスが静かにトンネルを迂回できるようになります。

意図の両半分を検証する

スプリットトンネルの設計には二つの意図があり、修正はその両方を保つべきです。保護されたサービスはトンネルを通らなければならず、除外されたカテゴリはトンネルを迂回し続けなければなりません。修復した宛先への新しい接続を試し、次に外に留まるべきものを試してください。

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

新しいアドレス、選んだ仕組み、日付を記録してください。 その記録があるからこそ、次の人が VPN が自分の設定をでたらめに無視したと結論づけずに済みます。