Vps сервер не работает

Как починить «сломанный» VPS сервер на Linux

Мы в компании Ruvds запустили на нашем хостинге возможность аренды серверов на Linux с операционными системами Centos, Debian и Ubuntu server!

Поэтому, мы объявляем конкурс «Как починить „сломанный“ VPS сервер на Linux». Попробуйте ваши силы в конкурсе, ведь в прошлый раз победитель справился за 3 часа. На этот раз мы немного усложнили задачу.

Условия конкурса
Нужно настроить веб-сервер nginx таким образом, чтобы при обращении на адрес http://your_vps_ip отображался сайт подготовленный для этих целей.

Требования
Файлы этого сайта сейчас размещены в директории: /home/administrator/contest_files.
Их нужно переместить на отдельный раздел размером 1gb или более (файловая система xfs), созданный путем уменьшения текущего раздела /dev/sda3

Что делать запрещено

• использовать загрузку OS по сети
• загружать на сервер новые файлы, которые не использовались при установке текущей версии ОС или не находились на сервере
• нельзя устанавливать пакеты, которые не были установлены до этого
• нельзя отключать файрвол
• нельзя уменьшать размер других разделов (/dev/sda1, /dev/sda2)
• нельзя повреждать файловую систему
• использовать сервер для каких-либо других целей

Как начать
Отправить заявку на support@ruvds.com с пометкой «Конкурс для Linux» и указав email, использованный при регистрации на сайте ruvds.com.

Когда задача считается выполненной
Cайт доступен по адресу http://your_vps_ip, а вы предоставили детальный отчет о ваших действиях, которые позволили решить задачу.

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

Призовой фонд конкурса
Первое место: VDS сервер, CPU 5×2.6ГГц, RAM 5 ГБ, Disk SSD 50 ГБ один год бесплатного пользования, диплом победителя, фирменная кружка от RUVDS.
Второе место: Скидка 70%, фирменная кружка от RUVDS
Третье место: Скидка 50%, фирменная кружка от RUVDS
Четвертое место: Скидка 30%, фирменная кружка от RUVDS

Итоги конкурса и наш вариант решения задачи: здесь

Источник

Диагностика сетевых неполадок VPS

После установки подключение по ssh длится долго.
Установленное сетевое ПО (proxy/VPN/CDN/webserver) работает медленно.

Низкая скорость является результатом неверно выбранной подсети. Не всегда с первого раза удаётся получить работающую со 100 % эффективности сеть на отдачу 160-200 мбит. Почему? При создании VPS мы не можем угадать ваш город, страну, возможные блокировки магистральных провайдеров сети и многие другие факторы. Также, на скорость подключения влияет неверно выбранный датацентр.

Следует заменить подсеть, через процедуру переустановки VPS.
Если замена сети не повлияла на задержки сети, измените ЦОД сервера.

Вы можете проверить среднюю скорость до датацентра До заказа VPS, через наш сервис:
https://lg.justhost.ru/
Внимание: полученные при проверке результаты сервисом https://lg.justhost.ru/ могут отличаться, как в лучшую так и в худшую сторону, от скорости реального сервера. Наилучший способ измерить скорость — это проводить измерения скорости непосредственно на самом VPS! Также, следует помнить, что сервис LookingGlass предоставляет для тестирования лишь Одну подсеть ipv4/ipv6 в то время как для заказа доступно большое количество подсетей и скорость из других подсетей может отличаться.

После установки я не могу подключиться к VPS

Сначала нужно убедиться, что это не проблема доступа от вашего провайдера/ISP сети.
Проверьте ping до VPS со следующих ресурсов:
http://ping.pe/
http://ping.chinaz.com/
Если отклик есть — значит имеются проблемы доступа через вашего провайдера сети.

Перезагрузите сетевое оборудование, проверьте доступ с мобильного провайдера (без wifi). Если это не помогло, значит данная подсеть недоступна в вашем регионе по различным причинам. Это НЕ является проблемой. Это обычная ситуация для большого хостера, с множеством сетей и датацентров. Измените подсеть, то есть ip адрес на странице управления VPS либо через запрос в нашу техподдержку .
Каждому клиенту даётся 5 бесплатных замен адреса, через процедуру переустановки.

Не открывается сайт или другой сетевой сервис установленный на VPS

Убедитесь, что порт открыт в файрволле.
Проверьте, работает ли программа:
Для сервиса с портами tcp выполните в консоли ssh:

Для сервиса с портами udp:

Если вашей программы Нет в списке — значит она не работает или работает неверно. Проверьте корректность работы вашей программы.
Если программа в списке, убедитесь, что порт доступен извне, любыми веб-сервисами проверки портов. Попробуйте изменить номер порта на другой. Провайдеры сети могут блокировать некоторые порты по умолчанию.

Источник

Проблема с VPS не грузится сайт после перезагрузки сервера?

nginx вообще стартован ? проверьте есть ли он в процессах.

ps -ef | grep nginx

Если пусто, то стартуйте и добавьте его в автозагрузку.

PS Как стартовать, надеюсь знаете.

с удаленной машины.

А если дернуть curl’ом/wget’ом с локалхоста ваш сайт?

И покажите правила iptables (хотя казалось бы, если бы всего-лшь рестарт)

sudo iptables -S

443 в nginx редиректится

правила
sudo iptables -S
[sudo] password for alx:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
И еще у нас кто-то долбится по ssh
last -f /var/log/btmp
это может повлиять на доступность сайта?

]$ telnet * 80
по 80 приконектился по 443 Connection refused

Сергей Ганжела, Ну проблема ясна, nginx не поднимает 443-й порт, вот почему — так сходу неясно. Покажите error-лог после рестарта. Если там вообще ничего нет, то попробуйте запустить nginx в дебаге

Источник

Что делать, если сервер недоступен по сети

Рассмотрим случай, когда сервер доступен по VNC, но при этом не пингуется и не реагирует на попытки подключения по ssh. Тут есть несколько сценариев развития событий, о которых мы поговорим далее. Но сначала убедимся, что это наш случай, и проверим, есть ли пинг.

Проверка пинга

Запустить ping с вашего ПК до IP-адреса вашего сервера можно, например, через CMD : командная строка Windows ( Пуск — Все программы — Стандартные — Командная строка )

Если пинг проходит корректно, то вы увидите статистику переданных пакетов и время ответа, как на скриншоте:

В противном случае появится сообщение об ошибке, что говорит о сетевой недоступности, либо о проблемах с соединением:

Далее нужно зайти на сам сервер и проверить пинг с сервера до внешних ресурсов, перейдите в панель VMmanager и найдите в верхнем меню значок VNC .

Если вы используете VMmanager 6, то нажмите на кнопку VNC во вкладке Виртуальные машины .

В окне VNC необходимо авторизоваться и запустить ping до любого адреса, например 8.8.8.8 . Если сеть работает, то вы увидите количество переданных пакетов и время, за которое они достигли конечного адреса. Если нет, то придут сообщения вида network unreacheble, connection timeout, либо команда будет просто «висеть» без вывода.

Так как ping не проходит, это говорит о том, что не работает сеть. Поэтому переходим к следующему шагу и идём проверять, в чём может быть проблема.

Проверка сетевых настроек сервера

Первым делом проверим корректность сетевого конфига. Если вы приобрели новый сервер и установили свою операционную систему из образа, могли ошибиться с настройками сети. Но даже для действующего сервера не будет лишним убедиться в том, что настройки в порядке. Узнать, какие сетевые настройки следует использовать для вашей операционной системы, можно в статье «Сетевые настройки в кластерах с технологией VPU».

Диагностика проблем сети с помощью утилиты ip

Диагностировать проблему нам поможет утилита ip — она покажет имя, статус сетевого интерфейса и IP-адреса, которые ему назначены. Утилита установлена во всех современных linux-дистрибутивах.

На сервере с корректными настройками вывод будет таким:

В этом случае, нас интересует блок с названием нашего сетевого интерфейса — в этом случае eth0 (на разных ОС может называться по-разному, например, ens3, eno1).

Здесь прописан наш IP-адрес, маска и шлюз, что можно увидеть в строке:

На наших серверах используется технология VPU , поэтому в качестве сетевого шлюза на серверах используется адрес 10.0.0.1 , а маска подсети /32

Также следует обратить внимание на статус интерфейса. Если его статус DOWN, а не UP, то стоит попробовать запустить интерфейс вручную командой if up eth0 , где вместо eth0 укажите имя вашей сетевой карты. Ранее мы рассмотрели, где можно его найти.

На этом примере видно, что интерфейс не «поднимается» из-за синтаксических ошибок в конфигурационном файле сетевых настроек /etc/network/interfaces .

Также стоит проверить статус службы Network командой systemctl status networking . Если она не запущена, то стоит её запустить командой systemctl start networking . Если служба не запустилась, то, возможно, имеется ошибка в конфигурации, о чём будет сообщено в выводе команды запуска. Вам нужно обратить внимание на строку, которая начинается с Active . Обычно статус запуска службы выделен цветом: красным в случае ошибки и зелёным, если запуск был успешен — как на скриншотах ниже:

Далее проверяем маршруты. Даже если сетевой интерфейс работает и IP указан верно, без двух маршрутов сеть работать не будет.

Должен быть прописан путь до 10.0.0.1 и он же установлен по умолчанию (дефолтным), как здесь:

Если сеть не заработала, проверяем пинг до шлюза 10.0.0.1 — если он проходит, возможно, проблемы на стороне хостинг-провайдера. Напишите нам в поддержку, разберёмся.

Проверка фаервола

Возможен вариант, что сеть настроена корректно, но трафик блокируется фаерволом внутри самого VDS.

Чтобы это проверить, первым делом смотрим на политики по умолчанию.
Для этого вводим iptables-save и смотрим на первые несколько строк вывода.

В начале мы увидим политику по умолчанию для соединений (цепочек) INPUT , OUTPUT , FORWARD — то есть правила для всех входящих, исходящих и маршрутизируемых соединений. Они имеют статус DROP либо ACCEPT .

Когда все соединения с сервера заблокированы, они имеют статус DROP , и вывод выглядит так:

Чтобы исключить влияние фаервола, просматриваем текущие правила с помощью iptables-save и сохраняем их в отдельный файл командой:

Меняем все политики по умолчанию на ACCEPT и сбрасываем все текущие правила командами:

Если после выполнения этих команд сеть появилась, значит проблема была в этом. Поэтому после того, как вы локализовали причину, необходимо разобраться, какое из правил блокирует доступ. Уточним, что при перезагрузке сервера исходные правила восстановятся, либо их можно восстановить командой из ранее сохраненного нами файла

Проверка влияния ПО

Возможен вариант, что установленные на сервере программы (особенно связанные с изменением маршрутизации на сервере, например, OpenVPN, Docker, PPTP) «ломают» работу сети. Чтобы исключить влияние установленного на сервер ПО, можно запустить сервер в режиме восстановления и проверить сеть.

Для этого в панели VMmanager останавливаем VDS и подключаем ISO-образ sysrescueCD через меню Диски :

В VMmanager 6 ISO-образ sysrescueCD подключается в Меню сервера по кнопке Режим восстановления на главной странице панели.

После загрузки образа подключаемся по VNC и выполняем команды (в VM6 еще потребуется сначала выбрать образ восстановления в VNC)

После чего запускаем пинг до 8.8.8.8 . Если он проходит, значит, с сетью на сервере всё благополучно.

Проверка на наличие сетевых потерь

Ещё возможен такой случай, что сеть работает, но наблюдаются потери пакетов по сети, что приводит к долгой загрузке сайтов, долгому ответу сервера и прочим неудобствам.

Для диагностики подойдет утилита mtr . Она совмещает в себе трассировку и пинг, что наглядно показывает, есть ли проблемы с потерей пакетов и на каких узлах (хопах) они проявляются.

Запускаем на сервере mtr до вашего IP, с которого пробуете подключаться, и с сервера — в обратном направлении до вашего адреса :

В верхнем окне показана трассировка с сервера до домашнего компьютера, в нижнем обратная, с ПК до сервера. Видно, что потерь нет, пакеты не теряются, пинг стабильный. Так должен выглядеть вывод mtr , если у вас все хорошо.

В случае, если на пути имеются потери, вместо 0.0% на хопах (промежуточных узлах) в столбце Loss будет указан процент потерянных пакетов от соответствующего узла. На примере ниже видно, что потери начинаются на одном из узлов и дальше сохраняются на последующих хопах:

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

В этой статье мы разобрались, как диагностировать проблемы, связанные с доступностью сервера по сети — от настроек на VDS и параметров фаервола до запуска трассировки при потерях. Если столкнулись с проблемой с доступностью сервера, но ответа в статье не нашли, обратитесь в техническую поддержку — мы всегда поможем.

Источник