По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
У вас проблемы с доступом к удаленному серверу через SSH? Если SSH отвечает сообщением «Connection Refused» (Соединение отклонено), возможно, вам придется изменить запрос или проверить настройки.
Почему при использовании SSH возникает отказ в подключении?
Существует множество причин, по которым вы можете получить ошибку «Connection Refused» при попытке подключения к серверу по SSH. Чтобы решить эту проблему, вам сначала нужно определить, почему система отказалась от вашего подключения через SSH.
Ниже вы найдете некоторые из наиболее распространенных причин, которые могут вызвать отказ в соединении SSH.
Клиент SSH не установлен
Прежде чем устранять другие проблемы, первым делом необходимо проверить, правильно ли установлен SSH. На машине, с которой вы получаете доступ к серверу, должен быть настроен клиент SSH. Без правильной настройки клиента вы не сможете подключиться к серверу.
Чтобы проверить, есть ли в вашей системе клиент SSH, введите в окне терминала следующее:
ssh
Если терминал предоставляет список параметров команды ssh, клиент SSH установлен в системе. Однако, если он ответит, что команда не найдена (command not found), вам необходимо установить клиент OpenSSH.
Решение: установить клиент SSH
Чтобы установить клиент SSH на свой компьютер, откройте терминал и выполните одну из команд, перечисленных ниже.
Для систем Ubuntu / Debian:
sudo apt установить openssh-client
Для систем CentOS / RHEL:
sudo yum установить openssh-client
Демон SSH не установлен на сервере
Так же, как вам нужна клиентская версия SSH для доступа к удаленному серверу, вам нужна версия сервера для прослушивания и приема соединений. Таким образом, сервер может отклонить входящее соединение, если SSH-сервер отсутствует или настройка неверна.
Чтобы проверить, доступен ли SSH на удаленном сервере, выполните команду:
ssh localhost
Если на выходе отображается «Connection refused», переходите к установке SSH на сервере.
Решение: установите SSH на удаленный сервер
Чтобы решить проблему отсутствия сервера SSH, установите сервер OpenSSH.
Учетные данные неверны
Опечатки или неправильные учетные данные - частые причины отказа в SSH-соединении. Убедитесь, что вы не ошиблись при вводе имени пользователя или пароля.
Затем проверьте, правильно ли вы используете IP-адрес сервера.
Наконец, убедитесь, что у вас открыт правильный порт SSH. Вы можете проверить, запустив:
grep Port /etc/ssh/sshd_config
На выходе отображается номер порта, как на картинке ниже.
Служба SSH не работает
Служба SSH должна быть включена и работать в фоновом режиме. Если служба не работает, демон SSH не может принимать соединения.
Чтобы проверить статус службы, введите эту команду:
sudo service ssh status
Вывод должен ответить, что служба активна. Если терминал отвечает, что служба не работает, включите его, чтобы решить проблему.
Решение: включить службу SSH
Если система показывает, что демон SSH не активен, вы можете запустить службу, выполнив:
systemctl start sshd
Чтобы служба запускалась при загрузке, выполните команду:
sudo systemctl enable sshd
Брандмауэр препятствует подключению SSH
SSH может отклонить соединение из-за ограничений брандмауэра. Брандмауэр защищает сервер от потенциально опасных подключений. Однако, если в системе настроен SSH, необходимо настроить брандмауэр, чтобы разрешить SSH-соединения.
Убедитесь, что брандмауэр не блокирует SSH-соединения, так как это может вызвать ошибку «Connection refused».
Решение: разрешить SSH-подключения через брандмауэр
Чтобы решить проблему, о которой мы упоминали выше, вы можете использовать ufw (Uncomplicated Firewall - несложный брандмауэр), инструмент интерфейса командной строки для управления конфигурацией брандмауэра.
Введите следующую команду в окне терминала, чтобы разрешить SSH-соединения:
sudo ufw allow ssh
Порт SSH закрыт
Когда вы пытаетесь подключиться к удаленному серверу, SSH отправляет запрос на определенный порт. Чтобы принять этот запрос, на сервере должен быть открыт порт SSH.
Если порт закрыт, сервер отказывает в соединении.
По умолчанию SSH использует порт 22. Если вы не вносили никаких изменений в конфигурацию порта, вы можете проверить, прослушивает ли сервер входящие запросы.
Чтобы вывести список всех прослушивающих портов, запустите:
sudo lsof -i -n -P | grep LISTEN
Найдите порт 22 в выходных данных и проверьте, установлено ли для него STATE значение LISTEN.
Кроме того, вы можете проверить, открыт ли конкретный порт, в данном случае порт 22:
sudo lsof -i:22
Решение: откройте порт SSH
Чтобы разрешить порту 22 слушать запросы, используйте команду iptables:
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
Вы также можете открывать порты через графический интерфейс, изменив настройки брандмауэра.
Отладка и ведение журнала SSH
Чтобы проанализировать проблемы SSH в Linux, вы можете включить подробный режим или режим отладки. Когда вы включаете этот режим, SSH выдает отладочные сообщения, которые помогают устранять проблемы с подключением, конфигурацией и аутентификацией.
Существует три уровня детализации:
уровень 1 (-v)
уровень 2 (-vv)
уровень 3 (-vvv)
Поэтому вместо доступа к удаленному серверу с использованием синтаксиса ssh [server_ip] добавьте параметр -v и выполните:
ssh -v [server_ip]
В качестве альтернативы вы можете использовать:
ssh -vv [server_ip]
или
ssh -vvv [server_ip]
При оценке плюсов и минусов Citrix XenServer (который сейчас называется Citrix Hypervisor) по сравнению с VMware vSphere ESXi первым делом следует отметить, что эти две программные системы разрабатываются и поддерживаются разными компаниями. VMware vSphere ESXi разработана компанией VMware Inc., тогда как XenServer - компанией Citrix.
Несмотря на то, что они выполняют схожие роли, у них есть несколько отличий, которые делают их уникальными. Основное различие между ними заключается в предполагаемом использовании программного обеспечения. Citrix XenServer используется частными пользователями, а также малым и средним бизнесом, в то время как VMware vSphere ESXi предназначена только для малого и среднего бизнеса и не структурирована для личного использования.
Технические характеристики
Обе эти программы работают на выделенных серверах без предусмотренной управляющей операционной системы,в то же время поддерживают архитектуры x86 и x64. Хотя они предусматривают различные типы виртуализации, такие как аппаратная виртуализация и паравиртуализация, только VMware vSphere ESXi поддерживает полную виртуализацию. Ни одна из них не поддерживает виртуализацию операционных систем.
Оба комплекта программного обеспечения поддерживают различные варианты хранения данных. Когда дело доходит до виртуализации, разница между ними заключается в том, что VMware поддерживает FCoE и SSD для Swap и не поддерживает USB, SATA, SAS, NFS, iSCSI, которые поддерживаются Citrix XenServer. Оба они поддерживают системы хранения DAS, FC и NAS, в то время как ни один из них не поддерживает eSATA или RDM. Множество пользователей в сфере образования, финансовых услуг, здравоохранения и правительства также используют эти системы.
Сравнение цен на Citrix Xenserver и Vmware vSphere
Сравнение цен на Citrix XenServer и VMware vSphere ESXi дает несколько интересных представлений о различных бизнес-моделях, которые они приняли на вооружение. XenServer является открытым и бесплатным исходным кодом, который предоставляет лицензирование для каждого сервера.
С другой стороны, VMware требует собственной лицензии и лицензируется для каждого процессора. Оба продукта имеют клиент по всему миру вне зависимости от их ценовой структуры.
Лимиты виртуальной машины
Эти решения имеют размер виртуального диска 2000 ГБ, но объем оперативной памяти на одну виртуальную машину зависит от VMware, поскольку он предлагает ошеломляющую емкость в 1024 ГБ, в то время как Citrix XenServer предлагает 128 ГБ на одну виртуальную машину.
Сервер XenServer имеет в общей сложности 16 виртуальных ЦП на одну виртуальную машину (VCPU), а VMware - вдвое больше, 32 VCPU. XenServer предоставляет в общей сложности 7 карт виртуального сетевого интерфейса (NIC) и 16 виртуальных дисков на одну виртуальную машину. С другой стороны, VMware vSphere ESXi имеет в общей сложности 10 виртуальных сетевых адаптеров и 62 виртуальных дисков на одну виртуальную машину.
Лимиты хост-сервера
VMware vSphere имеет в общей сложности 120 виртуальных машин на узел, при этом объем оперативной памяти составляет 2048 ГБ, а общий объем виртуальных дисков - 2048 на узел.
XenServer имеет в общей сложности 75 виртуальных машин на узел с оперативной памятью 1024 ГБ и 512 виртуальных дисков.
Обе системы имеют 160 логических ЦП на узел, а VMware может иметь в общей сложности 2048 виртуальных ЦП на узел. Однако на сервере XenServer нет виртуальных ЦП.
Функции управления виртуализацией
Одной из областей, где эти программы, как правило, отличаются друг от друга, и в значительной степени объясняют различия между ними в уровнях потребления и принятия запроса, является управление виртуализацией.
Единственной функцией управления ключами, поддерживаемой обеими продуктами, является тонкая резервация памяти.
Несмотря на то, что VMware не поддерживает управление активами и сопоставление конфигураций, XenServer поддерживает эти две функции управления в дополнение к "тонкому" выделению ресурсов, но не поддерживает такие ключевые функции, как динамическое выделение ресурсов, переключение на резервный ресурс и динамическая миграция. С другой стороны, эти три важные функции полностью поддерживаются VMware vSphere ESXi.
Однако следует отметить, что при поиске других дополнительных функций, таких как автоматизированные рабочие процессы, высокая доступность (HA), режим обслуживания, общий пул ресурсов и резервное копирование/восстановление виртуальных машин, рекомендуется опробовать другие программные средства, такие как VMware vSphere Essentials.
Поддерживаемые операционные системы хоста
Следующей областью, отличающей эти две системы, является поддержка операционных систем хоста. Без сомнения, слабым местом VMware vSphere является количество операционных систем хоста, поддерживаемых программой.
VMware vSphere поддерживает только MS-DOS и Free BSD в качестве хостов.
С другой стороны, Citrix XenServer поддерживает множество операционных систем, таких как Novell Linux Desktop, Red Hat Enterprise Linux AS, Linux ES, Linux WS и Red Hat Linux. Другая поддерживаемая ОС включает Windows 2000 Professional и сервер Windows 98 и 95, Windows Me, Сервер Windows NT, Терминальный сервер Windows NT, Автоматизированное рабочее место Windows NT, Предприятие Windows Server 2003, сеть и стандартные Выпуски и Windows XP Home и профессиональные дополнения.
Поддерживаемые гостевые операционные системы
На этом фронте битва между Citrix XenServer и VMware vSphere ESXi относительно ровная, поскольку обе они поддерживают следующие гостевые операционные системы: Novell Linux Desktop, Red Hat Enterprise Linux AS, Red Hat Linux ES, Red Hat Linux WS, Red Hat Linux, Windows 2000 Professional, Windows 2000 Сервер, Windows 98, Windows 95, Windows Me, Сервер Windows NT, сервер терминалов Windows NT, рабочая станция Windows NT, предприятие Windows Server 2003, Windows 2003 Web, Windows 2003 Standard, Windows XP Professional и версия для домашнего использования Windows XP.
Исключением, однако, является то, что VMware поддерживает MS-DOS, Sun Java Desktop System и платформы Solaris x86 в качестве гостевых операционных систем, в то время как Citrix XenServer не поддерживает ни одну из этих трёх операционных систем ни в качестве хоста, ни в качестве гостевой операционной системы.
Техподдержка
Оба этих пакета программного обеспечения поддерживают различные виды технической поддержки, такие как форумы, обучающие видеоролики, онлайн-самообслуживание, базу знаний, обновления системы, телефон и технические документы.
Они также различаются в этой области, поскольку VMware не предоставляет техническую поддержку в виде блогов, брошюр, электронной почты и руководства пользователя, но, что наиболее важно, имеет хорошо укомплектованную службу поддержки, а также предлагает возможность дистанционного обучения.
Citrix XenServer, с другой стороны, обеспечивает техническую поддержку через блоги, электронную почту, брошюры и руководство пользователя / владельца, но не предоставляет эту поддержку через службу поддержки или посредством дистанционного обучения.
Заключение
На рынке VMware vSphere ESXi одержит победу над конкурентом. Теперь, когда вы знаете больше о обоих продуктах, вы можете определить, что лучше всего подходит для вашей карьеры.
Перед начало убедитесь, что ознакомились с материалом про построение деревьев в сетях.
Правило кратчайшего пути, является скорее отрицательным, чем положительным экспериментом; его всегда можно использовать для поиска пути без петель среди набора доступных путей, но не для определения того, какие другие пути в наборе также могут оказаться свободными от петель. Рисунок 4 показывает это.
На рисунке 4 легко заметить, что кратчайший путь от A до пункта назначения проходит по пути [A, B, F]. Также легко заметить, что пути [A, C, F] и [A, D, E, F] являются альтернативными путями к одному и тому же месту назначения. Но свободны ли эти пути от петель? Ответ зависит от значения слова "без петель": обычно путь без петель - это такой путь, при котором трафик не будет проходить через какой-либо узел (не будет посещать какой-либо узел в топологии более одного раза). Хотя это определение в целом хорошее, его можно сузить в случае одного узла с несколькими следующими переходами, через которые он может отправлять трафик в достижимый пункт назначения. В частности, определение можно сузить до:
Путь является свободным от петель, если устройство следующего прыжка не пересылает трафик к определенному месту назначения обратно ко мне (отправляющему узлу).
В этом случае путь через C, с точки зрения A, можно назвать свободным от петель, если C не пересылает трафик к месту назначения через A. Другими словами, если A передает пакет C для пункта назначения, C не будет пересылать пакет обратно к A, а скорее пересылает пакет ближе к пункту назначения. Это определение несколько упрощает задачу поиска альтернативных путей без петель. Вместо того, чтобы рассматривать весь путь к месту назначения, A нужно только учитывать, будет ли какой-либо конкретный сосед пересылать трафик обратно самому A при пересылке трафика к месту назначения.
Рассмотрим, например, путь [A, C, F]. Если A отправляет пакет C для пункта назначения за пределами F, переправит ли C этот пакет обратно в A? Доступные пути для C:
[C, A, B, F], общей стоимостью 5
[C, A, D, E], общей стоимостью 6
[C, F], общей стоимостью 2
Учитывая, что C собирается выбрать кратчайший путь к месту назначения, он выберет [C, F] и, следовательно, не будет пересылать трафик обратно в A. Превращая это в вопрос: почему C не будет перенаправлять трафик обратно в A? Потому что у него есть путь, стоимость которого ниже, чем у любого пути через A до места назначения. Это можно обобщить и назвать downstream neighbor:
Любой сосед с путем, который короче локального пути к месту назначения, не будет возвращать трафик обратно ко мне (отправляющему узлу).
Или, скорее, учитывая, что локальная стоимость представлена как LC, а стоимость соседа представлена как NC, тогда:
Если NC LC, то тогда neighbor is downstream.
Теперь рассмотрим второй альтернативный путь, показанный на рисунке 4: [A, D, E, F]. Еще раз, если A отправляет трафик к пункту назначения к D, будет ли D зацикливать трафик обратно к A?
Имеющиеся у D пути:
[D, A, C, F], общей стоимостью 5
[D, A, B, F], общей стоимостью 4
[D, E, F], общей стоимостью 3
Предполагая, что D будет использовать кратчайший доступный путь, D будет пересылать любой такой трафик через E, а не обратно через A. Это можно обобщить и назвать альтернативой без петель (Loop-Free Alternate -LFA):
Любой сосед, у которого путь короче, чем локальный путь к месту назначения, плюс стоимость доступа соседа ко мне (локальный узел), не будет возвращать трафик обратно ко мне (локальному узлу).
Или, скорее, учитывая, что локальная стоимость обозначена как LC, стоимость соседа обозначена как NC, а стоимость обратно для локального узла (с точки зрения соседа) - BC:
Если NC + BC LC, то сосед - это LFA.
Есть две другие модели, которые часто используются для объяснения Loop-Free Alternate: модель водопада и пространство P/Q. Полезно посмотреть на эти модели чуть подробнее.
Модель водопада (Waterfall (or Continental Divide) Model).
Один из способов предотвратить образование петель в маршрутах, рассчитываемых плоскостью управления, - просто не объявлять маршруты соседям, которые пересылали бы трафик обратно мне (отправляющему узлу). Это называется разделенным горизонтом (split horizon). Это приводит к концепции трафика, проходящего через сеть, действующую как вода водопада или вдоль русла ручья, выбирая путь наименьшего сопротивления к месту назначения, как показано на рисунке 5.
На рисунке 5, если трафик входит в сеть в точке C (в источнике 2) и направляется за пределы E, он будет течь по правой стороне кольца. Однако, если трафик входит в сеть в точке A и предназначен для выхода за пределы E, он будет проходить по левой стороне кольца. Чтобы предотвратить зацикливание трафика, выходящего за пределы E, в этом кольце, одна простая вещь, которую может сделать плоскость управления, - это либо не позволить A объявлять пункт назначения в C, либо не позволить C объявлять пункт назначения в A. Предотвращение одного из этих двух маршрутизаторов от объявления к другому называется разделенным горизонтом (split horizon), потому что это останавливает маршрут от распространения через горизонт, или, скорее, за пределами точки, где любое конкретное устройство знает, что трафик, передаваемый по определенному каналу, будет зациклен.
Split horizon реализуется только за счет того, что устройству разрешается объявлять о доступности через интерфейсы, которые оно не использует для достижения указанного пункта назначения. В этом случае:
D использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
C использует D для достижения пункта назначения, поэтому он не будет объявлять о доступности D
B использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
A использует B для достижения пункта назначения, поэтому он не будет объявлять о доступности B
Следовательно, A блокирует B от знания альтернативного пути, который он имеет к месту назначения через C, а C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петель пересекает этот разделенный горизонт. точка в сети. На рис. 12-5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направляемый в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. C, в терминах LFA, является нижестоящим соседом A.
Следовательно, A блокирует B от знания об альтернативном пути, который он имеет к месту назначения через C, и C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петли будет пересекать эту точку split horizon в сети. На рисунке 5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направленный в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. В терминах LFA, С является нижестоящим соседом (downstream neighbor) A.
P/Q пространство
Еще одна модель, описывающая, как работают LFA, - это пространство P / Q.
Рисунок 6 иллюстрирует эту модель.
Проще всего начать с определения двух пространств.
Предполагая, что линия связи [E, D] должна быть защищена от сбоя:
Рассчитайте Shortest Path Tree из E (E использует стоимость путей к себе, а не стоимость от себя, при вычислении этого дерева, потому что трафик течет к D по этому пути).
Удалите линию связи [E,D] вместе с любыми узлами, доступными только при прохождении через эту линию.
Остальные узлы, которых может достичь E, - это пространство Q.
Рассчитайте Shortest Path Tree из D.
Удалите канал [E, D] вместе со всеми узлами, доступными только при прохождении по линии.
Остальные узлы, которых может достичь D, находятся в пространстве P.
Если D может найти маршрутизатор в пространстве Q, на который будет перенаправляться трафик в случае отказа канала [E, D]- это LFA.
Удаленные (remote) Loop-Free Alternates
Что делать, если нет LFA? Иногда можно найти удаленную альтернативу без петель (remote Loop-Free Alternate - rLFA), которая также может передавать трафик к месту назначения. RLFA не подключен напрямую к вычисляющему маршрутизатору, а скорее находится на расстоянии одного или нескольких переходов. Это означает, что трафик должен передаваться через маршрутизаторы между вычисляющим маршрутизатором и remote next hop. Обычно это достигается путем туннелирования трафика.
Эти модели могут объяснить rLFA, не обращая внимания на математику, необходимую для их расчета. Понимание того, где кольцо "разделится" на P и Q, или на две половины, разделенные split horizon, поможет вам быстро понять, где rLFA можно использовать для обхода сбоя, даже если LFA отсутствует. Возвращаясь к рисунку 6, например, если канал [E, D] выходит из строя, D должен просто ждать, пока сеть сойдется, чтобы начать пересылку трафика к месту назначения. Лучший путь от E был удален из дерева D из-за сбоя, и E не имеет LFA, на который он мог бы пересылать трафик.
Вернитесь к определению loop-free path, с которого начался этот раздел-это любой сосед, к которому устройство может перенаправлять трафик без возврата трафика. Нет никакой особой причины, по которой сосед, которому устройство отправляет пакеты в случае сбоя локальной линии связи, должен быть локально подключен. В разделе "виртуализация сети" описывается возможность создания туннеля или топологии наложения, которая может передавать трафик между любыми двумя узлами сети.
Учитывая возможность туннелирования трафика через C, поэтому C пересылает трафик не на основе фактического пункта назначения, а на основе заголовка туннеля, D может пересылать трафик непосредственно на A, минуя петлю. Когда канал [E, D] не работает, D может сделать следующее:
Вычислите ближайшую точку в сети, где трафик может быть туннелирован и не вернется к самому C.
Сформируйте туннель к этому маршрутизатору.
Инкапсулируйте трафик в заголовок туннеля.
Перенаправьте трафик.
Примечание. В реальных реализациях туннель rLFA будет рассчитываться заранее, а не рассчитываться во время сбоя. Эти туннели rLFA не обязательно должны быть видимы для обычного процесса пересылки. Эта информация предоставлена для ясности того, как работает этот процесс, а не сосредоточен на том, как он обычно осуществляется.
D будет перенаправлять трафик в пункт назначения туннеля, а не в исходный пункт назначения - это обходит запись локальной таблицы переадресации C для исходного пункта назначения, что возвращает трафик обратно в C. Расчет таких точек пересечения будет обсуждаться в чуть позже в статьях, посвященных первому алгоритму кратчайшего пути Дейкстры.