.png)
TLDR:클래스가 할당된 가상 머신에서 에뮬레이트된 VM과의 SSH 세션을 종료한 후 Docker 컨테이너/에뮬레이션된 VM에 액세스하는 데 사용되는 ping 추적 경로 및 원본 스크립트의 작동이 중지되었습니다. 이 프로그램은 내 수업에 할당된 호스트 VM 내의 Docker 컨테이너에서 실행되었습니다. 호스트 VM은 Ubuntu에서 실행됩니다.
학교에서 할당한 원격 데스크톱을 복구하고 수업을 계속하려면 ping, 경로 추적 및 원본 스크립트 및 에뮬레이트된 VM에 액세스하는 기능을 수정해야 합니다. 데스크탑 환경을 완전히 재설정해도 문제가 해결되지 않았습니다. SSH가 연결되고 브라우저가 작동하며 Traceroute가 실행되지만 결과는 각 홉에 별표가 3개 있는 30개 홉입니다.
이러한 모든 문제는 에뮬레이트된 VM과의 SSH 세션을 종료한 후 한꺼번에 나타났습니다. 아직 범위를 좁히지 않은 몇 가지 사항이 있습니다(ARP 테이블 및 소켓 인터페이스--업데이트를 위해 내일 다시 올 것입니다.) 적어도 질문이 더 간결해지기를 바랍니다.
문맥
클래스가 할당된 가상 머신에서 작업 중인데 해당 클래스가 할당된 데스크톱 환경에서 다른 가상 머신을 에뮬레이트하는 데 사용되는 프로그램을 종료하는 동안 문제가 발생했습니다. 다음 세부 정보는 제가 작업 중이었던 숙제의 일부이며 원래 수업에 할당된 VM 내에서 에뮬레이트된 VM에서 모두 수행되었습니다.
내 호스트 컴퓨터에서 에뮬레이트된 SSH 서버/VM/Docker 컨테이너를 설정하는 스크립트가 실행되지 않기 때문에 대상 컴퓨터에서 변경한 정확한 파일과 설정을 평가하기 위해 돌아갈 수 없습니다.
호스트 VM으로 돌아가기 전에 에뮬레이트된 VM에서 수행한 작업은 다음과 같습니다.
홈 폴더가 없고, 루트 권한이 있고, UID와 GID가 1000 미만인 사용자를 만들었습니다.
비밀번호 없이 루트 액세스를 허용하도록 sudoers 파일을 구성했습니다.
sshd_config포트 22가 아닌 다른 포트에 대한 SSH 액세스를 허용하도록 파일을 변경했습니다 .sshd_config대상 컴퓨터에서 파일을 포맷하는 동안 포트 22를 포트 2222로 재정의하는 실수를 저질렀습니다.
이는 현재 포트 목록 아래에 sshd_config다음과 같이 추가 행을 추가하여 수행되었습니다.
#Port 22
#Port 2222
파일을 편집하러 갔을 때 포트 22가 주석 처리되어 있었고 포트 22를 통해 대상 컴퓨터에 문제 없이 액세스할 수 있었기 때문에 당시에는 아무 것도 생각하지 못했습니다.
주석이 달린 포트가 왜 여전히 작동하는지에 대한 답변이 없으며 이것이 현재 호스트 VM에서 겪고 있는 문제를 일으킬 수 있는 방법도 없습니다.
내 호스트 VM의 포트가 열려 있고 작동하고 있습니다.
이것은 잠재적으로 무시할 수 있는 추가 정보일 수 있지만 이러한 변경을 수행하고 대상 컴퓨터를 종료한 직후 호스트 컴퓨터에서 문제를 발견했습니다. 대상 컴퓨터와 상호 작용을 시작하기 전에는 이러한 문제가 발생하지 않았습니다. Docker 컨테이너를 사용하여 SSH 세션을 부적절하게 시작하거나 종료함으로써 발생할 수 있는 문제가 있는 경우 세션 자체를 현재 문제에 연결하는 것보다 훨씬 더 가능성 있는 해결 방법입니다.
Docker/에뮬레이트된 VM 시작 관련 문제
이 경우 Docker는 스크립트에서 실행되는 SSH 서버의 에뮬레이션이기 때문에 대상 머신에 액세스해야 합니다. 이 기능이 없으면 대상 컴퓨터에 액세스할 수 없으며 대상 컴퓨터에서 변경한 내용이 호스트 컴퓨터의 문제와 어떻게 연관되는지 문제를 해결할 수 없습니다.
에뮬레이트된 VM 시작 메시지는 Docker가 실행 중이지만 대상 시스템에 액세스하는 데 필요한 스크립트를 시작하지 않음을 나타냅니다. 오류 메시지는 다음과 같습니다.
앱이 실행되지 않습니다. 뭔가 잘못되었다.
VM을 다시 시작한 다음 Docker를 다시 시작해 보세요.
그런 다음 스크립트를 다시 실행하십시오.
Docker를 다시 시작해도 이 메시지의 상태는 변경되지 않으며 재부팅되지도 않습니다.또는기계를 재설정합니다. 대상 컴퓨터를 실행하는 스크립트에 문제가 있을 수 있지만 직접 검사해 보면 잘못된 점을 찾을 수 없으며 전체 재설정으로 문제가 해결되지 않을 정도로 호스트 VM을 망칠 수 있는 잘못된 점은 훨씬 적습니다.
Ping 및 Traceroute 관련 문제
대부분의 IP에 대해 ping을 시도하면 첫 번째 줄에서 중단되고 실패 메시지가 표시되지 않으므로 프로세스를 수동으로 종료해야 합니다.
ping -c 3 -w 12 1.1.1.1ping 요청의 수와 기한을 제한하는 데 사용하면 다음이 표시됩니다.
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에 대해 ping을 수행할 수 있으며 0.0.0.0에 대해 ping을 수행하면 정상적으로 작동합니다. 내부 방화벽이 비활성화되고 ICMP가 활성화됩니다.
예제 인터페이스 ping 명령을 사용하면 ping -I interface google.com다음과 같은 출력이 표시됩니다.
ping: SO_BINDTODEVICE interface: No such device
소켓 프로그래밍에 대한 경험이 있다면 여기에 있는 조언이 매우 중요할 것입니다. 제 생각에는 이것이 문제가 발생할 수 있는 부분일 수 있기 때문입니다.
Traceroute가 실행되지만 유일한 출력은 각각 3개의 별표를 표시하는 30홉입니다.
시도한 솔루션
내 로컬 시스템의 구성 파일은 대상 시스템에서 기록한 구성 파일 변경 사항을 반영하지 않으므로 대상 시스템의 설정을 조작해도 로컬 시스템에 영향을 주어서는 안 되며 실수로 로컬 시스템의 구성을 변경하지 않았습니다. 그것이 목표 기계라고 생각했습니다.
나~이다localhost 및 127.0.0.1에 대해 ping을 수행할 수 있으며 0.0.0.0에 대해 ping을 수행하면 정상적으로 작동합니다.
내부 방화벽이 비활성화되고 ICMP가 활성화됩니다.
로컬 VM의 전체 시스템 재설정을 수행했는데 ping, 경로 추적 및 Docker/에뮬레이트된 VM이 여전히 오작동합니다. 전체 시스템을 재설정한 후에도 구성 문제가 멈춘다는 사실은 나에게 매우 혼란스럽지만 원인을 좁힐 수 있습니다. 전체 시스템 재설정을 통해 일관되게 유지되는 시스템 설정 또는 네트워킹 오작동이 있습니까?
가상 머신에 대한 대안이 있지만 특정 프로젝트에 백업 VM을 사용할 수 없기 때문에 여전히 이 문제는 시간에 민감한 문제라고 생각합니다. 질문을 편집하고 잠재적인 옵션을 살펴보면서 이미 시도한 더 많은 솔루션을 통해 명확하게 설명하겠습니다.
아직 시도되지 않은 잠재적인 솔루션
소켓 구성.
ARP 테이블 구성.
에뮬레이트된 VM 시작 프로세스와 정확히 어디에서 실패하는지에 대한 추가 조사입니다.
전체 시스템 재설정에도 불구하고 문제가 동일하게 유지되는 이유에 대한 추가 조사입니다.
포괄적인 답변은 필요하지 않으며 올바른 방향을 가리키는 지침만 있으면 됩니다! 내일 계속 업데이트하겠습니다. 아직 배제해야 할 것이 많습니다.
답변1
이 질문은 해결되었으며 이는 개인 후손에게 달려 있습니다. 호스트 VM은 ping을 제대로 실행하도록 구성되지 않았습니다. 구성 파일 내에서 근본적인 문제가 발생했다고 가정하면서 ping에 사용할 수 있는 다양한 문제 해결 각도를 시도하느라 바빴기 때문에 고려하지 않았습니다.
강의 강사에게 연락했더니 그는 호스트 VM을 재설정하여 에뮬레이트된 VM을 시작하는 데 사용되는 Docker 컨테이너를 수정했고, ping 및 경로 추적 문제가 시스템 자체의 일부인 것으로 명확히 설명했습니다.
특히 나중에 소켓 프로그래밍에 대해 더 많은 질문을 할 수도 있지만 결국 현재 상황과 관련이 없게 되었습니다.