LINUX.ORG.RU

Пропал http-доступ к хосту


0

1

Есть сервер с установленным GitLab. Ничего на нем не менялось (ставились только обновления), но сейчас почему-то пропал доступ к веб-интерфейсу сервера. 80-й порт проброшен на роутере, telnet на хост проходит отлично. Подключаюсь к серверу по ssh и в логах nginx-a вижу свои обращения к хосту. Хост долго грузится и в итоге выдает «Веб-страница недоступна». В чем может быть дело? Может ли провайдер блокировать доступ (но зачем)? Кстати, через разнообразные прокси-анонимайзеры все работает.


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

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

thesis ★★★★★
()
Ответ на: комментарий от thesis

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"
Показывает, что идет обращение к хосту. Но почему не загружается веб-интерфейс? Думаю это опять провайдер палки в колеса вставляет. Через левые прокси и другой провайдер работает.

Nokman
() автор топика
Ответ на: комментарий от kerneliq

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

Nokman
() автор топика
Ответ на: комментарий от thesis

Пробовал значения 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"
Не помогло. Все также висит загрузка страницы. Стандартное значение на роутере локалхоста 1420.

Nokman
() автор топика
Ответ на: комментарий от thesis

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

Nokman
() автор топика
Ответ на: комментарий от Nokman

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

thesis ★★★★★
()
Ответ на: комментарий от thesis

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

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

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

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

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

Nokman
() автор топика

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

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

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

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

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

Nokman
() автор топика
Ответ на: комментарий от mky

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

# 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
Дальше вывода нет. Попробую сегодня еще без роутера - подключение напрямую.

Nokman
() автор топика
Ответ на: А может Интернет-цензура? от askh

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

Nokman
() автор топика
Ответ на: комментарий от Nokman

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 байт.

mky ★★★★★
()
Ответ на: комментарий от Nokman

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

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от mky

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

.....................
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
_|
SSH работает нормально - команды top, htop, cat. Пинг тоже проходит нормально даже с "-s 5000" (среднее значение пинга 55мс).

Nokman
() автор топика
Ответ на: комментарий от thesis

Закинул с помощью 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 -
Не качает. Таки проблема с MTU?

Nokman
() автор топика
Ответ на: комментарий от thesis

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

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

Nokman
() автор топика
Ответ на: комментарий от Nokman

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

thesis ★★★★★
()
Ответ на: комментарий от thesis

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

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

Nokman
() автор топика
Ответ на: комментарий от Nokman

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

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

thesis ★★★★★
()
Ответ на: комментарий от thesis

Или там наглое 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
192.168.0.1 - мой роутер. Это выходит, что на моей локальной машине MTU 1500, на роутере - 1420. Дальше в выводе tracepath провайдерские айпишники без MTU. И да, по списку ниже больше 20-ти записей «no reply». В самом конце результат:
Too many hops: pmtu 1420
Resume: pmtu 1420 

Nokman
() автор топика
Ответ на: комментарий от Nokman

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)

mky ★★★★★
()

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: .....................
До этого в выводе tracepath вместо ntp.provider.net.ua был какой-то IP. Не знаю была ли точно в этом проблема, но тем не менее это косяк на стороне провайдера судя по всему. Отмечаю тему решенной.

Nokman
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.