TFTP は古いプロトコルですが、今でもインフラ運用では出てきます。PXE Boot、ネットワーク機器の設定バックアップ、ファームウェア転送、初期構築用の小さなファイル配布などで使われます。
TFTP を扱う時に気を付けたいのは、「UDP 69 番を開ければ終わり」と考えないことです。TFTP は最初の要求に UDP 69 番を使いますが、実際の転送は別の UDP ポートで行われます。
そのため、ファイアウォールや NAT を挟む環境では、制御の入口と実際のデータ転送を分けて理解する必要があります。
TFTP は単純だが、通信の流れは単純ではない
TFTP (Trivial File Transfer Protocol) は、FTP のような認証や複雑な制御を持たない、非常に単純なファイル転送プロトコルです。UDP を使い、主に小さなファイルの読み書きに使われます。
ただし、単純なプロトコルだからといって、ファイアウォール設計まで単純になるわけではありません。TFTP は、最初の要求と、その後の転送で見るべき通信が変わります。
| 段階 | 通信 | 意味 |
|---|---|---|
| 要求 | クライアント → サーバー UDP 69 | 読み込み / 書き込み要求を送る |
| 転送 | サーバー側の別 UDP ポート ↔ クライアント | データブロックと ACK をやり取りする |
| 完了 | 最後のデータブロックと ACK | 転送終了 |
つまり、UDP 69 番は入口です。実際の転送そのものを 69 番だけで見ようとすると、通信を誤解します。
UDP 69 番だけでは説明できない
TFTP サーバーは UDP 69 番で要求を受けます。しかし、転送が始まると、サーバーは別の UDP ポートを使ってクライアントとやり取りします。
このため、ステートフルファイアウォールであれば関連通信として追跡できる場合がありますが、単純な ACL や静的なフィルタでは、戻り通信や転送用ポートをどう扱うかが問題になります。
特に、TFTP サーバーとクライアントの間に NAT や厳格なファイアウォールがある場合、UDP 69 番だけを許可しても転送が途中で失敗することがあります。
PXE Boot では DHCP と TFTP を分けて見る
PXE Boot では、TFTP だけを見ても足りません。クライアントは DHCP で IP アドレスを取得し、次に起動ファイルの場所を知り、TFTP でブートローダーや設定ファイルを取得します。
| 要素 | 役割 |
|---|---|
| DHCP | クライアントへ IP アドレスや起動情報を渡す |
| next-server / bootfile | TFTP サーバーと起動ファイルを指定する |
| TFTP | ブートローダーや設定ファイルを配布する |
| HTTP / NFS など | 環境によっては後続の大きなファイル配布に使う |
PXE Boot が失敗した時に、TFTP だけを疑うと切り分けを誤ります。DHCP で正しい情報が渡っているのか、TFTP サーバーへ到達できるのか、ファイル名が合っているのか、権限やパスが合っているのかを分けて確認する必要があります。
ネットワーク機器の設定バックアップで使う場合
TFTP は、ネットワーク機器の設定バックアップやファームウェア転送でも使われます。Cisco、VyOS、古い L2 / L3 スイッチなどでは、TFTP サーバーへ設定を送る、または TFTP サーバーからファイルを取得する運用があります。
この場合に重要なのは、どちらがクライアントで、どちらがサーバーなのかです。ネットワーク機器が TFTP クライアントとして動き、管理用サーバーが TFTP サーバーになる構成が多いです。
管理ネットワーク内で閉じて使うならまだ扱いやすいですが、セグメントをまたぐ場合やファイアウォール越しに使う場合は、通信方向と戻り通信を明確にする必要があります。
ファイアウォール設計で見るべきこと
TFTP をファイアウォール越しに通す場合は、次の観点を確認します。
- TFTP サーバーはどこにあるのか
- クライアントはどのセグメントにいるのか
- UDP 69 番への要求をどこから許可するのか
- 転送用の戻り通信をステートフルに追跡できるのか
- NAT を挟むのか
- TFTP helper や conntrack module が必要なのか
- 管理ネットワーク内に閉じられないか
TFTP は認証を持たないため、広く開けるべきプロトコルではありません。特に、インターネット側や利用者セグメントから自由に使えるようにする設計は避けるべきです。
基本的には、管理用ネットワーク、PXE 用ネットワーク、特定の機器群など、用途と通信元を絞って許可する方が安全です。
NAT と TFTP helper の問題
TFTP は UDP であり、さらに転送時にポートが変わります。そのため、NAT を挟む環境では扱いが難しくなることがあります。
Linux の conntrack には TFTP を補助する helper があり、TFTP の関連通信を追跡できる場合があります。ただし、環境やディストリビューション、ファイアウォール設定によって前提が変わるため、helper が有効であることを前提にしすぎるのは危険です。
lsmod | grep tftp
modprobe nf_conntrack_tftp必要に応じて、conntrack helper の有無やファイアウォールの関連通信許可を確認します。ただし、これは環境依存です。まずは TFTP をどの範囲で使うのかを設計し、できるだけ NAT をまたがせない方が運用は分かりやすくなります。
障害切り分けでは通信を分解する
TFTP が失敗する時は、単に「TFTP が動かない」と見ない方がよいです。次のように分けて確認します。
| 確認点 | 見ること |
|---|---|
| 名前解決 / IP 到達性 | TFTP サーバーへ到達できるか |
| UDP 69 | 最初の要求が届いているか |
| 転送用ポート | データ転送の戻り通信が通っているか |
| ファイルパス | 要求しているファイル名が存在するか |
| 権限 | TFTP サーバーがファイルを読めるか / 書けるか |
| ログ | サーバー側に要求やエラーが残っているか |
| PXE の場合 | DHCP の next-server / bootfile が正しいか |
特に PXE Boot では、DHCP の設定ミス、TFTP の到達性、ファイルパスの誤りが似たような失敗として見えることがあります。影響範囲と通信段階を分けて確認することが重要です。
まとめ
TFTP は単純なファイル転送プロトコルですが、ファイアウォール設計では単純に扱えません。
UDP 69 番は要求の入口であり、実際の転送では別の UDP ポートが使われます。PXE Boot では DHCP と TFTP の役割を分けて見る必要があります。ネットワーク機器の設定バックアップでは、どちらがクライアントで、どちらがサーバーなのかを明確にする必要があります。
TFTP は認証を持たないため、広く開けるものではありません。用途、通信元、ネットワーク範囲を絞り、管理用の通信として扱うべきです。
TFTP の設計で重要なのは、古いプロトコルかどうかではありません。制御の入口、データ転送、DHCP との関係、ファイアウォールの責務を分けて理解することです。
