동일한 EC2 서브넷의 인스턴스 간에 TCP 연결을 생성할 때 EHOSTUNREACH 오류

동일한 EC2 서브넷의 인스턴스 간에 TCP 연결을 생성할 때 EHOSTUNREACH 오류

동일한 EC2 서브넷에 클라이언트 EC2 인스턴스와 서버 EC2 인스턴스가 있습니다. 서브넷 라우팅 테이블은 "로컬" 라우팅을 위해 구성됩니다.

내가 달릴 때EC2 네트워크 통찰력클라이언트 인스턴스에서 포트 22의 서버 인스턴스까지의 TCP 경로에 대해 성공적으로 경로를 찾습니다. 나에게 이는 보안 그룹과 ACL이 이 트래픽을 허용하는 방식으로 구성되었음을 의미합니다.

telnet <server-ip> 22클라이언트에서 실행하면 "호스트에 대한 경로 없음"이라는 메시지가 나타납니다. strace에서 errno=EHOSTUNREACH로 인해 connect(2)가 실패하는 것을 볼 수 있습니다.

나에게 보안 그룹/ACL/중간 라우팅 문제에 대한 이런 종류의 힌트가 있습니까? 그러나 임의의 포트(해당 포트에서 수신 대기하지 않는 것으로 알고 있음)를 사용하여 서버에서 클라이언트로 텔넷을 실행하면 예상되는 "연결이 거부되었습니다"라는 메시지가 나타납니다.

특히 이상한 점은 VPC 흐름 로그에서 트래픽이 괜찮은 것을 볼 수 있다는 것입니다. 작업은 "수락"이고 로그 상태는 "정상"입니다. 그러면 그런 종류의 보안 그룹/ACL이 괜찮다는 뜻인가요?

내가 달릴 때경로(8)클라이언트 인스턴스에서 서버 인스턴스의 게이트웨이가 0.0.0.0인 것을 볼 수 있는데, 이는 로컬 브로드캐스트 도메인에서만 사용할 수 있음을 나타냅니다. 따라서 중간 라우터가 없는 것 같습니다.

여기서 무슨 일이 일어나고 있는지 또는 추가 디버깅을 위해 무엇을 할 수 있는지 아는 사람이 있습니까? 이상적으로는 인스턴스나 적어도 해당 로그에 액세스할 수 있는 다른 방법이 있을 것입니다.

서버 인스턴스가 TCP에 도달하지 않고 IP 수준에서 트래픽을 거부하는 것 같습니다. 그러나 서버의 IP 계층은 TCP 포트에 대해서도 알 수 없기 때문에 이상해 보입니다.

서버 인스턴스에서 sshd가 실행되고 있다고 생각하므로 이 네트워크 문제를 해결할 수 있다면 아마도 내 인스턴스에 액세스할 수 있을 것입니다.

답변1

확실히firwalld여기에서 서버 인스턴스를 시작했습니다. 따라서 서버는 TCP SYN에 응답하지 않습니다.

관련 정보