이런 일이 생기는 이유
ping은 ICMP를 사용하지만 SSH와 HTTPS는 TCP 포트를 사용합니다. 서로 다른 트래픽이므로 방화벽은 하나를 버리고 다른 하나는 통과시킬 수 있습니다. 많은 네트워크와 클라우드 보안 그룹은 기본적으로 ICMP 에코를 차단합니다. 따라서 응답이 없다고 서버가 중단된 것은 아니며, 응답이 있다고 서비스가 작동한다는 증거도 아닙니다.
ping 대신 서비스를 테스트하세요
실제로 필요한 포트와 프로토콜을 확인하세요. 이 테스트들이 성공하면 해당 서비스로 서버에 접근할 수 있다는 뜻이며, ping 실패는 경로 어딘가에 필터가 있다는 사실만 보여 줍니다.
nc -vz -w 5 server.example 22
nc -vz -w 5 server.example 443
curl -sSI https://server.example/TCP로 경로 추적하기
ICMP나 UDP가 필터링되면 일반적인 traceroute에는 별표만 표시될 수 있습니다. 열린 포트로 TCP를 사용하면 더 먼 구간까지 확인할 수 있는 경우가 많습니다. 이 작업에는 root가 필요하며, 최소 구성 시스템에는 traceroute가 포함되지 않으므로 먼저 설치해야 할 수도 있습니다.
sudo traceroute -T -p 443 server.example서버에서 필터 찾기
서버를 관리하고 있다면 서버 방화벽과 에코 요청을 무시하는 커널 설정을 확인하세요. 차단 지점이 서버 외부의 보안 그룹이나 라우터일 수도 있고, 제공업체가 사용자에게 규칙이 보이지 않는 상태로 자체 네트워크에서 ICMP를 필터링할 수도 있다는 점을 기억하세요.
sysctl net.ipv4.icmp_echo_ignore_all
sudo nft list ruleset | grep -i icmp
sudo ufw status verboseICMP 차단이 실제 장애를 일으키는 경우
에코 차단은 대부분 무해하지만 모든 ICMP를 차단하는 것은 그렇지 않습니다. 경로 MTU 탐색은 패킷이 너무 크다는 메시지에 의존합니다. 이 메시지가 없으면 작은 데이터 교환은 되지만 큰 데이터 교환은 멈춥니다. 예를 들어 SSH 로그인은 성공한 뒤 대량 출력에서 멈출 수 있습니다. IPv6는 ICMPv6에 더욱 의존합니다. 두 번째 명령은 Linux에서 MTU 1500바이트에 대한 경로를 테스트합니다.
ip route get 192.0.2.10
ping -M do -s 1472 -c 3 192.0.2.10CH-J Server Manager에서 비교하기
Server Diagnostics는 root 없이 시스템 도구로 ping을 실행하고, TCP, SSH 식별, HTTP, TLS를 각각 별도로 테스트하므로 다른 결과와 함께 ping 실패를 해석할 수 있습니다. 여기서 ping 실패는 응답이 도착하지 않았다는 뜻입니다. 패킷이 어디서 버려졌는지는 알려 주지 않으며 traceroute로도 이를 알아내지 못할 수 있습니다.