По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
У вас проблемы с доступом к удаленному серверу через 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]
Модель Open Systems Interconnection (OSI) – это скелет, фундамент и база всех сетевых сущностей. Модель определяет сетевые протоколы, распределяя их на 7 логических уровней. Важно отметить, что в любом процессе, управление сетевой передачей переходит от уровня к уровню, последовательно подключая протоколы на каждом из уровней.
Видео: модель OSI за 7 минут
Нижние уровни отвечают за физические параметры передачи, такие как электрические сигналы. Да – да, сигналы в проводах передаются с помощью представления в токи :) Токи представляются в виде последовательности единиц и нулей (1 и 0), затем, данные декодируются и маршрутизируются по сети. Более высокие уровни охватывают запросы, связанные с представлением данных. Условно говоря, более высокие уровни отвечают за сетевые данные с точки зрения пользователя.
Модель OSI была изначально придумана как стандартный подход, архитектура или паттерн, который бы описывал сетевое взаимодействие любого сетевого приложения. Давайте разберемся поподробнее?
#01: Физический (physical) уровень
На первом уровне модели OSI происходит передача физических сигналов (токов, света, радио) от источника к получателю. На этом уровне мы оперируем кабелями, контактами в разъемах, кодированием единиц и нулей, модуляцией и так далее.
Среди технологий, которые живут на первом уровне, можно выделить самый основной стандарт - Ethernet. Он есть сейчас в каждом доме.
Отметим, что в качестве носителя данных могут выступать не только электрические токи. Радиочастоты, световые или инфракрасные волны используются также повсеместно в современных сетях.
Сетевые устройства, которые относят к первому уровню это концентраторы и репитеры – то есть «глупые» железки, которые могут просто работать с физическим сигналом, не вникая в его логику (не декодируя).
#02: Канальный (data Link) уровень
Представьте, мы получили физический сигнал с первого уровня – физического. Это набор напряжений разной амплитуды, волн или радиочастот. При получении, на втором уровне проверяются и исправляются ошибки передачи. На втором уровне мы оперируем понятием «фрейм», или как еще говорят «кадр». Тут появляются первые идентификаторы – MAC – адреса. Они состоят из 48 бит и выглядят примерно так: 00:16:52:00:1f:03.
Канальный уровень сложный. Поэтому, его условно говоря делят на два подуровня: управление логическим каналом (LLC, Logical Link Control) и управление доступом к среде (MAC, Media Access Control).
На этом уровне обитают такие устройства как коммутаторы и мосты. Кстати! Стандарт Ethernet тоже тут. Он уютно расположился на первом и втором (1 и 2) уровнях модели OSI.
#03: Сетевой (network) уровень
Идем вверх! Сетевой уровень вводит термин «маршрутизация» и, соответственно, IP – адрес. Кстати, для преобразования IP – адресов в MAC – адреса и обратно используется протокол ARP.
Именно на этом уровне происходит маршрутизация трафика, как таковая. Если мы хотим попасть на сайт wiki.merionet.ru, то мы отправляем DNS – запрос, получаем ответ в виде IP – адреса и подставляем его в пакет. Да – да, если на втором уровне мы используем термин фрейм/кадр, как мы говорили ранее, то здесь мы используем пакет.
Из устройств здесь живет его величество маршрутизатор :)
Процесс, когда данные передаются с верхних уровней на нижние называется инкапсуляцией данных, а когда наоборот, наверх, с первого, физического к седьмому, то этот процесс называется декапсуляцией данных
#04: Транспортный (transport) уровень
Транспортный уровень, как можно понять из названия, обеспечивает передачу данных по сети. Здесь две основных рок – звезды – TCP и UDP. Разница в том, что различный транспорт применяется для разной категории трафика. Принцип такой:
Трафик чувствителен к потерям - нет проблем, TCP (Transmission Control Protocol)! Он обеспечивает контроль за передачей данных;
Немного потеряем – не страшно - по факту, сейчас, когда вы читаете эту статью, пару пакетов могло и потеряться. Но это не чувствуется для вас, как для пользователя. UDP (User Datagram Protocol) вам подойдет. А если бы это была телефония? Потеря пакетов там критична, так как голос в реальном времени начнет попросту «квакать»;
#05: Сеансовый (session) уровень
Попросите любого сетевого инженера объяснить вам сеансовый уровень. Ему будет трудно это сделать, инфа 100%. Дело в том, что в повседневной работе, сетевой инженер взаимодействует с первыми четырьмя уровнями – физическим, канальным, сетевым и транспортным. Остальные, или так называемые «верхние» уровни относятся больше к работе разработчиков софта :) Но мы попробуем!
Сеансовый уровень занимается тем, что управляет соединениями, или попросту говоря, сессиями. Он их разрывает. Помните мем про «НЕ БЫЛО НИ ЕДИНОГО РАЗРЫВА»? Мы помним. Так вот, это пятый уровень постарался :)
#06 Уровень представления (presentation)
На шестом уровне творится преобразование форматов сообщений, такое как кодирование или сжатие. Тут живут JPEG и GIF, например. Так же уровень ответственен за передачу потока на четвертый (транспортный уровень).
#07 Уровень приложения (application)
На седьмом этаже, на самой верхушке айсберга, обитает уровень приложений! Тут находятся сетевые службы, которые позволяют нам, как конечным пользователям, серфить просторы интернета. Гляньте, по какому протоколу у вас открыта наша база знаний? Правильно, HTTPS. Этот парень с седьмого этажа. Еще тут живут простой HTTP, FTP и SMTP.
Существует новая тенденция для стандартов проектирования топологии сети - создание быстрой, предсказуемой, масштабируемой и эффективной коммуникационной архитектуры в среде центра обработки данных. Речь идет о топологии Leaf-Spine, о которой мы поговорим в этой статье.
Почему Leaf-Spine?
Учитывая повышенный фокус на массовые передачи данных и мгновенные перемещения данных в сети, стареющие трехуровневые конструкции в центрах обработки данных заменяются так называемым дизайном Leaf-Spine. Архитектура Leaf-Spine адаптируется к постоянно меняющимся потребностям компаний в отраслях big data с развивающимися центрами обработки данных.
Другая модель
Традиционная трехуровневая модель была разработана для использования в общих сетях. Архитектура состоит из Core маршрутизаторов, Aggregation маршрутизаторов (иногда этот уровень называется Distribution) и Access коммутаторов. Эти устройства взаимосвязаны путями для резервирования, которые могут создавать петли в сети. Частью дизайна является протокол Spanning Tree (STP) , предотвращающий петли, однако в этом случае деактивируется все, кроме основного маршрута и резервный путь используется только тогда, когда основной маршрут испытывает перебои в работе.
Введение новой модели
С конфигурацией Leaf-Spine все устройства имеют точно такое же количество сегментов и имеют предсказуемую и согласованную задержку информации. Это возможно из-за новой конструкции топологии, которая имеет только два слоя: слой «Leaf» и «Spine». Слой Leaf состоит из access коммутаторов, которые подключаются к таким устройствам как сервера, фаерволы, балансировщики нагрузки и пограничные маршрутизаторы. Уровень Spine, который состоит из коммутаторов, выполняющих маршрутизацию, является основой сети, где каждый коммутатор Leaf взаимосвязан с каждым коммутатором Spine.
Чтобы обеспечить предсказуемое расстояние между устройствами в этом двухуровневом дизайне, динамическая маршрутизация уровня 3 используется для соединения уровней. Она позволяет определить наилучший маршрут и настроить его с учетом изменения сети. Этот тип сети предназначен для архитектур центров обработки данных, ориентированных на сетевой трафик типа «Восток-Запад» (East-West). Такой трафик содержит данные, предназначенные для перемещения внутри самого центра обработки данных, а не наружу в другую сеть. Этот новый подход является решением внутренних ограничений Spanning Tree с возможностью использования других сетевых протоколов и методологий для достижения динамической сети.
Преимущества Leaf-Spine
В Leaf-Spine сеть использует маршрутизацию 3го уровня. Все маршруты сконфигурированы в активном состоянии с использованием протокола равноудаленных маршрутов Equal-Cost Multipathing (ECMP) . Это позволяет использовать все соединения одновременно, сохраняя при этом стабильность и избегая циклов в сети. При использовании традиционных протоколов коммутации уровня 2, таких как Spanning Tree в трехуровневых сетях, он должен быть настроен на всех устройствах правильно, и все допущения, которые использует протокол Spanning Tree Protocol (STP), должны быть приняты во внимание (одна из простых ошибок, когда конфигурация STP связана с неправильным назначением приоритетов устройства, что может привести к неэффективной настройке пути). Удаление STP между уровнями Access и Aggregation приводит к гораздо более стабильной среде.
Другим преимуществом является простота добавления дополнительного оборудования и емкости. Когда происходит ситуация перегрузки линков, которая называется oversubscription (что означает, что генерируется больше трафика, чем может быть агрегировано на активный линк за один раз) возможность расширять пропускную способность проста - может быть добавлен дополнительный Spine коммутатор и входящие линии могут быть расширены на каждый Leaf коммутатор, что приведет к добавлению полосы пропускания между уровнями и уменьшению перегрузки. Когда емкость порта устройства становится проблемой, можно добавить новый Leaf коммутатор. Простота расширения оптимизирует процесс ИТ-отдела по масштабированию сети без изменения или прерывания работы протоколов коммутации уровня 2.
Недостатки Leaf-Spine
Однако этот подход имеет свои недостатки. Самый заметный из них – увеличение количества проводов в этой схеме, из-за соединения каждого Leaf и Spine устройства. А при увеличении новых коммутаторов на обоих уровнях эта проблема будет расти. Из-за этого нужно тщательно планировать физическое расположение устройств.
Другим основным недостатком является использование маршрутизации уровня 3.Ее использование не дает возможность развертывать VLAN’ы в сети. В сети Leaf-Spine они локализованы на каждом коммутаторе отдельно – VLAN на Leaf сегменте недоступен другим Leaf устройствам. Это может создать проблемы мобильности гостевой виртуальной машины в центре обработки данных.
Применение Leaf-Spine
Веб-приложения со статичным расположением сервера получат преимущество от реализации Leaf-Spine. Использование маршрутизации уровня 3 между уровнями архитектуры не препятствует приложениям веб-масштаба, поскольку они не требуют мобильности сервера. Удаление протокола Spanning Tree Protocol приводит к более стабильной и надежной работе сети потоков трафика East-West. Также улучшена масштабируемость архитектуры. Корпоративные приложения, использующие мобильные виртуальные машины (например, vMotion), создают проблему, когда сервер нуждается в обслуживании внутри центра обработки данных, из-за маршрутизации уровня 3 и отсутствие VLAN. Чтобы обойти эту проблему, можно использовать такое решение, как Software Defined Networking (SDN) , которое создает виртуальный уровень 2 поверх сети Leaf-Spine. Это позволяет серверам беспрепятственно перемещаться внутри центра обработки данных.
Другие решения
В качестве альтернативы маршрутизации уровня 3 топология Leaf-and-Spine может использовать другие протоколы, такие как Transparent Interconnection of Lots of Links (TRILL) или Shortest Path Bridging (SPB) для достижения аналогичной функциональности. Это достигается за счет сокращения использования Spanning Tree и включения ECMP уровня 2, а также поддержки развертывания VLAN между Leaf коммутаторами.
Итог
Сети Leaf-Spine предлагают множество уникальных преимуществ по сравнению с традиционной трехуровневой моделью. Использование маршрутизации 3-го уровня с использованием ECMP улучшает общую доступную пропускную способность, используя все доступные линии. Благодаря легко адаптируемым конфигурациям и дизайну, Leaf-Spine улучшает управление масштабируемостью и контролем над перегрузкой линий. Устранение протокола Spanning Tree Protocol приводит к значительному повышению стабильности сети. Используя новые инструменты и имея способность преодолевать присущие ограничения другими решениям, такими как SDN, среды Leaf-Spine позволяют ИТ-отделам и центрам обработки данных процветать при удовлетворении всех потребностей и потребностей бизнеса.