포트 469에서 수신 대기하기 위해 Ubuntu 18.04.3 LTS 서버에서 Netcat을 실행하고 있습니다. 이 서버는 다른 시스템에서 포트 469로 TCP 요청을 자주 받습니다. 이 서버는 서버 가동 시간을 모니터링하는 데 사용됩니다. Netcat을 다음과 같이 시작합니다.
nc -kl 469
프로세스가 다음과 같이 실시간으로 진행되는 것을 볼 수 있습니다.
$ ps -aux | grep 469이는 다음과 같은 출력을 생성합니다.
루트 11041 0.0 0.1 13596 1060 ? S 8월 31일 0:21 nc -kl 469`
이 시스템은 약 24~28시간 동안 잘 작동하지만 이후 Netcat이 응답을 멈춥니다. 조사 결과, 문제는 Recv-Q 버퍼가 "채워지는" 것이라고 생각됩니다. 일반적으로 Recv-Q 버퍼는 Netcat이 응답을 중지하는 지점까지 0입니다. 응답이 중지된 후 Recv-Q 버퍼는 상수 2(일반 0 대신)입니다. 다음과 같이 "ss"로 이를 확인할 수 있습니다.
$ ss -tnl그런 다음 비정상적인 Recv-Q 2가 보이는 것을 봅니다.
$ ss -tnl
상태 Recv-Q Send-Q 로컬 주소:포트 피어 주소:포트
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 64 0.0.0.0:42587 0.0.0.0:*
LISTEN 0 128 0.0. 0.0:46663 0.0.0.0:*
듣기 0 128 0.0.0.0:111 0.0.0.0:*
듣기 2 1 0.0.0.0:469 0.0.0.0:*
듣기 0 128 127.0.0.53%lo:53 0.0.0.0:*
듣기 0 128 [::]:22 [::]:*
듣기 0 64 [::]:44057 [::]:*
듣기 0 128 [ ::]:55085 [::]:*
듣기 0 128 [::]:111 [::]:*
우리는 정확히 같은 방식으로 포트 469에서 수신 대기하는 Netcat을 실행하는 여러 다른 Ubuntu 서버를 가지고 있습니다. 그들은 실패하지 않습니다. 그들은 몇 주 동안 깨어 있었습니다. 하지만 이 서버는 다시 시작한 후에도 계속해서 실패하며 약 24시간 이상이 지나면 항상 실패합니다. 이 서버와 (내가 생각할 수 있는) 다른 서버 사이의 유일한 차이점은 이 서버에도 nfs 볼륨이 마운트되어 있다는 것입니다(위의 포트 111 수신 대기에서 볼 수 있듯이).
이것이 원인이 될 수 있는 것은 무엇입니까? Recv-Q를 어떻게든(bash에서) 지워서 일정한 간격으로(임시 수정으로) 지울 수 있습니까? 어떤 도움이라도 대단히 감사하겠습니다.
답변1
나는 이제 이 질문에 대한 답을 찾았고, 혹시 다른 사람에게 도움이 될 수 있을까 해서 여기에 게시하고 싶었습니다.
문제는 서버에 Strongswan도 설치되어 있고 포트 469로 들어오는 TCP 요청이 다른 서버의 IPSec 연결을 통해 왔다는 것입니다. IPSec 연결이 다시 입력될 때(약 24시간마다) 매우 짧은 시간 동안 IPSEC 연결이 중단되는 경우가 있었습니다. 포트 469에 대해 진행 중인 TCP 동기화/승인이 진행되는 도중에 이러한 일이 발생했다면 포트는 불확실한 상황에 놓이게 됩니다. 따라서 "nc -kl"은 Recv-Q 버퍼의 패킷과 함께 중단됩니다.
해결책은 키 재입력이 중단 없이 발생하도록 Strongswan을 구성하는 것이었습니다. Recv-Q 버퍼나 Netcat의 문제를 검색하기보다는 근본 원인을 이해하는 것이 필요하다는 것을 알게 되었습니다. 이 경우 TCP Syn/Ack가 완료되지 못한 이유를 이해하는 것이었습니다.