#blognavi
#blognavi
TFTPの通信開始時、クライアントのランダムポートからサーバのUDP69番ポート宛に
「Write Request」パケットを送出し、その後サーバのランダムポートからクライア
ント宛に「Acknowledgement」パケットが送出されます。
「Write Request」パケットを送出し、その後サーバのランダムポートからクライア
ント宛に「Acknowledgement」パケットが送出されます。
こんなかんじ。
Client Server
| |
| UDP [Write Request] |
1233 |------------------------>| 69
| UDP [Acknowledgement:0] |
1233 |<------------------------| 2048
| UDP [Data Packet:1] |
1233 |------------------------>| 2048
| UDP [Acknowledgement:1] |
1233 |<------------------------| 2048
| UDP [Data Packet:2] |
1233 |------------------------>| 2048
| UDP [Acknowledgement:2] |
1233 |<------------------------| 2048
| : |
| : |
※1233や2048は都度ランダムに決定される。
Firewall越しのTFTP通信の場合、[Write Request]に対する[Acknowledgement]の
送信元ポートが69番以外のため、ARルータなどのFirewallはいきなりUDP通信で通信が来たと判断し、Firewallで破棄してしまい、結果TFTPクライアントに届きません。
そのため、クライアントは次のデータパケットを投げることができず、[Write Request]パケットを投げ続けることになります。
送信元ポートが69番以外のため、ARルータなどのFirewallはいきなりUDP通信で通信が来たと判断し、Firewallで破棄してしまい、結果TFTPクライアントに届きません。
そのため、クライアントは次のデータパケットを投げることができず、[Write Request]パケットを投げ続けることになります。
以上のことから、FirewallNAT越しのTFTP通信は不可能という形になります。
プロトコル全透過のスタティックNATでも設定すればいけるかもしれませんが、信頼性の無いUDP通信という特性上、無理矢理インターネット越しにTFTPでファイル送信は避けたほうが無難だと思います。
カテゴリ: [null] - &trackback() - 2006年03月20日 17:30:32
#blognavi