iproute2의 ss를 사용할 때 UDP 소켓이 UNCONN 상태입니다.

iproute2의 ss를 사용할 때 UDP 소켓이 UNCONN 상태입니다.

OpenVPN 클라이언트를 실행하는 컴퓨터에서 일부 방화벽 규칙을 편집하는 동안 ss.

# ss -anup | grep openvpn
UNCONN6528   0    0.0.0.0:52012        0.0.0.0:*     users:(("openvpn",pid=333,fd=3))

결과는 비어 있습니다.

구성을 보면 클라이언트가 UDP를 통해 연결해야 함을 알 수 있습니다 10.0.0.5:389. 나는 이것을 다음에서 확인했습니다 /proc:

# cat /proc/net/nf_conntrack | grep udp | grep 389
ipv4     2 udp      17 175 src=10.0.7.8 dst=10.0.0.5 sport=52012 dport=389 src=10.0.0.5 dst=10.0.7.8 sport=389 dport=52012 [ASSURED] mark=0 zone=0 use=2

curl ipinfo.io아웃바운드 연결을 설정하고 제대로 작동하는지 확인한 후 예상 결과를 반환한 후 두 명령 모두 빠르게 연속해서 실행되었습니다.

클라이언트에서 출력을 nc -l -u 12345확인하기 위해 서버와 클라이언트에서 netcat에 대한 일반 UDP 연결을 시도했습니다 .nc -u 10.0.0.5 12345ss

# ss -anup | grep nc
ESTAB      0      0      10.0.7.8:52051              10.0.0.5:12345               users:(("nc",pid=2002,fd=3))

단순한 netcat 사례처럼 ssOpenVPN의 출력 UNCONN상태가 예상된 상태가 아닌 이유는 무엇입니까 ?ESTAB


환경:

# uname -a
Linux tank 4.16.3-1-ARCH #1 SMP PREEMPT Thu Apr 19 09:17:56 UTC 2018 x86_64 GNU/Linux

# pacman -Qo /usr/bin/ss
/usr/bin/ss is owned by iproute2 4.16.0-1

답변1

핵심요약: UDP 소켓을 연결 모드에서 사용하거나 연결되지 않은 상태로 둘 수 있습니다. 이는 단순성이나 확장성과 같은 다른 요소를 기반으로 한 구현 선택입니다. 이는 회선의 패킷 내용을 변경하지 않으며 선택한 항목을 추적하지도 않습니다.

netcat사용bind(2)선택한 포트에 한 번만 사용됨recvfrom(2)MSG_PEEK데이터를 사용하지 않고 소스를 검색한 다음 사용할 수도 있습니다.connect(2)이 소스로 이동하여 소켓 상태를 다음으로 변경하면 ESTAB이제 간단한 작업을 계속할 수 있습니다.read(2)그리고write(2)수신 전화.

다른 앱(예: UDP-RECVFROM:7777,fork -대신 socat socat UDP-LISTEN:7777 -및 분명히 openvpn)은 절대 사용하지 않습니다.connect(2)소스에 전송되므로 UNCONN 상태가 유지됩니다. 그들은 단지 사용할 것입니다recvfrom(2)다음을 사용하여 데이터를 내보냅니다.sendto(2).

이러한 사용법 차이에 대한 설명 중 일부는 다음과 같습니다.recv(2)그리고send(2):

send() 호출은 소켓이 연결되어 있을 때만 사용할 수 있습니다(의도한 수신자를 알 수 있도록). send()와 write(2)의 유일한 차이점은 플래그가 있다는 것입니다. 플래그 인수가 0인 경우 send()는 write(2)와 동일합니다.

관련 정보