이 서버가 속한 네트워크 조직이 ISP를 변경하고 있습니다. 이 서버를 IP, 게이트웨이 등의 새로운 값으로 전환하면 더 이상 SSH를 통해 연결할 수 없습니다. 포트 확인 도구 중 하나에 가서 포트 22를 확인했을 때 "포트 22의 _new_IP_value_에서 서비스를 볼 수 없습니다"라는 메시지가 반환되었습니다.
새 IP는 고정 IP입니다. 문제의 서버에는 라우터도 없고 포트 전달도 없습니다. 네트워크 케이블이 서버에 직접 연결됩니다.
당연히 조직의 네트워크나 새 ISP가 포트 22를 차단하고 있다고 생각하여 네트워크 관리자에게 전화하여 열어달라고 요청하거나 ISP에게 열어달라고 요청했습니다. 그는 그렇게 할 것이라고 말했습니다. 그러나 아무것도 바뀌지 않았습니다. 하루 뒤에 같은 질문으로 그에게 전화를 했는데, 그가 바쁘다는 것을 알 수 있었습니다. 그는 내가 요청한 대로 했다고 말하고 기본적으로 전화를 끊었습니다.
그래서 지금은 결국 서버 설정에 뭔가 문제가 있는 것 같아요. 그러나 lsof, netstat, nmap 등과 같은 모든 Linux 도구는 sshd가 실행 중이고 포트 22에서 수신 대기하고 있으며 포트 22가 열려 있다고 알려줍니다. 기존 ISP의 네트워크 - 내가 전환하는 것은 IP, 게이트웨이, DNS뿐입니다.
서버가 새 ISP의 네트워크에 있지만 이전 ISP의 네트워크에는 없을 때 SSH 연결을 차단하는 것이 이 서버에 있을 수 있습니까? OS는 리눅스 민트입니다.
답변1
클라이언트에서 패킷 캡처를 실행하고 서버에서 패킷 캡처를 실행합니다. 가장 일반적인 도구는 Wireshark와 tcpdump입니다.
tcpdump -n -i eth0 "(tcp port 22 or 3389) or icmp or icmp6"
TCP SYN 패킷이 클라이언트에서 나가고 서버에 도착하지 않는 경우 일반적으로 네트워크에 문제가 있는 것입니다. 온라인 포트 확인 도구가 클라이언트 측 ISP가 있을 가능성을 배제했기 때문에 서버의 ISP에 문제가 있을 가능성이 높습니다. 이상한 것.
(관리자가 포트를 전혀 열지 않았거나 올바른 주소로 열지 않았을 수도 있습니다. ISP 수준에서도 포트 3389가 닫히는 것은 드문 일이 아닙니다.)
tcptraceroute패킷이 사라지기 전에 얼마나 멀리 가는지 알아내는 데 도움이 될 수 있을 것 같습니다 .TCP SYN 패킷이 서버에 도착했지만 응답을 받지 못하는 경우조금도, 문제는 서버에 있습니다. 서버의 내부 방화벽일 수 있습니다(tcpdump가 패킷을 가져옴).~ 전에방화벽에 닿았으므로 iptables 규칙이 있는지 확인하세요.그리고nft 규칙.
또한 서버에돌아가는 경로클라이언트에게 전달하고 실제로 올바른 인터페이스를 통해 올바른 게이트웨이로 이동하는지 확인합니다.
ip -4 route get <client_ip> ip -4 route show match <client_ip>또한
systemctl cat sshdcgroup 수준 IP 주소 화이트리스트가 있는지 확인하려면 실행하세요. 또한ip xfrm policyIPsec 정책이 있는지 확인하려면 실행하세요.TCP SYN 패킷이 도착하지만 TCP RST 응답을 생성하는 경우 – 여전히 방화벽일 수도 있고 SSH 데몬이 다음과 같이 구성되었을 수도 있습니다.듣다잘못된 주소로요. (무엇을 언급하지 않았나요?현지 주소"포트 22" 옆에 lsof/netstat가 표시됩니다. 0.0.0.0:22 또는 [::]:22가 표시되면 좋지만 이전 주소가 표시되면 sshd_config에서 변경해야 합니다.)
TCP SYN 패킷이 도착하는 경우 서버에서 SYN/ACK 응답이 나오지만 클라이언트는 이러한 응답을 받지 못합니다. 이는 네트워크 문제이기도 하며 서버 ISP 측에서 발생할 가능성이 가장 높습니다.