mtu?

ставились только обновления

Ну я даже не знаю с чего начать.
И что по логам тебе отвечает нжынкс?

access.log

192.168.1.105 - - [27/Apr/2013:15:54:37 +0300] "GET /users/sign_in HTTP/1.0" 200 2138 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31"

Не знаю, что с ним может быть не так.

Ага, таки 200.
Ну попробуй уменьшить MTU на локалхосте и посмотри, что будет.

Пробовал значения MTU 1370, 1000, 700. access.log

192.168.1.105 - - [27/Apr/2013:16:52:45 +0300] "GET /users/sign_in HTTP/1.0" 200 2138 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31"

А какой тип подключения к провайдеру?

PS как же я ненавижу отправку сообщения по контрол+вводу.

Подключение PPTP.

Попробуй еще MTU и MRU поставь 1200 в ppp options. Чтобы закрыть этот вопрос.

Хм, не нашел где на роутере указать значение MRU. Роутер TP-Link (WR741ND) со стоковой прошивкой. Значение MTU изменил на 1200, что опять же не дало никакого результата. Я в шоке, несколько дней назад все работало просто отлично. После недавних проблем на стороне провайдера (что-то с каналом связи) начались вот такие проблемы, даже ssh недавно отказывался работать нормально. Наверное, придется использовать «костыли» в виде китайских прокси :(

Я перестал понимать, кто на ком стоял.
Я думал, у тебя так: где-то есть роутер с белым адресом, за которым стоит вебсервер.
С другого конца интернета ты, подключившись к неведомому провайдеру по pptp, ломишься на 80й порт роутера и получаешь фиг.
Если это так, я просил тебя изменить параметры подключения ppp на той машине, с которой ты подключаешься к провайдеру по pptp. Если не так, то зачем в топике сказано о пробросе 80-го порта роутером, не совсем понимаю.

Роутеры установлены на обоих сторонах: у меня (с подключением по pptp+раздача wi-fi на ноутбук с которого пишу) и удаленно (за которым работает веб-сервер, да). 80-й порт проброшен на удаленном роутере. На удаленном белый постоянный ip.

С другого конца интернета ты, подключившись к неведомому провайдеру по pptp, ломишься на 80й порт роутера и получаешь фиг.

Да, на 80-й порт удаленного роутера.

Если это так, я просил тебя изменить параметры подключения ppp на той машине, с которой ты подключаешься к провайдеру по pptp

Я так и сделал. Параметры менял на своем роутере. Но на нем нашел только как изменить значение MTU. Как-то так..

Запустите на сервере tcpdump на перехват tcp порт 80 и смотрите, все ли пакеты доходят.

В принципе, провайдер может блокировать что угодно, но может просто глючить ваш маршрутизатор.

Кроме MTU у маршрутизаторов бывают проблемы с tcp window scaling и другими опциями tcp, Потеря пакетов и другие глюки сети. (комментарий)

Запустите на сервере tcpdump на перехват tcp порт 80 и смотрите, все ли пакеты доходят.

Как правильно это сделать? Попробовал так:

# tcpdump port 80
...........................
30 packets captured
30 packets received by filter
0 packets dropped by kernel

Хм, делаю дамп удаленного хоста со своей локальной машины и все останавливается:

# tcpdump host myhost.com
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

А может Интернет-цензура?

Как вариант: может IP провайдера попал в чёрные списки? Проверить можно здесь: http://zapret-info.gov.ru/

Домен и хостинг зарегистрированы в Украине. Проверил ради интереса по указанному адресу: «Искомый адрес не значится в реестре». Вот с провайдером вариант блокировки возможен и в последнее время все больше об этом думаю. Только зачем им это нужно? Если что, буду звонить в техподдержку после выходных.

tcpdump -n -nn -s 2000 -i ИНТЕРФЕЙС -A port 80 and tcp and host IP-адрес-сервера

Нужно указать интерфейс. И запускать два tcpdump, один на клиенте, откуда идёт запрос, другой на сервере. Тогда можно сравнить, проходят ли все пакеты и меняется ли их содержимо. Раз у вас бразуер ничего не отображает, пакетов должно быть не много, только самое начало tcp-сессии.

А вобще, сначла лучше проверить, что и ssh нормально работает, допустим нормально выполняется команда ″top″ или ″cat ФАЙЛ_10-20_килобайт″. То есть нормально работают команды, выводящие в терминал разом досаточно большой объём данных. И ″ping″ нужно делать большими пакетами (размер задаётся опцией -s), посмотреть как ходят ping'и по 500, 1000, 2000 байт.

А теста ради сгенери файлик метров на 15-20 на вебсервере (или готовый какой-нибудь возьми) и попробуй его скачать через sftp или scp. Если проблема в MTU (я никак не могу отделаться от этой мысли), то качаться будут только мелкие файлы в пару кб весом, а все, что побольше, будет виснуть и обрываться.

Ну и чего там, tracepath покажи.

На сервере команда обрабатывается без проблем:

.....................
10 packets captured
16 packets received by filter
0 packets dropped by kernel

tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 2000 bytes
_|

Закинул с помощью scp файл на сервер, а назад его забрать тем же способом не выходит, да.

alex@localhost:~$ sudo scp server@host.com.ua:/home/server/test_file /home/
server@host.com.ua's password: 
test_file                                                                                                                       0%    0     0.0KB/s - stalled -

А файл с небольшим размером, типа публичного ssh-ключа (id_rsa.pub) загрузился без проблем. Т.е. проблема со скачиванием больших файлов. Тот тестовый файл («test_file»), скачать который так и не вышло - размером 20МБ.

p.s. Почему я не могу править свои комментарии?

Ну и покажи tracepath до удаленного роутера.
Кстати, роутеры у тебя железячные с обоих сторон? Не какие-нибудь линуксовые машины, нет? Поройся по ним на предмет фильтрации фрагментированных пакетов и всего в этом роде.

А что даст tracepath? Разве, что нарушит мою анонимность :)

Роутеры железячные TP-Link (серии N). Настройки покрутить можно, но если ничего не менялось и вдруг перестало работать это весьма странно. Провайдер проблему на своей стороне не признает. Уже перестаю понимать куда и копать.

Разве, что нарушит мою анонимность :)

Да окончательный диагноз нужен, а не сама трассировка. Или там наглое 1500?
А копать надо в сторону workaround, раз уж источник проблем не у тебя, а у прова.

Или там наглое 1500?

Не совсем.

 1:  linux.local                                           0.192ms pmtu 1500
 1:  192.168.0.1                                           2.015ms 
 1:  192.168.0.1                                           1.603ms 
 2:  192.168.0.1                                           1.615ms pmtu 1420

Too many hops: pmtu 1420
Resume: pmtu 1420 

tcpdump: WARNING: eth0: no IPv4 address assigned

Как это понимать? У вас клиент работает без ip-адреса, или вы запускаете tcpdump не на том интерфейсе, где клиент получает трафик?

Если проблема с MTU, то по scp не должны передаваться файлы размером более 1000-1500 байт. Так что попробуйте определить размер файла, который не удаётся скопировать по scp.

У вас на сервере остались правила в iptables, корректирующие MSS?

Работает ли ping большими пакетами, когда запускается с сервера? При выводе информации о каждом полученном в ответ пакете число байт близко к тому, что указывается в оцпии ″-s″, в конце строки не пишется (truncated)? Вот как здесь:

# ping -s 1000 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1000(1028) bytes of data.
72 bytes from 8.8.8.8: icmp_seq=1 ttl=49 (truncated)
72 bytes from 8.8.8.8: icmp_seq=2 ttl=49 (truncated)

thesis, mky спасибо вам большое, да и другим тоже за попытки помощи. Проблема сегодня исчезла точно также как и появилась. Единственное, что удалось заметить - это изменение в выводе tracepath. Одна строка с записью там все же изменилась. Я специально это проверил после того как все заработало.

$ tracepath myhost.com.ua
 1:  linux.local                                           0.096ms pmtu 1500
 1:  192.168.0.1                                           1.967ms 
 1:  192.168.0.1                                           1.620ms 
 2:  192.168.0.1                                           1.605ms pmtu 1420
 2:  10.20.30.40                                           13.437ms 
 3:  ntp.provider.net.ua                                   29.809ms
 n: .....................