저는 많은 양의 TCP/IP 트래픽을 전송하는 장치를 사용해 왔습니다.
Python 프로그래밍 언어를 사용하여 Linux 시스템(Ubuntu 22.04.2 LTS)에서 이러한 패킷을 캡처하려고 합니다.
그러나 대부분의 경우 전송된 패킷이 운영 체제에서 올바르게 수신되지 않습니다.
이러한 패킷 중 일부는 운영 체제에서 올바르게 재조립되지만 대부분은 그렇지 않습니다.
Wireshark의 내용을 명확하게 볼 수 있습니다.
다음은 예상치 못한 동작입니다.
내가 주로 보는 것은 조각난 IP 프로토콜 패킷이고, 이어서 TTL(조각화 시간 초과)이 초과된 것을 봅니다.
예상되는 동작은 다음과 같습니다.
모든 패킷을 캡처하기 위해 이 동작을 수정하는 방법(패킷 재조립 실패를 유발하는 조건 완화)이 있습니까?
Windows 10에서는 이런 문제가 발생한 적이 없습니다.
동일한 클라이언트 시스템에서 Ubuntu에서 로그아웃하고 Win10에 로그인하면 패킷이 삭제되지 않고 전송된 모든 청크가 재조립되어 적절한 포트로 전송됩니다. Linux에서는 패킷 손실에 영향을 미치는 일부 시스템 매개변수가 있는 것 같습니다.
아래에 Wireshark 캡처 파일을 첨부했습니다.
https://drive.google.com/file/d/1GFtlHnKF619HE02JfuSUQpIGqSxRt6Yf/view?usp=sharing
이것이 출력이다sudo sysctl -a | grep ipfrag
net.ipv4.ipfrag_high_thresh = 4194304
net.ipv4.ipfrag_low_thresh = 3145728
net.ipv4.ipfrag_max_dist = 64
net.ipv4.ipfrag_secret_interval = 0
net.ipv4.ipfrag_time = 30
또한 다음 작업을 시도했습니다(위 설정의 10배).
sudo sysctl -w net.ipv4.ipfrag_time=300
sudo sysctl -w net.ipv4.ipfrag_high_thresh=41943040
sudo sysctl -w net.ipv4.ipfrag_low_thresh=31457280
sudo sysctl -w net.ipv4.ipfrag_max_dist=640
아직도 운이 없습니다.
감사해요.
답변1
어떤 이유로 일부 부품이 누락되었습니다.
이는 재조립 문제가 아니며 시간 제한을 아무리 조정해도 문제가 해결되지 않습니다.
Wireshark(또는 모든 pcap 기반 도구)에서 볼 수 있는 것은 운영 체제 네트워크 스택으로 전달되기 전에 NIC에 들어오고 나가는 원시 트래픽입니다. 따라서 캡처에서 누락된 항목이 있을 때마다 이는 NIC가 해당 항목을 수신하지 못했다는 의미입니다(또는 단순히 하드웨어에 의해 삭제된 항목임).
첫 번째 스크린샷은 덤프에 하나 이상의 조각(오프셋 17760의 조각)이 누락되었음을 보여줍니다. 따라서 운영 체제는 조각이 도착할 가능성이 있는 경우(전송 중에 재정렬되었거나 하위 계층에서 재전송된 경우)를 잠시 기다리고, 조각이 도착하지 않으면 ICMP 리어셈블리 시간 초과 오류가 발생합니다.
기본 네트워크에 의해 패킷이 오랫동안 지연될 것으로 예상되는 타당한 이유가 없으면 시간 초과를 조작할 필요가 없습니다. 그 조각들은 단지 잃어버렸을 뿐이고 결코 나타나지 않으며, 더 오래 기다려도 도움이 되지 않습니다.
이것이 바로 신뢰할 수 없는 전송을 기반으로 하는 UDP의 현실입니다. 미디어에 심각한 손실이 있고 조각화가 많이 발생하면 많은 패킷을 재조립할 수 없습니다.
먼저 패킷 손실의 원인이 무엇인지 조사해야 합니다. NIC의 오류 카운터를 확인하는 것이 좋은 첫 번째 단계일 수 있습니다. 동일한 하드웨어를 사용하는 다른 운영 체제에서 이 문제가 발생하지 않으면 네트워크 카드가 다르게 구성되었을 수 있습니다(예: 오프로딩이 비활성화되어 CPU가 트래픽을 처리할 수 없게 되거나 네트워크 카드가 한 운영 체제의 고속 이더넷과 다른 운영 체제의 강제 기가비트의 자동 협상과 같은 다양한 데이터 속도).