ファイアウォールの設定ではじかれているのかどうか

まったくの個人メモだ。

いま、MicrosoftのAzureにUbuntu VMを立てて、手元のUbuntu PCと通信するテストをしている。
プロトコルの仕様があって、それを実装している相手と、自分で実装したアプリを通信させようとしているのだ。

相手はクラウド上なので、Azureの設定でファイアウォールがきっちり設定されているから、穴を開けなくてはいかん。
自アプリは手元のPCなので、192.168.x.xみたいなローカルアドレスだから、クラウドから自アプリに接続させることはできず、自アプリから接続させなくてはならない。

で、ここからが本題だ。
つまり、うまくいっていない。

• 自アプリからクラウド側にsocketを張りにいって、その接続はできている
• 一応、telnetで確認したが、指定したIPアドレスとポート番号は空いているようだ
• しかし、自アプリからデータを送信して、それが正しければ相手から返ってくるはずなのだが、それが返ってこない
• 困ったことに、相手のアプリがどうログを出すのかがわかっていない

というところだ。

まあ、これから悩むのは私の仕事なのだが、socketが張れたのに、送受信がファイアウォールなどで止められることがあるのだろうか？という、すごく初歩的なところで悩んでいた。
悩むというか、わからんので失敗する理由から除外して良いかどうか判断できなかったのだ。

---

そういえば、JSON-RPCを使ったアプリの動作確認をするときにコマンドを使ったことを思い出した。
netcatだ。

catコマンドみたいに、といってよいかどうかわからんが、標準入力で受け取ったデータを指定したIPアドレス:ポート番号に流してくれるようだ。
今回は、こちらを読んでやった。

netcatってなんじゃらほい - マイペースマイライフ

今回、クラウド側が受ける方なので、そちらは -l オプションでポート指定した待ち状態にしておき、手元のPCから-l無しで実行すると入力待ちになるので、標準入力から打ち込んでリターンを押すと相手に転送される(標準入力は、デフォルトではトリガが何かないとキャッシュされるため)。

以前であれば、socketでbindやらconnectやら使っていたかもしれないが、コマンドを知ってしまえば楽ちんというか、手間が省略されるし、確実だ。

そして・・・困っている環境でやってみたのだが、うん、普通に送信できてるし、受信できてるね。
ってことは、ファイアウォールとかの問題ではなく、少なくともアプリより下では問題ないのだろう。
はあ、問題がよくわからなくなっただけではあるが・・・わからないということがわかっただけでもよしとしよう。