web-dev-qa-db-ja.com

tcpdumpを使用してNFS RPCコンテンツを抽出する

かなり単純な質問... tcpdumpを実行して、サーバー/クライアント間のTCPパケットの内容を分析しようとしています。 "GETATTR" RPCが受信されているのがわかります。 、RPCが作成されているファイルを知りたいのですが、これはパケットコンテンツにあると想定しています。tcpdumpをASCIIとして出力すると、.

From server:
tcpdump -vvv -s 200 port 2049 
14:45:38.408949 IP (tos 0x0, ttl 64, id 58408, offset 0, flags [DF], proto TCP (6), length 296)
myserver.nfs > myclient.2469839164: reply ok 240 getattr NON 3 ids 0/3 sz 0

ここ と他のサイトは、ファイル名にマップできることを示しています。多分それはプラットフォームに依存していますか？私はtcpdumpに欠けている明白なオプションがないことを確認したいだけです。

RH5を実行しています-カーネル2.6.32-279.el6.x86_64

rhelnfstcptcpdump
3
Jmoney38

さて、私はなんとか「回避策」を見つけることができたと思います。 NFSv3を使用してファイル名を取得することはできませんが、iノードを取得することはできます。

Wiresharkを使用して、

[編集]-> [設定]-> [プロトコル]-> [NFS]に移動し、すべてのチェックボックスをオンにして、[nfsハンドルのデコード：KNFSD_LE]を設定します。

それを保存。次に、NFSプロトコルでキャプチャしてフィルタリングします。

パケットを検索GETATTR Reply (Call in #) Regular file mode: ???.

このパックを開き、以下を展開します。

Network File System -> obj_attributes

チェック値fileid、これはファイルのiノード番号になります。

サーバーでnfs共有に移動し、

find . -inum inode

NFSv4では、ファイル名を直接指定した呼び出しが表示されます。

2
BitsOfNix

Githubで nfstraceツール を確認できます：（ https://github.com/epam/nfstrace ）。キャプチャされたすべてのNFSv3/NFSv4プロシージャをトレースします。

3
Pavel K

RedHat（およびその他）のNFS v3実装では、名前の代わりに、ほとんどの操作で実際にファイルハンドルが使用されます。 Wiresharkでハンドルが表示されない場合は、見つかるまでパケットの一部を拡張してください。一部のパケットには、ターゲットオブジェクトとその親ディレクトリのハンドルが含まれるため、慎重に調べてください。 NFS CALLでは、wiresharkの要約「Info」行に、ハンドルの縮小バージョンであるハッシュが表示されることがよくあります。問題は、「他の情報」または問題のマシンへのアクセスがない場合（たとえば、他の誰かのパケットを分析している場合）、ファイルハンドルがあまり役立つ情報ではないことです。

ハンドルまたはハッシュの前に来たパケットを検索して、同じファイルハンドルがファイル名に関連付けられる方法で存在する場所が見つかることを願っています。たとえば、ルックアップの結果、ファイルのハンドルを含む応答が返されます。または、作成操作の応答で、作成されたばかりのオブジェクトのハンドルが表示されます。または、「readdirplus」シーケンスが存在し、パケットが切り捨てられなかった場合は、そこから情報を取得できる可能性があります。

もちろん、多くの場合、nfsマウントはしばらくの間使用されており、クライアントが名前に対応するハンドルを「学習」する原因となった元の呼び出しは、なくなっている可能性があります。したがって、問題の再現とパケット収集の手順を制御および計画できる場合は、nfsマウントが存在しない状態で開始すると役立ちます。次に、tcpdumpを開始します。次に、マウントを実行します。次に、nfs問題を再現します。このようにして、すべてのファイルハンドルをファイル名で接続するパケットを確実にキャプチャします。

0
Darcy