Brak odpowiedzi na niektóre pakiety SYN po włączeniu znaczników czasu

Mam serwer TCP nasłuchujący na komputerze („serwerze”) z systemem Ubuntu 12.04.3 (jądro 3.8.0-31-generic). Odbiera połączenia z 2 różnych komputerów klienckich. Na komputerze A działa Ubuntu 12.04.4 (3.11.0-17-generic), a na komputerze B działa Ubuntu 11.10 (3.0.0-32-server).

Jeśli znaczniki czasu TCP są włączone na serwerze (sysctl net.ipv4.tcp_timestamps = 1), to czasami pakiety SYN z komputera A są „ignorowane”. Korzystając z tcpdump na serwerze (w trybie nieużytecznym) widzę, że SYN przychodzą OK i przy prawidłowych sumach kontrolnych - po prostu nie ma odpowiedzi - brak SYN / ACK i brak RST. Maszyna A retransmituje SYN kilka razy przed poddaniem się. Oprogramowanie klienckie działające na komputerze A (w tym przypadku wget) natychmiast próbuje ponownie nawiązać nowe połączenie i kończy się powodzeniem, uzyskując natychmiastową SYN / ACK.

Komputer B nie ma problemów z tym samym serwerem i jego ruch wygląda normalnie - używa również tych samych opcji TCP, co komputer A (z tego, co widzę z plików przechwytywania). Wyłączenie znaczników czasu TCP na serwerze sprawia, że ​​wszystko działa tak, jak powinno.

Znaczniki czasu w ignorowanych pakietach SYN wydają mi się jednak poprawne, więc nie jestem pewien, dlaczego powodują problemy lub czy w ogóle są przyczyną.

Umieściłem tutaj anonimowy pcap https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap . Został wzięty na serwer (10.76.0.74) pokazujący maszynie A (10.4.0.76), z powodzeniem wykonującą HTTP GET (pakiety od 1 do 10), a następnie 1 sekundę później próbuje ponownie pobrać ten sam adres URL (pakiety 11 do 17), ale zamiast tego ma ignorowane SYN. Pakiety od 18 do 27 to kolejny sukces.

Podejrzewam, że jest to problem podobny do opisanego w „ Dlaczego serwer nie wysyła pakietu SYN / ACK w odpowiedzi na pakiet SYN ” i chociaż wyłączenie znaczników czasu jest obejściem, chciałbym zrozumieć, co się dzieje. Czy to tylko błąd?

Nie ma uruchomionej lokalnej zapory ogniowej. Serwer obsługuje sporo połączeń TCP (w tym samym czasie około 32 KB), ale ma dużo wolnej pamięci / procesora. W czasie testu pokazanego na pcap nie było innych połączeń TCP między maszyną A a serwerem. Nic nie wskazuje na to, że kolejka akceptacji aplikacji serwera nagle się zapełnia (poza tym, jak sądzę, powinien to mieć wpływ na obu klientów). Ponieważ pakiety wyglądają OK na pcapie zrobionym na serwerze, nie wygląda na to, że interweniujące urządzenie sieciowe psuje rzeczy.

Pierwotnie opublikowałem to na forach ubuntu, ale z perspektywy czasu może to być bardziej odpowiednia lokalizacja. Nadzieję na pożyczkę wskazówki.

W moim przypadku następujące polecenie rozwiązało problem z brakującymi odpowiedziami SYN / ACK z serwera Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Myślę, że jest to bardziej poprawne niż wyłączenie znaczników czasu TCP, ponieważ znaczniki czasu TCP są w końcu przydatne (PAWS, skalowanie okien itp.).

Dokumentacja tcp_tw_recyclewyraźnie stwierdza, że ​​nie jest zalecane włączenie tej opcji, ponieważ wiele routerów NAT zachowuje znaczniki czasu, a zatem PAWS uruchamia się, ponieważ znaczniki czasu z tego samego adresu IP nie są spójne.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.