--- title: "代替WANトラブルシューティング" slug: "alternative-wan-troubleshooting" updated: 2026-07-30T01:31:51Z published: 2026-07-30T01:31:51Z canonical: "knowledge.catonetworks.com/alternative-wan-troubleshooting" --- > ## Documentation Index > Fetch the complete documentation index at: https://knowledge.catonetworks.com/llms.txt > Use this file to discover all available pages before exploring further. # 代替WANトラブルシューティング ## 概要 代替WAN（Alt。 WAN）は、柔軟で強靭なWANトラフィック管理ソリューションを提供することで、組織がネットワーク接続性を向上させることを可能にします。 同一サブネット上のソケット用のレイヤー2と異なるネットワーク上のソケット用のレイヤー3の設定をサポートします。 展開に関する詳細は、[代替WANネットワークとの統合](/v1/docs/integrating-cato-with-an-alt-wan-network)を参照してください。 この記事は、Alt。 WANに関する一般的な問題と、それを解決するためのトラブルシューティング手順を提供します。 ## 症状 以下は、Alt。 WANが期待通りに機能しない場合の一般的な症状です： - Alt。 WAN接続が確立できない - CMAはサイトを切断状態として表示しますが、トラフィックはAlt。 WAN - Alt。 WAN使用時にサーバによってTLS接続がリセットされる - Alt。 プライマリトンネルがダウンすると、WANの復旧が失敗する - Alt。 BGP接続が確立できない ## 可能な原因 - 誤った設定 - UDP/20049がAlt。 WANサイト間でブロックされている - 高いソケットCPU ## 問題のトラブルシューティング ### 代替WANトンネルが確立されない #### 設定を確認 - 正しい設定を確認するために、代替WANが有効になっているソケットサイトに移動します。 **ネットワーク > サイト > ソケット**に移動し、代替WANインターフェースの**ポートステータス**が**アップ**として表示されていることを確認します。 - ステータスが**ダウン**と表示されている場合、ネットワークに正しく接続されていることを確認するためにポート接続をチェックしてください。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22956910173085.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - インターフェースが**代替WAN（レイヤー2）**または**代替WAN（レイヤー3）**の正しいオプションで設定されていることを確認します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22983816847773.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - 次に、IPアドレスとサブネット設定が正確に構成されていることを確認します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22983845786909.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - 代替WANトンネルがアクティブであることを確認するには、[ソケットWebUI](/v1/docs/using-the-socket-webui-tools)にアクセスします。 代替WANトンネルが正しく確立された場合、**SDWANトンネル**の下に接続されているチャンネルの数が表示されます。 - ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22958985729053.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) #### UDPポート20049がブロックされていないことを確認します - 代替WANトンネルは**UDP/20049**上で確立されます。 - 両方のソケットのSocketUIにアクセスして、トラフィックキャプチャタブに移動します。 - Alt。 WANが設定されており、UDPプロトコルのキャプチャを開始します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/21913272403613.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - PCAPはUDPポート20049について双方向トラフィックを表示する必要があります。 双方向のフローが見られない場合は、2つのサイト間のいかなるデバイスがUDP/20049をブロックしているかを確認してください。![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/21913283042589.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D)**注：** 代替WANレイヤー2の構成では、トンネルは代替WAN IPを使用して開始されます。 対照的に、代替WANレイヤー3の構成では、トンネルはネイティブサブネットのローカルIPを使用して開始されます。 以下の表は、トンネルの送信元IPに注目して、レイヤー2とレイヤー3の設定でのトラフィックフローの違いを強調しています。 | **レイヤー2** | **レイヤー3** | | --- | --- | | ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22960352948637.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) 代替WANトンネルは代替WAN IPから開始されます。 代替WANインターフェースからのパケットキャプチャは、IPアドレス192.168.20.2からトンネルが開始され、リモートサイトの代替WAN IP: 192.168.20.3および192.168.20.4と接続が確立されることを示しています。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22960344390429.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) | ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22960344394781.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) ソケットUIで代替WAN IPアドレスが192.168.20.2として設定されていますが、代替WANトンネルはこのIPからは開始されません。 代替WANインターフェースのパケットキャプチャは、トンネルが代わりに192.168.2.1から開始され、リモートサイトに対して代替WAN用に構成されたネイティブローカルIP：192.168.3.1および192.168.4.1と接続が確立されることを示しています。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/22960344395805.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) | ### CMAでのサイトが切断されているにもかかわらずAlt。 WAN - サイトはCatoクラウドへのトンネルがダウンしているためにCMAで切断状態として表示されます。 - トラフィックはAlt。 WANリンクを介して流れ続け、ネットワーク操作を保証しますが、CMAはそれにアクセスできないためサイトをオフラインとして登録します。 - CMAでの可視性を回復するには、トンネル接続をトラブルシューティングしてCatoクラウドに再確立します。 詳細なトラブルシューティング手順については、[ソケット・サイト・トンネル接続性のトラブルシューティング](/v1/docs/socket-site-tunnel-connectivity-troubleshooting)をご覧ください。 ### Alt。 WANリンクでのTLS接続失敗 - Alt。 WANは主なトランスポートとしてWANを使用するように明示的に設定されたネットワークルール![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/21913283042973.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - ソケットUIのチェックでは、Alt。 WANトンネルが有効です。![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/21913272404637.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - しかし、サーバーはAlt。 WANを使用する際にTLSアプリケーションを常にリセットします。 - このシナリオでは、Alt。 WANルールの上に複雑なネットワークルールが存在しないことを確認することが重要です。 複雑なネットワークルールとは、ソケットが直接評価できないルールのことです。 したがって、Alt。 WANルールの上に複雑なルールがある場合、ソケットは適切なネットワーク処理を決定するためにPoPにトラフィックを送信します。 - このプロセスにより、戻りのトラフィックがAlt。 WANリンク上を通過するときに対称性のないフローが生じ、最終的にサーバーが接続をリセットします。 - 複雑なルールについての詳細は、[CatoのTCPアクセラレーションおよびベストプラクティスの説明](/v1/docs/explaining-the-cato-tcp-acceleration-and-best-practices)、「*複雑なネットワークルールの作業」 と題された セクション をご覧ください。* - この問題の解決方法については、[AWS-WANリンク上のTLS接続失敗の解決方法に関する指針](/v1/docs/alternative-wan-troubleshooting#solution-to-tls-connection-failure-on-alt-wan-links)を参照してください。 Alt。 ### WANへの復旧。 プライマリトンネルがダウンした際にAlt。 - WAN が発生しませんでした。 デフォルトでは、Alt。 WANの復旧は有効になっていません。 - これは限定機能とみなされており、それを選択したい場合は、Cato担当者にリクエストを送信することができます。 ### BGPが接続を確立できません - 顧客のBGPルーターとAlt。 WANリンク上でソケットの間でBGPピアリングが設定されていますが、BGP接続が確立できません。 - この場合、Alt。 ソケットのWAN構成は次の通りです： ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/21913283043485.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - BGPルーターのログは、次のホップが無効であることを示しています。 一つの可能な理由は、BGP更新で広告された次のホップがBGPピアを介して到達不可能であることです。 ```plaintext %BGP-5-ADJCHANGE: neighbor 192.168.200.1 Up %BGP-3-NOTIFICATION: received from neighbor 192.168.200.1 3/8 (invalid next hop specified) 4 bytes 0AFD0011 ``` - 次のホップが無効でないのが原因で、BGP構成で次のホップセルフコマンドを使用するのが潜在的な解決策です。 このコマンドは、ルーターに自分自身を次のホップとして宣伝するよう指示し、広告されたルートが受信するBGPピアに到達可能な次のホップIPアドレスを持つことを保証します。 - この問題の詳細については、[BGPが接続を確立できない解決策](/v1/docs/alternative-wan-troubleshooting#solution-to-bgp-fails-to-establish-connection)を参照してください。 ### ソケットCPUパフォーマンスの確認 - 持続的なCPU利用率が90％以上で、ソケット性能にネガティブな影響を与え、パケットの損失、トンネルが確立されず、または頻繁に切断が発生する可能性があります。 - ネットワークアナリティクスに移動し、[ハードウェア](/v1/docs/showing-the-site-network-analytics)タブを選択して、コアごとの履歴CPU使用状況を表示します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/25467347853469.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - リアルタイムのソケットCPU使用率を確認するには、ソケットWebUIにアクセスしてHWステータスタブを選択します。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/25467347857053.png?sv=2026-02-06&spr=https&st=2026-11-10T17%3A11%3A09Z&se=2026-11-10T18%3A11%3A09Z&sr=c&sp=r&sig=snmi2H0yhJLvK1nDTf0O7Mh6NCUd78W5EfPswW3zg2o%3D) - 継続して高いCPUが検出された場合は、[サポートに連絡](/v1/docs/submitting-a-support-ticket)してください。 ## 発見した問題の解決 ### Alt。 WANリンクでのTLS接続失敗の解決策 - オフクラウドまたはAlt-WANリンクを使用している場合、単純なネットワークルールが定義済みのアプリケーションを含む複雑なルールの下に配置されている場合、Catoサイト間のTLS接続が失敗する可能性があります。 - これは、TCPプロキシが強制され、TCPハンドシェイクがCatoクラウドを通過する一方、データパケットがAlt。 WANを通過する結果、接続がリセットされます。 - 解決策は、単純なオフクラウドまたはAlt-WANルールを複雑なルールの上に移動するか、あるいは、TCPプロキシの強制を避けるためにTLSインスペクションを無効にすることです。 - この問題の詳細については、[オフクラウドまたはAlt-WANリンクでのTLS接続失敗](/v1/docs/tls-connection-failure-over-off-cloud-or-alt-wan-links)をご覧ください。 ### BGPが接続を確立できない解決策 - 顧客はデフォルトルートの次のホップがBGPルーターで正しく設定されていることを確認する必要があります。 顧客のルーターでは、以下のいずれかのオプションを使用してデフォルトルートを設定します： 1. 次のホップをBGP隣接の代替WAN IPとして設定するために、ネクストホップセルフコマンドを使用します： ```plaintext neighbor <ソケット代替WAN IP> next-hop-self ``` 2. ルートマップを適用して、ルーターの代替WANインターフェースIPに次のホップを明示的に設定します： ```plaintext route-map <マップ名> permit 10    set ip next-hop <ルーター代替WANインターフェースIP> ``` ## 制限／注意点 - Alt。 WANがHAサイトで構成されている場合、Alt。 WANトンネルは**マスター**ソケットのみで確立されます。 したがって、通常の状態では、**マスター**ソケットだけがAlt。 WANトンネルをリモートサイトと確立します。