Rulez mai multe VM-uri în Azure. VM-urile rulează într-o subrețea cu NSG. NIC-urile nu folosesc NSG-uri, nu folosim rețele accelerate.
Observ că atunci când un VM vorbește cu un alt VM din aceeași subrețea folosind TCP, valoarea MSS din pachetele SYN este redusă cu 42. Asta înseamnă că dacă trimit un TCP SYN cu MSS=876 către un alt VM din aceeași rețea, alt VM va captura un TCP SYN cu MSS=834:
Client:
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sack 876,sack length,sack 36020 val,sack 363020,seq 3092614737
18: 49: 27.528398 IP 10.56.142.108.ssh> 10.56.142.25.49614: steaguri [S.], SEQ 1710658781, ACK 3092614738, Win 28960, Opțiuni [MSS 1418, Sackok, TS Val 390195731 ECR 29362044 ], lungime 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] 1957391 ecr lungime
Server:
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sack 834,sack length,sack 36020 val]
18: 49: 27.527682 IP 10.56.142.108.ssh> 10.56.142.25.49614: steaguri [S.], SEQ 1710658781, ACK 3092614738, Win 28960, Opțiuni [MSS 1460, Sackok, TS Val 390195731 ECR 29362044 ], lungime 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] 1957391 ecr lungime
Folosim mai multe NVA-uri, iar pachetele noastre SYN călătoresc prin mai multe hopuri și, de fapt, vedem că MSS-ul este redus de mai multe ori, am măsurat inițial o reducere cu 84, am măsurat și o reducere de 138 în unele cazuri (de fapt, nu un multiplu de 42), asta înseamnă că reducem cu mai mult de 10% eficiența rețelei noastre.
Am petrecut ceva timp privind modul în care diverse aparate de rețea joacă cu MSS. În cele mai multe cazuri, MSS este setat la o valoare fixă, fiind fie fixat la o valoare statică, fie la calea MTU. PaloAlto va folosi o „ajustare” care este relativă la MTU a unei interfețe de rețea, care este o valoare fixă. Arista vă va permite să puneți o valoare plafon pentru traficul de intrare sau de ieșire, din nou valori absolute. Unii furnizori de firewall, cum ar fi PaloAlto, vor reduce MSS în cazul unui atac DoS și cookie-urile SYN sunt activate, dar MSS va fi una dintre cele 8 valori posibile în acest caz.
Cred că acest mecanism MSS -= 42 rupe TCP: dacă clientul acceptă cadre jumbo și trimite un MSS de 8860, serverul din Azure primește 8876, el însuși răspunde 1330, dar clientul primește 1246, clientul va fi de acord că pachetele ar trebui să aibă 1246 de octeți sarcină utilă, în timp ce serverul va trimite o sarcină utilă de 1330 de octeți.
Cea mai mare problemă este că avem cazuri în care traficul funcționează „din întâmplare”.Prinderea nu se face corect pe partea de rută expres, totuși din această cauză -42 ici și colo MSS se reduce efectiv la o valoare care „se potrivește”, până când există o ușoară schimbare în modul în care sunt rutate pachetele și descoperiți dintr-o dată că pe undeva a fost o configurație greșită.
Ai idee cum să explic această reducere? Cred că acest comportament nu este documentat nicăieri.
EDITAȚI | ×
Doar citind RFC879
MSS poate fi utilizat complet independent în fiecare direcție a fluxului de date. Rezultatul poate fi dimensiuni maxime destul de diferite în cele două direcții.
Deci, pare legal conform RFC. Totuși, un comportament ciudat.
