トポロジー
トポロジをローカルに保存してから拡大して表示できるため、より明確に表示できます。（新しいウィンドウにドラッグして開きます）
NATサーバーテスト
注：NATサーバー機能は以前に展開され、2つのアドレスが変換され、対応するWWWサービスとFTPサービスが提供されました。現在、テストに外部ネットワークを使用しています。
正常にアクセスできるかどうかのイントラネットテスト
注：2つのサービスはすでに正常であることがわかります。
外部PCアクセスに対応するサービス[テレコム]
ファイアウォールには対応するNATセッション情報があります。
通常のFTPではWEBにアクセスできません
外部PCアクセスに対応するサービス[Netcom]
パブリックネットワークアドレスは、引き続き外部ネットワークアクセスの役割として使用されます。
同じものを開くことはできません。
質問：HTTPにアクセスできるのに、FTPアクセスに失敗するのはなぜですか。
注：HTTPはシングルチャネルプロトコルであり、FTPはマルチチャネルプロトコルであるため、アクティブモードとパッシブモードに分けられます。HTTPは、さまざまなモードに従ってアプリケーション層でポート番号とアドレスを動的にネゴシエートします。これにより、アドレスが発生します。 NATの後に変更します。しかし、アプリケーション層のアドレスファイアウォールがそれを認識しなかったため、アクセスが失敗しました。
解決策：[アプリケーション層ゲートウェイ機能ALGを有効にする]
[USG-GW]ファイアウォールゾーン間信頼isp_dx
[USG-GW-interzone-trust-isp_dx] ftpを検出する
[USG-GW]ファイアウォールゾーン間信頼isp_lt
[USG-GW-interzone-trust-isp_lt] ftpの
説明を検出：この構成は、信頼と2つのISPの間にあるアプリケーション層ゲートウェイ機能を有効にするためのものです。この双方向の開口部は方向を区別しないことに注意してください。
開いた後、両方のアドレスに正常にアクセスできることがわかります。
拡張機能：PPTPサーバーがマップされている場合、問題が発生します。
注：ポート番号のマッピングに加えて、PPTPサーバーはGREもカプセル化します。1対1の変換でない場合は問題が発生するため、解決策は上記と同じです。内部のPPTPを監視するだけです。
プロジェクトの一般的な問題：パブリックIPまたはドメイン名を使用して内部サーバーにアクセスする方法。
注：作業中は、サーバーにアクセスして外部サービスを提供する必要があることがよくあります。この場合、お客様は、内部ネットワーク用と外部ネットワーク用の2つのIPを覚えています。これは非常に不便であり、また、非常に不便です。IT技術を理解している人にとっては現実的ではありません。したがって、外部IPまたはドメイン名を介して直接アクセスすることを望んでいます。
デフォルトでは、イントラネットアドレスへのアクセスに問題はありません。
解決策[ドメイン内NAT]
1.アドレスプールを定義します
[USG-GW] nat address-group 5 200.1.1.1 200.1.1.1
2.定義されたドメイン内のNAT
[USG-GW] nat-policyゾーンの信頼
注：アドレスプールのアドレスは任意に定義して、ドメイン内NATで呼び出すことができます。正常であれば、ここにある可能性があり、正常にアクセスできますが、この環境では機能しません。
3.デュアルISP +ポリシールーティングの場合は、特別な注意を払う必要があります。
（1）問題：デュアルISPがゾーンにバインドされている
説明：上記の2つの構成は、ゾーンにバインドされていない構成、つまり、入力時に対応するゾーンパラメータが追加されない構成にのみ適しています。追加されない場合は、次のことができます。追加すると、ゾーンのパケット変換のみが処理され、以前に定義されたものが出力ISPにバインドされるため、2つのISPからのトラフィックのみを変換できますが、内部トラフィックを正常に変換できません。これは失敗につながります。
解決策：リバースなし
2つのバインディングトラストゾーンが追加され、トラストからの変換を処理できるようになりました。これは、実際にはドメイン内での直接変換です。ここではWWWのみを示していますが、FTPは示していません。no-reverseパラメーターを同じゾーンに追加する必要があることに注意してください。そうしないと、構成ができません。
4.ポリシールーティング
の影響の分析：通常、上記の3つの構成で問題を確実に解決できる場合。ただし、この環境では、NAT変換よりも優先されるポリシールーティングも展開しました。ポリシールーティングで指定されたネクストホップに従って送信されるため、アクセスは正常に変換されますが、ポリシールーティングによって渡されたネクストホップはサーバーではなくISPに失われます。
解決：
1、定义新的ACL
[USG-GW] acl番号3001
[USG-GW-acl-adv-3001] rule deny ip source 192.168.0.0 0.0.255.255 destination 192.168.88.251 0
[USG-GW-acl-adv-3001 ] rule permit ip source 192.168.19.0 0.0.0.255
[USG-GW-acl-adv-3001] rule permit ip source 192.16.21.0 0.0.0.255
[USG-GW] acl番号3002
[USG-GW-acl-adv-3002] rule deny ip source 192.168.0.0 0.0.255.255 destination 192.168.88.251 0
[USG-GW-acl-adv-3002] rule permit ip source 192.168 .20.0 0.0.0.255
説明：ACLが標準から拡張に変更されました。最初に拒否が削除されていることがわかります。192.168.0.0がサーバーにアクセスすると、変換が行われます。通常は、3層スイッチを介して直接変換する必要があります。 、ファイアウォールなし。ただし、ドメイン内NATを実行する場合、実際にはファイアウォールのインバウンドインターフェイスで変換を実行しますが、ポリシールーティングはインバウンドインターフェイスで呼び出されます。前の一致はISPに直接渡されます。これはパケットはサーバーに送信されたいのですが、ポリシールーティングが存在するため、強制的にISPに送信されるため、ここでの拒否は、次のように正常に転送できるようにすることです。ポリシールーティングによって制御されないルーティングテーブル。
2.ポリシールーティングの変更[変更されたACLの呼び出し]
3.インバウンドインターフェイスに適用します（デモにはありません）
4.FTPに関する注意点。
以前のNATServer in Trustの定義に加えて、アプリケーション層モニタリングを呼び出す必要があります。以前はドメイン間で変換されていたため、ALG関数はドメイン間で呼び出されましたが、今回はドメイン内変換であるため、再度監視する必要があります。
[USG-GW]ファイアウォールゾーンの信頼
[USG-GW-zone-trust] ftpの検出
結果テスト
IPアドレスを介して正常にアクセスできることがわかります。もちろん、ドメイン名を介してアクセスすることもできます。ここでは、テストする環境を設定していません。
まとめ[戦略、NAT、デュアルISP展開]
戦略とNATデュアルISPの状況が現れ、考慮する必要のある多くの要因があることがわかります。たとえば、戦略では要件を考慮する必要があり、展開はNAT、時間戦略、および効果を達成するための他の要因。ソースNATに注意を払うことは何もありません。ただし、NATサーバーに注意を払うべき点がいくつかあります。同じゾーンの場合は、no-resverパラメーターを追加する必要があります。異なるゾーンでは必要ありません。デュアルISPが存在する場合は、ルーティングスイッチング、検出メカニズム、およびポリシールーティングの展開を考慮する必要があります。ここでは、要件が変更されるとすぐに標準ACLが表示されるため、拡張ACLを使用することを強くお勧めします。どうしようもない。拡張はよりよく一致することができます。最後に、展開でパブリックIPまたはドメイン名を介して会社の内部サーバーにアクセスする必要がある場合は、ドメイン内NATを展開する必要があります。ただし、ゾーンをポリシールーティングにバインドする場合は、十分に注意する必要があります。最後はNATのALG機能です。マルチチャネルプロトコルの場合、アプリケーション層監視機能をオンにする必要があります。オンにしないと、NATを認識できません。FTP、PPTP、QQなどの一般的なものを使用できます。アプリケーションが正しく機能していない場合は、ALG関数を追加できます。
この記事は最初に公開アカウントで公開されました：Network Road Blog