tun 인터페이스에 주입된 IPv6 패킷은 IPv4 스택에 들어갑니다.

tun 인터페이스에 주입된 IPv6 패킷은 IPv4 스택에 들어갑니다.

tun 인터페이스와 커널의 IPv6 처리에 대해 질문이 있습니다.

내 네트워크의 최종 사용자에게 순수 IPv4 네트워크를 통해 IPv6을 제공하려고 합니다. (터널링 배경 이론만) 요약하면 모든 IPv6 패킷은 IPv4 패킷에 넣어 터널을 통해 전송되며, 나갈 때 이 IPv4 헤더가 제거되어 시스템으로 전달됩니다.

이 모든 것을 시뮬레이션하는 시나리오는 다음과 같습니다.

  • 두 장치 사이의 트래픽을 터널링하는 데 사용하는 IPv4 가상 인터페이스가 2개 있는 머신이 한 대만 있습니다. 우리는 그것들을 "if4a"와 "if4b"라고 부릅니다. 이러한 인터페이스는 관리 인터페이스의 하위 인터페이스입니다.
  • 또한 이 머신에는 최종 사용자 IPv6 주소를 마스크하는 데 사용되는 두 개의 IPv6 tun 인터페이스가 있습니다. 우리는 그것들을 "if6a"와 "if6b"라고 부릅니다. 각 tun 인터페이스에는 터널에 패킷을 쓰거나 터널에서 패킷을 읽기 전에 필요한 헤더(GTP)를 넣거나 제거하는 수동 프로그램이 첨부되어 있습니다(주소가 있는 fd00:fea:2001::1 if4a 및 fd00:fea가 있는 if4b: 2002 주소: :1 주소).
  • 어디에도 정의되지 않고 실제로 최종 사용자 주소인 두 개의 IPv6 주소가 있습니다(fd00:cafe:2001::1은 if6a의 사용자를 나타내고 fd00:cafe:2002::1은 if6b 네트워크의 사용자를 나타냅니다).
  • 경로 테이블은 최종 사용자 트래픽을 "if6a" 또는 "if6b"(tun 인터페이스)로 보내도록 구성됩니다.
  • 패킷이 대상 if6x 인터페이스로 직접 전달되는 것을 방지하기 위해 "cafe" 주소를 통해 "fea" IPv6 주소를 변경하고 IPv6 트래픽이 tun 인터페이스, 즉 내 GTP 핸들러를 통과하도록 강제하는 NAT 구성이 있습니다.

문제는 다음과 같습니다

  • if6a를 통해 fd00:fea:2001::1에서 fd00:cafe:2002::1로 ICMPv6을 보냅니다.
  • NAT 이후 라우팅 체인은 fd00:cafe:2001::1을 통해 소스 주소를 변경합니다.
  • if6a에서 수신 대기하는 프로그램은 ICMPv6을 읽고 GTP 헤더를 추가한 후 이를 if4b로 보냅니다(IPv4 사용).
  • GTP로 캡슐화된 IPv6 패킷의 주소는 다음과 같습니다: fd00:cafe:2001::1 ~ fd00:cafe:2002::1
  • 서버는 패킷을 수신하고 GTP 헤더를 제거한 후 이를 if6b 인터페이스에 삽입합니다(IPv6 패킷).
  • tshark가 패킷을 스니핑하고 추적을 인쇄하는 곳입니다.
  • NAT 사전 라우팅 체인은 fd00:fea:2002::1을 통해 대상 주소를 변경하고 스택 IP로 올라갑니다.
  • 패킷이 IPv6 스택 대신 IPv4 스택에 들어갔기 때문에 삭제되었습니다.

일부 흔적:

  • 샤크:

 

[root@vm062 ~]# tshark -i if6b`
 Running as user "root" and group "root". This could be dangerous
 Capturing on 'if6b'
 1   0.000000 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104 Echo
 (ping) request id=0x7383, seq=1, hop limit=0
 1   2   0.785373 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=2, hop limit=0
 2   3   1.782000 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=3, hop limit=0
 3   4   2.781968 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=4, hop limit=0...
  • Dropwatch에서 볼 수 있듯이 삭제된 패킷은 다음과 같습니다.

 

 [ipv6test@vm062 ssh]$ echo start | dropwatch -l kas
 Initalizing kallsyms db
 dropwatch> start
 Enabling monitoring...
 Kernel monitoring activated.
 Issue Ctrl-C to stop monitoring
 1 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 1 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 ...

ping6을 중지하면 ping6도 중지됩니다.

나는 공부하고있었습니다ip_rcv 함수그리고 이는 IPv4 패킷에만 작동하므로 내 IPv6 패킷은 IPv6 스택이 아닌 IPv4 스택을 통해 들어오는 것 같습니다. 커널은 왜 이런 일을 하는가?

비슷한 질문이 있습니다여기.

관련 정보