このドキュメントでは、さまざまなタイプのネットワーク アドレス変換(NAT)について説明し、各 NAT タイプをそのタイプをサポートする関連の ONS 15454 ソフトウェア バージョンにマップしています。
次の項目に関する知識があることが推奨されます。
Cisco ONS 15454
CTC
NAT
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
Cisco ONS 15454 のすべてのバージョン
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
現場では多くの場合、さまざまな NAT が使用されていますが、適切に機能しません。ほとんどは、その症状から特定できます。問題のほとんどは、ネットワーク要素(NE)が Cisco Transport Controller(CTC)ワークステーションへの接続を開始できないことに起因します。
CTC で特定の NAT 構成がサポートされていない場合に、CTC はノードとの接続のドロップと再接続を特定の間隔で断続的に繰り返します。新しいバージョンでは、CTC はビューからドロップせずに接続解除から回復できます。これらのバージョンでは、CTC を使用したノードとの通信中にこの問題に気付くことがあります。
この症状は、アクセス リストによってセキュリティが制御される外部ファイアウォールの設定が誤っていることが原因で発生することもあります。アクセス リストでは、NE が定義されている IP アドレス/ポートとの間で特定の接続を開始できず、CTC ワークステーションに戻ります。頻繁な接続解除は、外部ファイアウォールのタイムアウト設定が短すぎることが原因でも発生します。
ONS 15454 で使用できるファイアウォール アクセス リストの例については、『Cisco ONS 15454 リファレンス マニュアル リリース 5.0』の「外部ファイアウォール」の項を参照してください。
NAT を使用すると、ルータなどの 1 つのデバイスがインターネットとローカル ネットワーク間のエージェントとして動作します。ここでは、NAT のさまざまなタイプについて説明します。
詳細は、『RFC 2663 - IPネットワークアドレス変換の用語と考慮事項』を参照してください 。
従来型 NAT では、プライベート ネットワーク内のホストが外部ネットワーク内のホストに透過的にアクセスできます。従来型 NAT は、プライベート ネットワークからのアウトバウンド セッションを開始します。
ここでは、従来型 NAT の 2 つのバリエーションについて簡単に説明します。
基本的な NAT:基本的な NAT は、外部アドレス ブロックを確保します。基本的な NAT では、ホストが外部ドメインとのセッションを開始するときにプライベート ドメインでホストのアドレスを変換するために、これらの外部アドレスを使用します。
Network Address Port Translation(NAPT):NAPT では変換の概念がさらに拡張されました。NAPT は、トランスポート識別子(TCP および UDP ポート番号、ICMP クエリ識別子など)を変換します。このような変換では、多数のプライベート ホストのトランスポート識別子が、1 つの外部アドレスのトランスポート識別子に多重化されます。
注:NAPTはポートアドレス変換(PAT)とも呼ばれます。
外部ネットワーク上のデバイスが、内部のデバイスとのトランザクションを開始します。この開始を許可するため、基本的な NAT が拡張され、高度な機能が組み込まれました。この機能拡張は一般に双方向 NAT と呼ばれますが、2 方向 NAT またはインバウンド NAT と呼ばれることもあります。双方向 NAT を使用すると、パブリック ネットワークおよびプライベート ネットワーク内のホストからセッションを開始できます。プライベート ネットワーク アドレスは、いずれかの方向で接続を確率すると、グローバルに一意のアドレスに静的または動的にバインディングされます。
インバウンド トランザクションで NAT を実行することは、アウトバウンド NAT よりも困難です。この原因は、外部デバイスがパブリックであるため、内部ネットワークが外部デバイスの IP アドレスを認識していることにあります。ただし外部ネットワークは内部ネットワークのプライベート アドレスを認識していません。外部ネットワークがプライベート ネットワークの IP アドレスを認識している場合でも、これらの IP アドレスを、外部から開始する IP データグラムのターゲットとして指定することはできません。これは、これらの IP アドレスがルーティング可能ではないためです。
アドレスが見えないという問題を解決するには、次のいずれかの方法を使用できます。
スタティック マッピング
TCP/IP ドメイン ネーム システム(DNS)
注:このドキュメントでは、双方向NATは基本的なNATを意味しますが、基本的なNATは双方向NATを意味しません。
Twice NAT は NAT のバリエーションです。データグラムがアドレス領域を通過するときに、Twice NAT は送信元アドレスと宛先アドレスの両方を変更します。この概念は、1 つのアドレス(送信元または宛先のいずれか)だけを変換する従来型 NAT や双方向 NAT とは対照的です。
次の表に、ONS 15454 と NAT の互換性を示します。
NAT のタイプ | CTC が認識する内容 | ゲートウェイ ネットワーク エレメント(GNE)が認識する内容 | サポートされる CTC バージョン |
---|---|---|---|
基本的な NAT | GNE IP | 変換後の IP | リリース 3.3 |
NAPT | GNE IP | 変換後の IP | リリース 4.0 |
双方向 NAT | 変換後の IP | CTC IP | リリース 5.0 |
Twice NAT | 変換後の IP | 変換後の IP | リリース 5.0 |
NE と CTC の間で通信の問題が発生する場合は、fhDebug コマンドの出力に次のエラー メッセージが記録されています。
OCT 27 18:35:37.09 UTC ERROR ObjectChange.cc:432 tEventMgr CORBA::NO_IMPLEMENT/0x3d0004 updating [192.168.1.100:EventReceiver]. Marking c OCT 27 18:36:17.09 UTC DEBUG AlarmImpl.cc:353 tEventMgr Removing corba client [192.168.1.100:EventReceiver] from auton msg list
このエラーを引き起こす原因はさまざまです。ただし、エラーが予測可能な定期的な間隔(~ 2 分または ~ 4 分)で発生する場合は、CTC でサポートされない NAT タイプが使用されているか、または必要なポート許可がないファイアウォールが原因である可能性があります。
172.16.1.100 が CTC ワークステーションの IP アドレスであり、10.1.1.1 が NAT アドレスであることがわかります(図 1 を参照)。
図 1:トポロジ
inetstatShow コマンドの出力の一部を次に示します。
-> inetstatShow Active Internet connections (including servers) PCB Typ Rx-Q Tx-Q Local Address Foreign Address (state) ------- --- ---- ---- ----------------- --------------- ------- 2145984 TCP 0 0 10.10.10.10:1052 10.1.1.1:1029 SYN_SENT 21457f8 TCP 0 0 10.10.10.10:80 10.1.1.1:1246 TIME_WAIT 2145900 TCP 0 0 10.10.10.10:57790 10.1.1.1:1245 ESTABLISHED --- ISP assigned address 21453d8 TCP 0 0 10.10.10.10:80 10.1.1.1:1244 TIME_WAIT 2144f34 TCP 0 0 10.10.10.10:80 10.1.1.1:1238 TIME_WAIT 2144eb0 TCP 0 0 10.10.10.10:1080 10.1.1.1:1224 ESTABLISHED --- ISP assigned address
この出力には、このアドレスの証拠は示されていません。この出力には、ISP が使用するパブリック アドレスが示されており、これが従来型 NAT のシナリオの証拠となります。
双方向 NAT と Twice NAT を特定するには、CTC ワークステーションと同じネットワーク セグメントからのスニファ トレースが必要です。理想的には、CTC ワークステーションで実行されるスニファが最適です。