支店のサブネットを本社のSonicWallインターネット出口経由でルーティングする

支店の電話は本社経由で出るべきですが、支店のノートPCはローカルWANを使い続けるため、ルーティングポリシーだけではこれを実現できません。支店ルートはトンネルを選択できますが、トンネルポリシーがトラフィックを受け入れる必要があり、本社がそれを転送して変換し、応答が同じ経路で戻ってこなければなりません。この三つのどれかが欠けると、症状はトンネルが稼働している間だけインターネットを失う一部のクライアントになります。

セレクターから始め、ルートから始めない

ルーティングポリシーはソースで照合するため、何よりも先にソースが安定していなければなりません。選択したデバイスを管理者が維持するアドレスグループに入れるか、さらに良いのは、メンバーシップがデバイスの役割に従う専用セグメントに置くことです。通常のDHCPの入れ替わりで一致したアドレスが別のマシンに移ると、ポリシーは黙って誤ったクライアントを選び、最初の報告はたいてい遅いブラウジングであり、実際には遠回りです。

グループ名は、フロアや部門ではなく、それが提供するポリシーにちなんで付けてください。ルーティングルールはどちらよりも長く残るので、どのデバイスが含まれ、誰が追加できるかを記録してください。

支店ポリシーを追加し、その順序を守る

支店のSonicWallでは、ルートポリシーがソースグループを選択し、意図する宛先を指定し、トンネルインターフェースをゲートウェイに設定しますが、これはサポートされたトンネルインターフェース設計の目的そのものであり、ローカルおよびプライベート宛先のルールは広いインターネットルールより上に保ってください。なぜなら最初の一致が勝ち、トンネルに押し込まれたプライベートプレフィックスは本社に届いても破棄されるだけだからです。ファイアウォール自身のVPNピアへのルートも維持しなければ、トンネル輸送が依存するポリシーに従ってしまいます。これらのどれも、既存のポリシーベースのトンネルをすべて変換することを強制せず、トンネルインターフェースはいくつかあるサポート済みの選択肢の一つです。

順序は事故で変わる部分です。例外を追加する人は広いルールの上に挿入しなければならず、広いルールを編集する人は一回の保存で設計全体を反転できます。意図する順序をポリシーの横に書き、インターフェースの命名とポリシーの表示がリリース間で実際に変わるため、ファームウェア更新後に再確認してください。

本社で経路を完成させる

本社のトンネルポリシーは、支店ルートが選択するトラフィックを受け入れる必要があります。本社のプライベートLANに限定された拠点間セレクターは、任意のパブリック宛先を運ぶ許可ではないため、ポリシーには支店のソースと、実際に意図する宛先範囲が必要です。本社はその受信トラフィックを独自のアクセスルールに従ってインターネットアップリンクへ転送し、SonicWallの中央出口の例には中央WANでのリモートネットワークのソース変換が含まれます。この変換がないと、遠端はプライベートな支店アドレスを見て、そこへの戻りルートを持ちません。

応答は契約のもう半分です。応答はトンネルまたはそれ用に作成されたステートフル変換を通って戻らなければならず、プライベートサイトのトラフィックはパブリック出口とは異なるNAT処理を必要とする場合があります。すべての内部ソースを隠す一つの広い変換ルールは後からのログ記録とトラブルシューティングをはるかに読みにくくするため、これらのルールを区別可能に保ってください。

トンネルが切れたときにグループがどうするかを決める

中央出口が好みではなく要件である場合、ユーザーがオンラインのままであってもローカルWANへのフォールバックはコンプライアンス違反です。SonicOSは、選択したトラフィックが意図しない代替経路を取るのを防ぐサポート済みの方法として、トンネルインターフェースをドロップするルートを文書化しています。

そのルートの範囲と優先度をインストール済みリリースに合わせ、ラベルを信じるのではなくトンネルを落としてテストしてください。決してローカルへ出てはならないグループはクローズドに失敗すべきであり、可用性の方が重要なグループは正当にフォールバックしてかまわず、どちらも判断であり、どちらもデフォルトで起きるべきではありません。

三台のクライアントから確認し、その後きれいにロールバックする

中央ゲートウェイへのpingは、ファイアウォールから発信され選択されたクライアントからではないため、間違ったものをテストします。代わりにデバイスからテストし、そのうち三台、つまり選択されたデバイス、ローカルにとどまるべき通常のデバイス、ローカルサービスに依存するデバイスをテストしてください。

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

パブリックリクエストが実際にどこから出たかを比較してください。選択されたクライアントは本社の出口を通ってインターネットに到達すべきであり、通常のクライアントは遠端で支店自身のアドレスを提示し続けるべきで、203.0.113.10は気にする宛先の代替として使われるドキュメント用アドレスです。支店のリゾルバーに問い合わせるクライアントはルーター起源で異なるソースを持つ検索を生成し、その結果として異なるルートを生む可能性があるため、DNSも同じパスに含めてください。

ロールバックは保存されたポリシー順序とアドレスグループです。以前の順序を復元し、ポリシーからグループを外し、両方のデバイスクラスを再テストしてください。次のエンジニアが誰かが編集する前の広いルールを知る必要があるため、エクスポートした設定を変更記録と一緒に保管してください。