"a", "b", "c"라는 세 개의 서버가 있으며 모두 동일한 /24 서브넷 마스크를 사용합니다.
모든 서버에서 nc
TCP 포트 9999와 다른 두 서버 중 하나에는 항상 0.01초가 걸리며, 포트 9694에 대한 UDP는 항상 0.01초가 걸립니다.2.01초.
이는 ncat 7.70이 설치된 RHEL 8.6에 있습니다.
UDP 응답 속도를 늦추는 구성 매개변수가 있습니까?
$ hostname
FISPCCPGS302c
$ nc -zvu FISPCCPGS302a 9694
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 10.109.160.16:9694.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
$ nc -zv FISPCCPGS302a 9999
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 10.109.160.16:9999.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
답변1
TCP와 달리 UDP는 연결 지향 프로토콜이 아닙니다.
여기서는 nc
1바이트 페이로드가 포함된 패킷을 보내고 UDP 패킷이든 ICMP 패킷이든 TCP와 마찬가지로 포트를 사용할 수 없거나 대상을 라우팅할 수 없음 등을 나타내는 메시지가 다시 오기를 기다립니다.
일반적으로 해당 UDP 포트에서 수신 대기 중인 모든 항목은 UDP 메시지를 보낸 사람에게 다시 보낼 이유가 없습니다. 예를 들어 이것이 DNS 서버인 경우 들어오는 1바이트 메시지는 가비지로 처리되어 무시됩니다. 답변을 얻으려면 nmap
UDP 스캔과 같이 올바른 DNS 쿼리를 보내야 합니다 .
따라서 제한 시간(netcat의 경우 2초로 추정) 내에 응답이 수신되지 않으면 netcat은 ICMP 메시지도 수신하지 않았으므로 UDP 포트가 열려 있다고 가정합니다.
그래서 당신이 보는 것은 다음과 같습니다:
- TCP를 사용하면 연결을 설정하기 위해 클라이언트가 보낸 SYN을 기반으로 상대방의 시스템(여기서 실행 중인 서버 소프트웨어도 아님)이 SYN+ACK로 응답합니다. 그것은 즉시 발생합니다.
- UDP의 경우 netcat은 ICMP 패킷(포트가 열려 있지 않음을 나타냄)을 수신하지 않기 때문에 포트가 열려 있다고 가정하고 2초 후에 시간 초과됩니다.
서버 소프트웨어의 응답 시간을 추정하려면 해당 서버의 프로토콜에서 적절한 요청을 해야 합니다. 이는 TCP와 UDP 모두에 적용됩니다.
dig . NS @"$address" -p "$port"
예를 들어 DNS 서버인 경우 DNS 쿼리(DNS 서버가 권한을 부여받은 도메인에 대한 SOA 쿼리 또는 루트 도메인에 대한 NS 쿼리와 같이 업스트림 서버 쿼리와 관련되지 않은 일부 쿼리)를 보내야 합니다. ~ 1), TCP의 경우 UDP의 경우 연결 요청, 데이터 및 종료 패킷을 보내고 응답을 기다리는 것을 의미하고, UDP의 경우 쿼리가 포함된 패킷을 보내고 응답을 기다리는 것을 의미합니다.
1 예를 들어 여기에서 실행한 테스트의 네트워크 추적에 따르면 UDP 포트 53(DNS의 표준 포트)에서 nmap -sU
전송됩니다 .서버 상태 요청DNS 쿼리.