☰

SYN ACK 후 TCP 재설정은 "호스트에 대한 경로 없음"과 관련될 수 있습니다.

tag-icon • tag-icon routing tcp handshake
SYN ACK 후 TCP 재설정은 "호스트에 대한 경로 없음"과 관련될 수 있습니다.

클라이언트 중 하나가 서버에 대한 TCP 연결을 시작하려고 시도했지만 실패하는 문제가 발생했습니다.

tcpdump클라이언트 장치가 SYN패킷을 보내고 서버가 올바르게 응답하는 것을 확인했습니다 SYN ACK. 그 직후에 서버가 RST패킷을 수신합니다. 몇 초 후에 프로세스가 반복됩니다. 이상하게 연결이 제대로 되는 경우가 가끔 있습니다(약 이틀에 한번씩 오전 8시 30분경).

패킷을 다른 서버로 리디렉션하려고 시도했지만 해당 서버에도 동일한 문제가 있었습니다.

오늘은 반대로 연결해 봤습니다. 우리 클라이언트는 현재 방화벽에 포트가 열려 있지 않지만 무슨 일이 일어나는지 확인하기 위해 어쨌든 연결을 시도했습니다. ssh다른 컴퓨터에서 연결을 시도했는데 이것이 내가 찾은 것입니다 .

내 개인용 컴퓨터(Mac OS X 10.10)에서:ssh: connect to host x.x.x.x port 22: Connection refused

패킷을 수신하는 서버에서 SYN(Debian 8):ssh: connect to host x.x.x.x port 22: No route to host

다른 호스팅 센터의 다른 서버(Debian 7)에서:ssh: connect to host x.x.x.x port 22: No route to host

대기업의 다른 서버(Debian 7)에서:ssh: connect to host x.x.x.x port 22: Operation timed out

집에 있는 PC에서 얻은 응답은 방화벽에서 포트가 열려 있지 않은 경우 예상했던 것과 정확히 일치하지만, 다른 서버에서 얻는 출력이 다르기 때문에 혼란스럽습니다.

이러한 컴퓨터 중 하나에서 클라이언트의 IP를 ping하면 정상적으로 작동합니다.

SYN-ACK내 패키지가 잘못 라우팅되어 (거의) 클라이언트에 도달하지 못하는 라우팅 문제가 있습니까 ? 이 문제를 해결하는 방법에 대한 제안 사항이 있습니까? 고객의 ISP나 서버 제공업체에 문의해야 합니까?

당신의 도움을 주셔서 감사합니다.

업데이트 1:

나는 Jeff의 질문에 대해 좀 더 조사해 보았습니다. 내 결과는 다음과 같습니다. IP TTL SYN: 55 IP TTL RST: 59 현재 클라이언트가 자신의 네트워크에 대한 액세스 권한을 부여하기를 기다리고 있으므로 클라이언트가 이를 수신했는지 SYN-ACK전송했는지 확인할 수 없습니다.RST

Traceroute: 1 x.x.x.x 25.793 ms 5.516 ms 5.516 ms 2 x.x.x.x 4.140 ms 4.172 ms 4.166 ms 3 x.x.x.x 4.158 ms 4.147 ms 4.139 ms 4 x.x.x.x 9.855 ms 9.877 ms 9.874 ms 5 x.x.x.x 15.506 ms !X 15.753 ms !X 15.970 ms !X 내 컴퓨터의 Traceroute는 마지막 두 홉에서 동일합니다. 두 추적 경로 모두 5개의 홉을 갖습니다.

서버 측에는 방화벽이나 로드 밸런서가 없습니다.

라우팅 테이블은 no route to host주로 기본 경로와 로컬 서브넷 경로로 구성되며 다른 모든 경우에는 잘 작동합니다.

답변1

질문을 할 만큼 충분한 평판이 없기 때문에 답변보다는 질문에 가깝습니다. 하지만 올바른 방향을 제시하거나 다른 사람들이 문제에 대해 더 많은 통찰력을 제공할 수 있도록 해야 합니다.

-What is the IP TTL (or hop limit if IPv6) in the SYN and RST?
-What does a capture from the client show?  
    -Does it receive the SYN-ACK, and does it send the RST?
-What does a traceroute look like?
    -How many hops between the server and the client?  
-Is there a firewall, load balancer or other network 
 device fronting  (NAT, VIP) the server?
-What do the routing tables look like for the servers 
 receiving the No Route to Host?

답변2

모든 것은 구성 문제로 귀결됩니다. 오늘 한 고객이 자신의 네트워크에 대한 액세스를 허용했으며 기본적으로 그의 네트워크에서 라우팅 문제를 일으키는 동일한 IP 주소를 가진 두 개의 장치가 있다는 것을 발견했습니다.

IP 주소 중 하나가 변경되었습니다. 해결되었습니다.

당신의 도움을 주셔서 감사합니다.

관련 정보