しかし、LSNを導入するにあたって、解決しなければいけない問題点も多々あります。
現在議論指摘されている、代表的な問題点にはこのようなものがあります。
・ペイロード部分にIPアドレスが含まれている場合には、通信に不具合が発生する可能性がある。
・Webサイト側では、アドレス送信元が全てLSNのIPになってしまい、アクセスログから、送信元を割り出すのが、時間がかかる。
・加入者に対して、同時使用ポート数を制限するため、Webページの閲覧に支障が出る可能性がある。
・IPv4アドレス延命を助長させるため、IPv6への移行の足かせになる。
これらの、問題点を抱えていたとしても、3年以内に枯渇すると言われている、IPv4アドレス枯渇対策の延命措置として、なくてはならないものだと考えられています。
今回は、上記に挙げた問題点以外で、私が懸念している内容を記載します。
最も難しいのは性能監視
「性能監視の何が問題になるのか?」と考えられる方も多いと思います。しかし、ネットワークを設計する上で性能監視が出来なければ以下の問題が発生します。
事象
・機器の性能不足による、パケットドロップ
結果
・ネットワークの品質低下を招く
あたりまえのことかもしれませんね。あたりまえのことかもしれませんが、正しく性能監視と、その定量的な測定を行う事で、増設計画を行う事はネットワークを運用していくうえで、非常に大切です。
では、もし、性能監視が正しく行えないとしたら、みなさんどうお考えになるでしょうか?
LSNで性能監視が行えない理由
・ソフトウェア処理が発生する
LSNに限らず、NATを実行することは、それほど簡単ではありません。最低でもこれだけの処理は発生します。
1) パケットを受信
2) 送信元IP、送信元ポートアドレス、送信先IP、送信先IPアドレスのチェック
3) 利用可能リソースの確認(IPアドレスプール、ポート番号)
4) xLate(アドレス変換テーブル)の作成
5) アドレス変換実施
6) ルーティングテーブル参照
7) パケット送信
ルータ、スイッチであれば、上記の1)、2)、6)、7)を実施するだけです。しかも、2)についてはポート番号は参照しません。単純にIPの宛先を見て、後はルーティングテーブルに従ってパケットを送信するだけです。IPヘッダに基づくパケット転送はアプリケーションに依存しませんから定型処理ですから、ハードウェア処理させる事が可能です。ですから最近の高級な、ルータ、スイッチは物理インターフェースの仕様で規定されたPPSをワイヤレートで転送する事が可能です。
しかし、NATを行う装置は上記のように複雑な処理を行います。ですが、実際にはこれより、更に複雑な処理が行われます。
■NAT装置での、TCPパケットの処理
全てのNAT装置がこのような処理を行っているとは限りませんが、実際にTCPパケットがどのようにNAT処理されるかを考察してみましょう。
TCPの通信は、大きく三つの段階にわかれます。
1) コネクション確立シーケンス
- 3WAYハンドシェイク
2) データ転送シーケンス
3) コネクション終了シーケンス
- FINによるClose処理
次に、上述した、TCPのセッション開始・終了までのプロセスがどのように、NAT装置で処理されるかを当てはめてみましょう。
1) コネクション確立シーケンス
1-1 xLateテーブル作成
1-2 xLateの内容がFIBに転記される。
2) データ転送シーケンス
2-1 FIBを参照して、ハードウェアによるパケット転送
3) コネクション終了シーケンス
3-1 FIB、xLateテーブルから該当セッションを削除
NAT装置はコネクション確立シーケンス時に、xLateテーブルを作成し、データ転送シーケンス中はxLateテーブルの内容に従い、パケットをハードウェア処理で高速に転送します。そして、コネクション終了シーケンス時に、xLateテーブルからセッション情報を削除します。
このような処理が発生するわけですが、これだけではすみません。
悪意のある第三者がTCPのSYNパケットだけを大量に投げ続けたらどうなるでしょうか?
答えは、何も対策されていなければ、NAT装置のリソースを全て奪われてしまい、DDoSの対象となってしまいます。
ですから、一般的なNAT装置であれば、こういった攻撃に対処するために、セキュリティ対策が実施されています。前述した例のケースの場合には、一定時間に大量にSYNを受信したらアタックとみなして、破棄するといったことや、一定時間内にTCPコネクションが確立出来なかった通信は、破棄する等の仕組みを設けています。
こういった複雑な処理は、ソフトウェア処理になります。
TCPのコネクションが発生する度に、こういったソフトウェア処理が発生することになります。
※あくまでも、経験則であり、全ての機器がこういった処理を行っているとは限りません。お使いになられているメーカに、どういった処理を行っているかをご確認下さい。
■NAT装置での、UDPパケットの処理
先ほどはTCPを処理する時の動作を紹介しました。では、UDPではどうでしょうか?
UDPはTCPと違って、コネクションの概念がありません。では、xLateテーブルはUDPでは作成されないのでしょうか?
そんなことは、ありません。
xLateテーブルが無い状態でNAPTを行えば、バラバラの送信元IP、送信元ポートからパケットを受信したノードは、不正なパケットと判断して、アプリケーション層でパケットが破棄されることでしょう。
UDPには、本来コネクションは存在しませんが、NAT装置では、以下の組み合わせで擬似コネクションを作成します。
送信元IP、送信元ポート & 送信先IP、送信先ポート
そして、通常一定時間通信が継続している間は、コネクション継続中と処理され、通信が無くなればコネクションはxLateテーブルから削除されます。
UDPの場合には、送信元から発生したパケットと、それに対する応答で1コネクションが確立します。
DNSであれば、Queryに対する、Responseと考えて頂ければわかりやすいでしょう。
そして、UDPの擬似コネクションを作成する処理も、ソフトウェア処理となります。
・ソフトウェア処理が発生すると何故、性能監視が行えないのか?
---次回へ続く---
投稿
0 コメント:
コメントを投稿