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 12345
ss
# ss -anup | grep nc
ESTAB 0 0 10.0.7.8:52051 10.0.0.5:12345 users:(("nc",pid=2002,fd=3))
단순한 netcat 사례처럼 ss
OpenVPN의 출력 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)와 동일합니다.