RDPのWindowsのファイアウォールの送信の規則について

背景

• Azure上のWindows Serverの仮想マシンにリモートデスクトップで接続する機会があった。
• リモートデスクトップができるクライアントは制限したかったので、RDPの制限をすることにした。
• Azureの仮想マシンのネットワーク設定は初期で以下のようになっている。

ここで疑問に思ったのが、送信側のRDPの制限はしなくてもよいのかということだった。

調べてみた

ファイアウォールみたいなものは、不勉強だったので、手元のWindowsPC 2台で検証してみた。

• RDPクライアントPC:Widnows11
• RDPサーバPC:Windows11

でサーバ側のファイアウォールの送信規則に新しい規則から、ローカルポート3389、リモートポートすべてのポートでブロック設定を追加した。
このとき新しい規則から設定するとリモートポートの設定しかないため、規則を作ってから、プロパティでローカルポートの制限を設定するのを間違えないようにする。

結果

普通に接続できた。

このときのパケットはどうなっているか確認してみた。確認はWiresharkというソフトを使った。初めて使ったが、インフラ関係の人だと当たり前につかうやつ？

サーバからの通信は3389がきっちり使われている。

このへんでよくわからなくなったので、ChatGPTとかに聞きながらやっていたが、これといった回答が得られなかったので、Claudeにも聞いてみた。

なんかそれっぽい回答が帰ってきた。
一回確立した接続の場合は許可されるらしい。

Window11のファイアウォールはステートフルファイアウォールであって、通信の状態（state）を追跡・管理するため、通信の状態を比較することで同一の通信かどうか判断している？ってことらしい。
たぶんAzureのネットワーク設定もこのステートフルファイアウォールであったため、受信の設定だけを初期に設定しているものと思われる。

ここで、あらたな疑問が生まれる。

ではRDPのような、TCPで3ウェイハンドシェイクを行うステートフルなプロトコル以外、UDPのようなプロトコルにはこの制限は通用するのであろうか?

これに関しては、UDPでそもそもそういった通信がそもそもあんまりない気がしたのだが、最近のプロトコルでGoogleが開発したQUICというプロトコルがあり、UDPで通信の管理ができるものらしい。
では仮にQUICベースのRDPがあれば、今回の送信ポート制限は有効なのだろうか。Claude
に聞いてみた。

なんかブロックされるらしい。本当だろうか？
この辺で本来の目的である。RDPを制限することから随分趣旨がそれていることに気づいたため、これくらいにしておく。

素直にRDPの制限を行いたければ、サーバ側の受信ポートでブロック設定をすればよいということがわかった。

ちなみにFTPもTCPなので、RDPと同様にサーバ側でWidnowsファイアウォールの送信ポート制限を行っても、通信されるようだ。