TS_UNACCEPTABLE は、壊れたプロファイルではなく、カバレッジの不一致として読む。ゲートウェイは、このトンネルがどのアドレスを運べるかで両ピアが合意できなかった、と言っている。その時点で IKE SA はすでに確立していることがあり、だからクライアントは背後に子 SA がないまま接続済みに見える。そう捉えれば、作業は機械的になる。両側の意図したプレフィックスを書き出し、片方向で比較し、交差するまで狭める。

まず意図した組を書き出す

設定に触る前に、開始側の送信元範囲、その宛先範囲、そして応答側から見た同じ組という四つの値を並べる。それぞれのアドレスファミリーも記録する。IPv4 の範囲と IPv6 の範囲は別のセレクタ種別であり、どちらも他方のペイロードに畳み込むことはできない。

ポリシーが持つプロトコルやポートの制限も加える。ファイルサーバーへの TCP 445 だけを許可する規則は、それが属するサブネットより狭い集合を表す。これをメモから外すと、交渉結果は見えない理由で一貫しないように見える。

比較する前にラベルを入れ替える

ローカルとリモートは相対的なラベルだ。クライアントのローカルプレフィックスはゲートウェイのリモート範囲であり、ゲートウェイのローカル範囲はクライアントのリモートだ。だから両端のスクリーンショットは決して一致せず、それを文字どおり比較するのは午後を失う定番の方法だ。

応答側は提案を拒否する代わりに、受け入れ可能な部分集合へ狭めることがある。その結果は、半分だけ動くためにきれいな失敗より悪い。ポリシーが 10.0.5.0/24 を許すときに 10.0.0.0/16 を要求すると、その /24 だけを覆う子 SA で終わることがある。一台のホストだけが応答し、ほかはすべて外に落ち、クライアント側では何もそれを告げない。交渉が成功したと結論づける前に、要求したセレクタではなく受け入れられたセレクタを読む。

既定ルートを要求するロードウォリアーのプロファイルは、ここに頻繁に落ちてくる。分割アクセス向けに作られたゲートウェイは、全範囲の提案を自分のサブネットに狭め、クライアントは狭められた結果を受け入れるか、大きな音を立てて失敗するしかない。

拒否は一度の試行から読む

同じ接続試行の両方のログを集める。保存済みのプロファイルは設定した内容を示すのであって、提案された内容ではなく、strongSwan では swanctl --log が受信した通知を、それが運んだセレクタとともに出力する。

次に、実際に何がインストールされたかを見る。swanctl --list-sas は子 SA のセレクタを示し、ip xfrm policy は同じ範囲をカーネルポリシーの項目として示す。その一覧に意図しないセレクタを持つ子 SA があれば狭められた出来事であり、子 SA がなくログに TS_UNACCEPTABLE があれば拒否だ。

そこにいる間に、近い隣人を切り分ける。INVALID_SELECTORS は確立済みの子 SA の内側のセレクタについて不平を言い、INTERNAL_ADDRESS_FAILURE は応答側が仮想アドレスを割り当てられなかったことを意味し、これはプールの問題であってカバレッジの問題ではない。

静かに集合を縮めるものを確認する

三つのものが、何も言わずにセレクタ集合を縮める。一つ目は応答側のポリシーで、サブネット一覧、グループ規則、ユーザー単位の認可によって提案が部分集合に減る。二つ目はアドレスファミリーで、デュアルスタックのクライアントは IPv4 と並べて IPv6 を提案しがちで、ゲートウェイが一度も設定していない範囲について拒否を受ける。

三つ目はプロトコルとポートの制限だ。ポリシーが TCP 445 だけを許す場合、ICMP と UDP が外に残ったまま子 SA が上がることがあり、利用者は、許されていたのが一つのプロトコルだけだったのに、トンネルが壊れたと報告する。

したがってアドレスを広げるだけではポート制限のあるポリシーは直らず、これこそが三回の切り分けを経ても変わらずに残る可能性が最も高いケースだ。

合うトラフィックでカバレッジを証明する

子 SA がインストールされたら、受け入れられた範囲の内側に確実に入る要求を一つ送る。状態アイコンではなく、ip -s xfrm state と ip xfrm policy の背後のカウンターがパケットの一致と保護で増えるのを見る。実際のトラフィックの後もゼロのままのバイト数は、カーネルがそのポリシーを一度も選ばなかったことを意味する。

そのゼロはルーティングかポリシー順序の問題であり、暗号の問題ではない。利用者の席から見るとセレクタ拒否とまったく同じに見えるため、プロファイルを開き直す前にカウンターを集める価値がある。一方向にしか増えないカウンターは、代わりに戻り経路を指している。

最後に、受け入れられた組を、当初要求した範囲の隣にチケットへ書き込む。選択は要件と同じだけ狭く保つべきで、非公開範囲をすべてのアドレスに置き換えてエラーを消すのは、アカウントに承認された以上のアクセスを与えてしまう。

関連記事