.png)
Краткий обзор:На виртуальной машине, назначенной классом, ping traceroute и оригинальный скрипт, используемый для доступа к контейнеру Docker/эмулированной виртуальной машине, перестали работать после выхода из сеанса SSH с эмулированной виртуальной машиной. Эта программа была запущена из контейнера Docker в моей назначенной классом виртуальной машине хоста. Виртуальная машина хоста работает на Ubuntu.
Мне нужно исправить ping, traceroute и возможность доступа к исходному скрипту и эмулированной виртуальной машине, чтобы восстановить назначенный мне школой удаленный рабочий стол и продолжить выполнять классную работу. Полный сброс среды рабочего стола не решил проблему. SSH подключается, браузер работает, traceroute запускается, но результаты — 30 переходов с тремя звездочками для каждого перехода.
Все эти проблемы проявились сразу после выхода из сеанса SSH с эмулированной виртуальной машиной. Есть пара вещей, которые я пока не сузил (таблицы ARP и интерфейс сокетов — вернусь завтра, чтобы обновить). Надеюсь, это хотя бы сделает вопрос более кратким.
Контекст
Я работаю с виртуальной машины, назначенной классу, и столкнулся с проблемами при выходе из программы, используемой для эмуляции другой виртуальной машины в среде рабочего стола, назначенной этому классу. Следующие детали являются частью домашнего задания, над которым я работал, и все они были выполнены в эмулированной виртуальной машине внутри этой исходной виртуальной машины, назначенной этому классу.
Я не могу вернуться назад, чтобы оценить точные файлы и настройки, которые я изменил на целевой машине, поскольку скрипт для настройки эмулируемого SSH-сервера/виртуальной машины/контейнера Docker на моей хост-машине не запускается.
Вот что я сделал на эмулируемой виртуальной машине, прежде чем вернуться на свою хостовую виртуальную машину.
Я создал пользователя без домашней папки, с правами root и UID и GID ниже 1000.
Я настроил файл sudoers так, чтобы разрешить root-доступ без пароля.
Я изменил
sshd_configфайл, чтобы разрешить доступ по SSH к порту, отличному от порта 22.При форматировании
sshd_configфайла на целевой машине я допустил ошибку, из-за которой порт 22 был переопределен портом 2222.
Это было сделано путем добавления дополнительной строки под текущим списком портов, так что это sshd_configвыглядело так:
#Port 22
#Port 2222
Когда я начал редактировать файл, порт 22 был закомментирован, и мне удалось получить доступ к целевой машине через порт 22 без проблем, поэтому в тот момент я не придал этому значения.
У меня нет ответов на вопрос, почему закомментированный порт все равно будет работать, и я не вижу никаких причин, по которым это могло бы вызвать текущие проблемы, которые у меня возникают с моей хостовой виртуальной машиной.
Порты на моей виртуальной машине открыты и функционируют.
Это может быть потенциально незначительной дополнительной информацией, но я заметил проблемы на своей хост-машине сразу после внесения этих изменений и выхода из целевой машины. Этих проблем не было до того, как я начал взаимодействовать с целевой машиной. Если есть проблемы, которые могут возникнуть просто из-за неправильного входа или выхода из сеанса SSH с контейнером Docker, это гораздо более вероятное решение, чем привязка самого сеанса к текущим проблемам.
Проблемы с Docker/Запуск эмулированной виртуальной машины
В этом случае Docker требуется для доступа к целевой машине, поскольку это эмуляция SSH-сервера, запущенного из скрипта. Без этой функции я не смогу получить доступ к целевой машине и устранить неполадки, связанные с тем, как изменения, внесенные мной в целевую машину, соотносятся с проблемами на моей хост-машине.
Эмулированное сообщение о запуске виртуальной машины указывает, что Docker запущен, но не запускает требуемый скрипт для доступа к целевой машине. Вот сообщение об ошибке:
Приложения не запускаются. Что-то не так.
Попробуйте перезапустить виртуальную машину, а затем перезапустите Docker.
Затем запустите скрипт еще раз.
Перезапуск Docker не изменяет статус этого сообщения, как и перезагрузка.илисброс машины. Возможно, что-то не так со скриптом, запускающим целевую машину, но, проверив его самостоятельно, я не вижу ничего неправильного, тем более ничего неправильного, что могло бы испортить мою хостовую виртуальную машину до такой степени, что полный сброс не решит проблему.
Проблемы с Ping и Traceroute
Когда я пытаюсь выполнить ping для большинства IP-адресов, процесс останавливается на первой же строке, и мне приходится вручную завершать процесс, поскольку сообщение об ошибке не выдается.
Использование ping -c 3 -w 12 1.1.1.1для ограничения количества и крайнего срока запроса ping показывает:
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
--- 1.1.1.1 ping statistics ---
12 packets transmitted, 0 received, 100% >packet loss, time 11249ms
яявляюсьсмог пинговать localhost и 127.0.0.1, а пинг 0.0.0.0 работает нормально. Внутренний брандмауэр отключен, а ICMP включен.
Когда я использую команду ping для интерфейса примера, ping -I interface google.comя получаю вывод
ping: SO_BINDTODEVICE interface: No such device
Если у вас есть опыт программирования сокетов, ваш совет будет бесценным, так как я думаю, что именно здесь что-то идет не так.
Traceroute запускается, но выводит только 30 переходов, каждый из которых отмечен тремя звездочками.
Попытки решения
Файлы конфигурации на моей локальной машине не отражают изменения файлов конфигурации, которые я записал на целевой машине, поэтому любое изменение настроек целевой машины не должно было повлиять на локальную машину, и я не изменил случайно конфигурацию на своей локальной машине, думая, что это целевая машина.
яявляюсьпинговать localhost и 127.0.0.1, а пинговать 0.0.0.0 работает нормально.
Внутренний брандмауэр отключен, а протокол ICMP включен.
Я выполнил полный сброс системы моей локальной виртуальной машины, а ping, traceroute и Docker/эмулированная виртуальная машина все еще работают со сбоями. Тот факт, что проблема конфигурации осталась даже после полного сброса системы, меня очень сбивает с толку, но может сузить круг причин. Есть ли системная настройка или сбой в работе сети, которые останутся неизменными после полного сброса системы?
У меня есть альтернативы моей виртуальной машине, но я все равно посчитал бы это вопросом, чувствительным ко времени, поскольку я не могу использовать свою резервную виртуальную машину для определенных проектов. Я отредактирую вопрос и уточню с помощью дополнительных решений, которые я уже попробовал, по мере того, как буду рассматривать потенциальные варианты.
Потенциальные решения еще не опробованы
Конфигурация сокета.
Конфигурация таблицы ARP.
Дальнейшее исследование процесса запуска эмулируемой виртуальной машины и того, где именно происходит сбой.
Дальнейшее расследование причин, по которым проблемы могли остаться прежними, несмотря на полный сброс системы.
Мне не нужен исчерпывающий ответ, просто указатели в правильном направлении! Продолжу обновлять завтра. Еще много чего нужно исключить.
решение1
Этот вопрос был решен и остается для личных потомков. Хостовая виртуальная машина никогда не была настроена для правильного запуска ping, что я не учел, поскольку был занят попытками различных углов устранения неполадок, доступных для ping, предполагая, что я сломал что-то фундаментальное в файлах конфигурации.
Я связался с преподавателем курса, и он сбросил настройки хостовой виртуальной машины, что исправило контейнер Docker, используемый для запуска эмулируемой виртуальной машины, а также объяснил, что проблемы с ping и traceroute являются частью самой системы.
Я, возможно, задам больше вопросов о программировании сокетов позже, однако в текущей ситуации это оказалось неактуальным.