TCP 클라이언트는 핸드 셰이 킹 중에 ACK를 보내지 않습니다.

debugcn 에 게시 Dev

user1411817

내 테스트 환경

고객

IP 192.168.0.2/24
게이트웨이 192.168.0.1

섬기는 사람

IP 192.168.0.1/24
포트 80에서 실행되는 http 서비스

웹 페이지를 서버에서 호스팅하려고하면 모든 것이 잘됩니다.

그런 다음 서버에서 netfilter를 사용하여 커널 모듈을 작성합니다.이 모듈은 원본 대상 IP가 192.168.1.1이면 대상 IP를 192.168.0.1로 변경하고 원본 원본 IP가 192.168.0.1이면 원본 IP를 192.168.1.1로 변경합니다. 클라이언트에 대해 서버를 192.168.1.1로 가장하고 있다는 것을 이해할 수 있다고 생각합니다. (IP 헤더 체크섬과 TCP 체크섬이 제대로 변경되었습니다)

클라이언트에서 웹 브라우저 (chrome, firefox ...)를 사용하여 192.168.1.1을 방문하고 클라이언트에서 패킷을 캡처하면 결과는 다음과 같습니다.

192.168.0.2:someport_1 -> 192.168.1.1:80 [SYN]
192.168.1.1:80 -> 192.168.0.2:someport_1 [SYN, ACK]
192.168.0.2:someport_2 -> 192.168.1.1:80 [SYN]
192.168.1.1:80 -> 192.168.0.2:someport_2 [SYN, ACK]
192.168.0.2:someport_3 -> 192.168.1.1:80 [SYN]
192.168.1.1:80 -> 192.168.0.2:someport_3 [SYN, ACK]

클라이언트가 TCP 핸드 셰이 킹의 마지막 ACK를 보내지 않는 이유를 모르겠습니다. 아이디어가 있습니까?

편집 1 :

이제 wireshark는 볼 수 있지만 브라우저는 서버에서 [SYN, ACK] 패킷을받지 못했다고 생각합니다. 그래서 아마도 OS (Windows7)가 서버에서 [SYN, ACK] 패킷을 떨어 뜨 렸기 때문일 것입니다. 이제 Windows가 올바른 [SYN, ACK] 패킷을 삭제하는 이유는 무엇입니까?

user1411817

세 가지 실수를했습니다.

첫 번째는 skb가 비선형 일 수 있으므로 csum_partial ()에서 가져온 체크섬이 올바르지 않게됩니다.

두 번째는 체크섬을 얻기 위해 csum_tcpudp_magic ()을 사용하지만 skb-> ip_summed 를 변경하는 것을 잊었 기 때문에 NIC는 체크섬을 다시 계산하기 위해 tcp 의사 헤더의 부분 체크섬으로 올바른 체크섬을 사용하여 체크섬이 잘못되었습니다. 패킷.

세 번째 실수는 내 wireshark가 tcp 체크섬을 무시하도록 설정되어 있고 항상 잘못된 체크섬이있는 패킷을 좋은 것으로 표시하는 반면 tcpdump는 잘못된 체크섬을 알려준다는 것입니다.

이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.

침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제

에서 수정2021-05-30

몇 마디 만하겠습니다

0리뷰

로그인참여 후 검토

Related 관련 기사

기사