상당히 간단한 질문입니다... 저는 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를 실행 중입니다.
답변1
당신은 볼 수 있습니다nfstrace 도구깃허브에서:(https://github.com/epam/nfstrace). 캡처된 모든 NFSv3/NFSv4 프로세스를 추적합니다.
답변2
좋아, 그래서 "해결 방법"을 찾은 것 같습니다. NFSv3을 사용하여 파일 이름을 얻을 수는 없지만 inode는 얻을 수 있습니다.
와이어샤크를 이용하여,
편집 -> 기본 설정 -> 프로토콜 -> NFS -> 모든 상자를 선택하고 "nfs 핸들을 다음으로 디코딩: KNFSD_LE"로 설정합니다.
구하다. 캡처 및 필터링은 이제 NFS 프로토콜을 통해 수행됩니다.
패킷 검색GETATTR Reply (Call in #) Regular file mode: ???.
이 zip 파일을 열고 다음 내용을 확장합니다.
Network File System -> obj_attributes
값 확인파일 번호, 이는 파일의 inode 번호가 됩니다.
서버에서 nfs 공유로 이동하고
find . -inum inode
NFSv4를 사용하면 파일 이름으로 호출을 직접 볼 수 있습니다.
답변3
RedHat의 NFS v3 구현은 대부분의 작업에 이름이 아닌 파일 핸들을 사용합니다. Wireshark의 핸들이 표시되지 않으면 찾을 때까지 패킷의 다양한 부분을 계속 확장하세요. 일부 패킷에는 대상 개체와 해당 상위 디렉터리에 대한 핸들이 포함되어 있으므로 주의 깊게 살펴보세요. NFS 호출에서 Wireshark의 요약 "정보" 줄은 일반적으로 핸들의 축소된 버전인 해시 값을 표시합니다. 문제는 파일 핸들이 "다른 정보"나 문제의 컴퓨터에 대한 액세스(예: 다른 사람의 패킷을 분석하는 경우) 없이는 그다지 유용한 정보가 아니라는 것입니다.
핸들이나 해당 해시에 대한 이전 패킷 발생을 검색하고 동일한 파일 핸들이 존재하는 위치를 찾아서 파일 이름과 연결할 수 있기를 바랍니다. 예를 들어, 조회는 파일 핸들이 포함된 응답을 생성합니다. 또는 생성 작업에 대한 응답으로 방금 생성된 개체에 대한 핸들이 표시됩니다. 또는 "readdirplus" 시퀀스가 있고 패킷이 잘리지 않은 경우 거기에서 정보를 얻을 수 있습니다.
또는 물론 많은 경우 nfs 마운트가 한동안 사용되어 클라이언트가 이름과 관련된 핸들을 "학습"하게 만든 원래 호출이 오래 전에 사라졌을 수도 있습니다. 따라서 문제 재현 및 패킷 수집 단계를 제어하고 계획할 수 있다면 nfs 마운트 없이 시작하는 것이 도움이 될 수 있습니다. 그런 다음 tcpdump를 시작하십시오. 그런 다음 마운트하십시오. 그런 다음 nfs 문제를 재현하십시오. 이렇게 하면 모든 파일 핸들을 파일 이름과 연결하는 패킷을 캡처할 수 있습니다.