Все это хорошо в Windows, но в Linux, когда я пытаюсь получить определенную веб-страницу, я получаю долгое ожидание, а затем "сброс соединения одноранговым узлом"
Пинг IP назначения работает нормально.
Я попытался уменьшить MTU интерфейса до 1476 (найдено с помощью "ping -c1 -M do -s") и даже более низких значений, но это не решило проблему.
На другом ПК с Linux рядом с целевым хостом проблем нет, поэтому я подозреваю, что на пути есть какой-то маршрутизатор.
Это вывод wirehark и tshark:
Linux со сбросом соединения: http://pastebin.com/tpjS5qZc
Винда без проблем: http://pastebin.com/iyN1GDxT
Кажется, что третий пакет теряется на пути к хосту назначения, и пункт назначения отправляет несколько дублированных пакетов подтверждения, но я не вижу какой-либо соответствующей разницы в пакетах Windows и Linux.
В вашем захвате оба сервера устанавливают "Не фрагментировать бит". Это означает, что оба конца пытаются выполнить обнаружение MTU пути.
Вроде есть файрвол, который блокирует ICMP Fragmentation Needed сформируйте свой Linux-сервер в сторону удаленного сервера. В качестве обходного пути включите зажим MSS с помощью:
iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Вы также можете попробовать отключить обнаружение P MTU в 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