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 -にsocatsocat UDP-LISTEN:7777 -と明らかにopenvpn)は決して使用されません。connect(2)ソースに送信されるため、UNCONN 状態が維持されます。彼らは単に使用されますrecvfrom(2)以下を使用してデータをエクスポートします。sendto(2)

これらの使用法の違いの説明のいくつかは次のとおりです。recv(2)そしてsend(2):

send()呼び出しは、ソケットが接続されている場合にのみ使用できます(意図した受信者がわかるように)。 send() と write(2) の唯一の違いは、フラグがあることです。フラグ引数が0の場合、send()はwrite(2)と同じです。

おすすめ記事