2014-01-22 4 views
1

Windows 컴퓨터에서 2 개의 네트워크 인터페이스간에 NAT를 수행하는 응용 프로그램을 개발 중이며 진행 상황을 이해하는 데 약간의 문제가 있습니다.NAT 구현

시스템 2 네트워크 인터페이스가있다 :

  • 물리적 네트워크 인터페이스 (00 : 0 C 29 : BC : 4C : 192.168.133.130 11)의 게이트웨이로서 0시 50분 56초 사용 eb : f5 : 15 - 192.168.133.2 (VMware에서 운영)
  • 게이트웨이로 사용하는 응용 프로그램에서 사용하는 가상 TAP 네트워크 인터페이스 (00 : ff : 15 : 08 : ac : 26 192.168.200.100) : 03 : 03 : 03 : 03 - 192.168.200.1 (내 응용 프로그램에 의해 운영) 내 응용 프로그램이 무엇

:

  • 응답은
  • 가 무엇을 보여주기 위해 탭 인터페이스와 실제 일 사이에 ICMP, UDP와 TCP에 대한

을 일대일 NAT를 수행 192.168.200.1 요청 (가상 게이트웨이) ARP하기 계속 나는 (그것은 또한 Wireshark로 열릴 수있다)에 의해 붙잡은 패킷과 함께 .cap file을 붙였다. 이 테스트는 google.com:80과 TCP 연결을 설정하는 것입니다. 먼저 인터넷 연결이 있음을 증명하기 위해 실제 인터페이스를 통해 직접 연결이 설정된 다음 TAP 인터페이스를 통해 연결이 설정되어 NAT를 테스트합니다. 위에서 아래

패킷 분석 :

  • 1 - TCP SYN-ACK 물리적
  • 경우 통해 google.com로부터 수신 - TCP SYN 직접
  • 2 물리적 인터페이스를 통해 전송 google.com
  • 3 - TCP ACK 물리적 경우
  • google.com 통해 전송
  • 4 - 연결
,369를 닫을 경우 TCP RST-ACK 물리적 통해 전송 google.com

좋습니다, 우리는 인터넷에 연결되어 있습니다. 지금은 가상 라우터 내 응용 프로그램 (192.168.200.1)가 운영하는 기본 게이트웨이를 변경

  • 5 - Windows가 기본 게이트웨이는 192.168.200.1로 변경 통지 및
  • 를 192.168.200.1하는 ARP 요청을 전송 6 - 내 앱이 192.168.200.1이 03 : 03 : 03 : 03 : 03 : 03
  • 에 있다고 응답합니다. 7 - TCP SYN이 google.com으로 TAP 인터페이스 (192.168.200.100)를 통해 가상 라우터 (192.168. 200.1)
  • 8 - 내 앱이 패킷에 NAT를 수행합니다 (원본 및 대상 MAC 주소가 그에 따라 변경되고 IP 원본 주소가 192.168.133.130으로 변경됨). cal 인터페이스를 00 : 50 : 56 : eb : f5 : 15 (192.168.133.2)
  • 9 - 다시 무응답 - 내 앱 NAT 동일한 방식으로 수행하고, 물리
  • 11
  • 경우에 상기 패킷을 전송 - 응답이
  • 10 그래서 만약 제 TCP의 SYN가 TAP에 전송되고 수신되지 그래서 제 시도
  • 12 이루어진다 - 내 앱 동일한 방법으로 NAT를 수행

NAT 물리적 인터페이스를 통해 전송되는 패킷은, 첫 번째 테스트에서 송신되는 것과 거의 동일한되면 네트워크 토폴로지에서는 아무 것도 변경되지 않습니다. 두 번째 TCP 연결이 실패한 이유는 무엇입니까? 그것은 아무 의미가 없습니다.

프로그램에서 WinPcap을 사용하고 있습니다. 관심이 있다면 Here 코드입니다.

답변

1

캡쳐 된 파일을 검사했는데 TCP 레벨 및 MAC 계층 헤더 (SYN과 실패한 SYN 사이)에는 차이점이 없습니다. 성공한 SYN에서 IP 헤더 체크섬이 0임을 알 수 있습니다. 아마도 계산이 인터페이스 카드로 오프로드 되었기 때문일 것입니다. 실패한 SYN에서는 체크섬이 계산되고 Wireshark에 따라 정확합니다. 체크섬이 맞으면 문제가되지 않습니다. 그것이 IP 계층에서 볼 수있는 유일한 차이점입니다.

나는 중간에 누군가가 다음 메시지를 걸러 내고 있다고 말하고 싶습니다.

나에게 이상한 점은 앱이 스트림 인덱스 0의 소켓을 닫을 때 FIN 대신 RST를 보내는 이유입니다. 어쩌면 어떤 노드가 귀하의 IP 주소에서 RST 공격을 막으려 고 시도하고 있습니까? 소켓을 닫고 [FIN, ACK] 메시지를 보내는 방법이 있습니까? 두 번째 테스트를 실행하기 전에 더 많은 시간을 기다릴 수 있습니까?

다른 이상한 점은 두 번째 테스트에서 연결 192.168.200.100 (응용 프로그램 (03 : 03 : 03 : 03 : 03 : 03 : 03))과 "응용 프로그램"둘 다 동일한 소스 포트 49181을 사용한다는 것입니다. 이들은 두 개의 다른 기계이기 때문에 문제가되는 것처럼 보이지만 나는 아주 마지막 자원으로 거기에서 조사 할 것이다. 나는 그것이 문제라고 생각하지 않는다.

편집 :

당신은 내가 문제를 실현 세그먼트는 수정되지 않은 넘겨하는 TCP를 설명 후에는 TCP 체크섬을 다시 계산하지 않는 것입니다! 두 SYN 메시지 (프레임 7과 8)는 동일한 TCP 체크섬을가집니다. IP 주소가 변경되면 TCP 체크섬이 변경되어야합니다.

자세히 알아 보려면 매우 흥미로운 문제입니다.

+0

테스트 응용 프로그램은 Ws2_32 \ socket 및 Ws2_32 \ WinAPI 함수를 사용하여 TCP 연결을 설정합니다. 그 후 테스트 응용 프로그램이 닫히고 소켓은 죽고 Windows는 RST를 보냅니다. 그것은 문제가 아니지만 .. 물리적 인 if를 사용하여 2 회 연속 테스트를 실행할 수 있습니다. 이 포트는 일대일 NAT (현재는)이므로 포트가 변환되지 않으므로 IP 만 수정되고 TCP는 변경되지 않습니다. – Chris

+1

안녕하세요! 문제는 TCP 체크섬을 다시 계산하지 않는다는 것입니다. 두 SYN 메시지 (프레임 7과 8)는 동일한 TCP 체크섬을가집니다. IP 주소가 변경되면 TCP 체크섬이 변경되어야합니다. 내 대답을 편집 할게. – rodolk

+0

당신이 옳습니다! 나는 Wireshark에서 "TCP 체크섬 유효성 검사"를 사용했고 패킷 8에는 유효하지 않은 TCP 체크섬이 있습니다. 하지만 왜? TCP 패킷은 변경되지 않았으며 TCP 체크섬에는 TCP 헤더와 데이터 만 포함됩니다. TCP 체크섬에는 IP 헤더도 포함되어 있습니까? – Chris