☰

s2s VPN接続を介して単方向接続しかできない場合、どのサブシステムが責任を負いますか？

tag-icon • tag-icon freebsd routing firewall openvpn pfsense
s2s VPN接続を介して単方向接続しかできない場合、どのサブシステムが責任を負いますか？

次のs2s VPN（pfSenseで）接続を設定しましたが、正常に動作します。

ここに画像の説明を入力してください。

残念ながら、クライアントからサーバーにしか接続できず（ping、netcat、ssh）、再接続することはできません。

正常にsshを行うことができれば、ファイアウォールに問題はないでしょうか？パッケージは双方向に出荷されるので？

コマンドラインツールを使用して問題を診断する方法は？

間違いをしてnetcatを逆にすることはできませんでした。ただし、サーバーからクライアントにpingを送信すると、パケットキャプチャを介してクライアントのpingトラフィックを表示できます。

また、明示的なパスを追加しました。

route add -net 192.168.31.0/24 192.168.27.2

サーバーから。

これは、サーバー（.31.1）またはそのネットワーク対応物（.31.155）でクライアントをpingしたときにクライアントにパケットをダンプしたときに表示される内容です。

$ tcpdump -n -i ovpnc2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytes
20:04:44.123925 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 0, length 64
20:04:45.133435 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 1, length 64
20:04:46.146100 IP 192.168.27.1 > 192.168.31.1: ICMP echo request, id 14862, seq 2, length 64
20:04:49.664935 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 0, length 64
20:04:50.663422 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 1, length 64
20:04:51.679393 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 2, length 64
20:04:52.688367 IP 192.168.27.1 > 192.168.31.155: ICMP echo request, id 1295, seq 3, length 64

クライアントはpingパケットを見たが応答しないようだ。そうですか？

答え1

もちろん、ファイアウォールはSYNフラグが設定されているがACKフラグが設定されていないTCPパケットを1方向にのみ転送して、TCP接続が確立される方向を制御できます。

通常、SSHを使用できるという事実は、パケットがSYNフラグはまったくありません。またはSYN フラグと ACK フラグの両方がセットされました。両方の方向が許可されます。 TCP接続を確立するには、システムはTCP SYNフラグを設定し、ACKフラグを設定せずにパケットを送信する必要があり、ファイアウォールはこれらのパケットを他のパケットと簡単に区別できます。

ping は TCP パケットではなく ICMP パケットなので、ファイアウォールはこれに対して他のルールを簡単に設定できます。また、ファイアウォールは、「ping リクエスト」のルール 1 つと「ping レスポンス」の別のルールを簡単に設定できます。

関連情報