pull-filter はサブネットではなくテキストを照合する：接頭辞として読む

意図は、送られたルートを ひとつ落とすことでした。変更後、別のルーティングオプションが欠けたり、クライアントがループで再接続したりします。どちらの結果も、テキストを比較するフィルターをサブネットのルールとして読むことから生じます。クライアントは、送られたオプションが指定した文字で始まるかどうかを調べるだけで、どの段階でもアドレスの論理は関与しません。

フィルターが実際に比較するもの

送られる各オプションは、名前とその引数からなる行として届きます。フィルターはあなたの文字をその行の先頭と比較し、アドレスが解析される前、ルートがインストールされる前に判定します。そのため、名前に対して書いたルールは、その文字で始まるすべてのオプションを捕捉し、見ていたひとつだけに限りません。だからフィルターは単独では正しく見えても、無関係なものを削除してしまうのです。

ネットワーク範囲に見える文字列も、やはり文字にすぎません。接頭辞を選ぶことも、ネットワークビットを計算することも、宛先の集合を表すこともできません。そうしたルールが機能しているように見えて後で止まる場合、送られたテキストの形が変わっているのが普通です。

空白ひとつで一致集合が変わる

同じオプション名でも、末尾の区切りがある場合とない場合では別の行を選びます。区切りがなければ一致は開いたままになり、区切りがあれば引数が始まる前にオプション名がまさにそこで終わらなければなりません。

pull-filter ignore "route"
pull-filter ignore "route "

開いた形は、同じ文字で始まるだけのオプションも捕捉し、そうして 落としたいと思っていたルートと一緒に無関係なルーティング動作まで消えてしまいます。フィルターを書く前に、ログから送られた行をコピーしてください。編集したプロファイルの隣に未編集のコピーを、広い一致を元に戻すのは記憶よりファイルのほうが簡単なので置いてください。

順序とアクションで症状が変わる

ルールは順に評価され、最初の一致が結果を決めるため、早い位置に置かれた広いルールは、後ろの具体的なルールをすべて到達不能にします。アクションも障害を変えます：一致を無視するとオプションが落ちてセッションは続き、拒否すると接続を再起動させるエラーが発生します。したがって、繰り返し送られる行と拒否アクションが組み合わさると再接続サイクルになります。そのサイクルはネットワーク障害と読み違えやすく、一致したオプションを示すログ行が両者を分けます。

どの行が一致し、どのアクションが実行されたかを記録してください。落としたルートと再起動のループでは必要な修理が異なるので、メモにはどちらが起きたのかを書き、両方を曖昧なままにしないでください。

ホストが何をインストールしたか確認する

再接続後に適用されたルートを読み、残したかった宛先と削除したかった宛先の両方を試してください。送られたルートを落としても代替は提供されないため、不要なルートが消えた一方で、リソースが別の経路から到達不能になることがあります。名前が別の場所で解決されるようになった場合は、送られたリゾルバーオプションが同じ広い接頭辞に捕まったかどうかを確認してください。実行したテストに通り、意図したテストに落ちる変更は、ここではよくある結果です。

その違いをチケットに残してください：削除したルート、残すつもりだったルート、そして今テーブルが示している内容です。次の変更はその記録と照らして判断されます。

信頼の境界として扱わない

テキストに対するフィルターは設定の便宜であり、信頼していないサーバーに対する制御ではありません。書式の違いだけで破られるので、マニュアルはその主張を限定しています。サーバーがあなたの組織のものであるなら、ローカルな例外を積み上げるより、プッシュポリシーを直すほうが明確です。

ローカルのフィルターがそもそもなぜ存在するのかを書き留めてください：次の人がまだ必要かどうかを判断できます。フィルターは理由が消えたずっと後まで積み上がります。