.png)
Azure에서 여러 VM을 실행하고 있습니다. VM은 NSG가 있는 서브넷에서 실행됩니다. NIC는 NSG를 사용하지 않으며 가속 네트워킹을 사용하지 않습니다.
VM이 TCP를 사용하여 동일한 서브넷의 다른 VM과 통신할 때 SYN 패킷의 MSS 값이 42만큼 감소한다는 것을 알았습니다. 즉, MSS=876인 TCP SYN을 동일한 네트워크의 다른 VM에 보내면 다른 VM은 MSS=834로 TCP SYN을 캡처합니다.
고객:
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
섬기는 사람:
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
우리는 여러 NVA를 사용하고 있으며 SYN 패킷은 여러 홉을 통해 이동하며 실제로 MSS가 여러 번 감소하는 것을 볼 수 있습니다. 원래 감소를 84로 측정했으며 어떤 경우에는 138의 감소도 측정했습니다(실제로 의 배수는 아님). 42) 이는 네트워크 효율성이 10% 이상 감소한다는 의미입니다.
나는 다양한 네트워크 장비가 MSS와 어떻게 작동하는지 살펴보는 데 시간을 보냈습니다. 대부분의 경우 MSS는 정적 값이나 경로 MTU로 고정되어 고정 양으로 설정됩니다. PaloAlto는 고정된 값인 네트워크 인터페이스의 MTU에 상대적인 "조정"을 사용합니다. Arista를 사용하면 수신 또는 송신 트래픽에 대한 상한값(역시 절대값)을 지정할 수 있습니다. PaloAlto와 같은 일부 방화벽 공급업체는 DoS 공격 및 SYN 쿠키가 활성화된 경우 MSS를 줄이지만 이 경우 MSS는 8가지 가능한 값 중 하나가 됩니다.
나는 이 MSS -= 42 메커니즘이 TCP를 중단한다고 생각합니다. 클라이언트가 점보 프레임을 지원하고 8860의 MSS를 보내는 경우 Azure의 서버는 8876을 수신하고 자체적으로 1330을 응답하지만 클라이언트는 1246을 수신하며 클라이언트는 패킷이 1246바이트를 가져야 한다는 데 동의합니다. 서버는 1330바이트의 페이로드를 전송합니다.
가장 큰 문제는 "우연히" 트래픽이 작동하는 경우가 있다는 것입니다. Express 경로 측에서는 클램핑이 제대로 수행되지 않지만 여기저기서 이 -42로 인해 MSS는 패킷이 라우팅되는 방식에 약간의 변화가 있을 때까지 실제로 "적합"한 값으로 감소됩니다. 갑자기 어딘가에 잘못된 구성이 있다는 것을 알게 되었습니다.
이 감소를 어떻게 설명할 수 있을까요? 나는 이 행동이 어디에도 문서화되어 있지 않다고 생각합니다.
편집하다
그냥 읽는 중RFC879
MSS는 데이터 흐름의 각 방향에서 완전히 독립적으로 사용될 수 있습니다. 결과적으로 두 방향의 최대 크기가 상당히 다를 수 있습니다.
따라서 RFC에 따르면 합법적인 것처럼 보입니다. 그래도 이상한 행동이네요.
답변1
물리적 네트워킹과 달리 SDN 네트워킹은 GRE(캡슐화 헤더)에 추가 "바이트"를 사용합니다. 보이는 IP는 CA(고객 주소)이지만, 클라우드 제공자에서 라우팅이 필요한 PA(공급자 주소)도 있습니다. 따라서 클라우드 공급자가 백엔드 라우팅이 발생하도록 인프라에 추가 TCP 클램핑을 적용하므로 사용 가능한 MSS가 줄어듭니다.