Сброс соединения TCP в linux(странная потеря пакетов), но не в windows

Это все хорошо в Windows, но в Linux, когда я пытаюсь получить определенную веб-страницу, я получаю долгое ожидание, а затем "сброс соединения по пиру"

Pinging IP назначения работает нормально.

Я пытался уменьшить MTU интерфейса до 1476(было найдено с помощью "ping -c1 -M do -s") и даже более низкие значения, но это не решило проблему.

На другом компьютере с Linux рядом с хостом назначения проблем нет, поэтому я подозреваю, что на пути есть какой-то маршрутизатор.

Это выходы wireshark и tshark:

Linux с сбросом соединения: http://pastebin.com/tpjS5qZc

Windows без проблем: http://pastebin.com/iyN1GDxT

Кажется, что третий пакет теряется в пути к узлу назначения, и пункт назначения отправляет обратно несколько дублированных пакетов подтверждения, но я не вижу какой-либо существенной разницы в пакетах windows и linux.

Источник

1 ответ

Решение

В вашем захвате оба сервера устанавливают "Не фрагментировать бит". Это означает, что оба конца пытаются сделать Path MTU Discovery.

Кажется, что есть брандмауэр, который блокирует ICMP Fragmentation Needed сформируйте свой сервер Linux к удаленному серверу. В качестве обходного пути включите зажим MSS с помощью:

iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu

Вы также можете попробовать отключить P MTU Discovery в Linux:

echo  1  |sudo tee /proc/sys/net/ipv4/ip_no_pmtu_disc

От iptables справочная страница:

TCPMSS Эта цель позволяет изменить значение MSS пакетов TCP SYN, чтобы контролировать максимальный размер для этого соединения (обычно это ограничение MTU вашего исходящего интерфейса минус 40 для IPv4 или 60 для IPv6, соответственно). Конечно, его можно использовать только в сочетании с -p tcp.

   This  target is used to overcome criminally braindead ISPs or servers which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too
   Big" packets.  The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind  it
   can never exchange large packets:
    1) Web browsers connect, then hang with no data received.
    2) Small mail works fine, but large emails hang.
    3) ssh works fine, but scp hangs after initial handshaking.
   Workaround: activate this option and add a rule to your firewall configuration like:

           iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN
                       -j TCPMSS --clamp-mss-to-pmtu

   --set-mss value
          Explicitly  sets  MSS  option  to  specified  value.  If  the  MSS of the packet is already lower than value, it will not be
          increased (from Linux 2.6.25 onwards) to avoid more problems with hosts relying on a proper MSS.

   --clamp-mss-to-pmtu
          Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).  This may not function as desired where  asymmetric
          routes  with  differing  path MTU exist — the kernel uses the path MTU which it would use to send packets from itself to the
          source and destination IP addresses. Prior to Linux 2.6.25, only the path MTU to the destination IP address  was  considered
          by this option; subsequent kernels also consider the path MTU to the source IP address.

   These options are mutually exclusive.

Смотрите: http://lartc.org/howto/lartc.cookbook.mtu-mss.html

Изменить: После того как я более внимательно посмотрел на перехваты, я обнаружил, что на пути есть сломанный межсетевой экран, который фильтрует все IP-пакеты, которые используют опцию TCP Timestamp. Просто запустите на коробке Linux: echo 0 | sudo tee /proc/sys/net/ipv4/tcp_timestamps

Источник
Другие вопросы по тегам