質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

89.97%

サーバ間通信の疎通確認

解決済

回答 5

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 7,665

poyopi

score 103

linux上のJavaプログラムで、送信元IPを制限しているAPIに接続する(https)ようなことをしています。
API側ではこちらのグローバルIPを許可して穴あけした「らしい」状態で、この許可作業が正しく設定されているかどうかをこちらで確認するのには

# telnet XXX.XXX.XXX.XXX 443


で Connected to XXX.XXX.XXX.XXX. の応答があれば確認OKだとばかり思っていたのですが
適当な私用のさくらのVPSやAWSのインスタンスから上記コマンドで確認してみたら同じくConnected to~が出てしまったのであてがはずれ(別のテストサーバで実施した際は何も応答がなかったので、この確認方法で問題ないと思っていた)、適切な確認方法がわからない状態です。

サーバ間通信において、正常に穴あけされているかどうか確認する適切なコマンドを教えてください。


接続先はLBで、接続元のIPを制限しています(許可IP以外は通さない)という情報を頂いています。
改めてtelnet以外のコマンドで確認したところ、

  • wget -S --spider https://XXX.XXX.XXX.XXX/
    これは無関係のサーバからもConnecting to XXX.XXX.XXX.XXX... connected.と返答
  • curl -k -l https://XXX.XXX.XXX.XXX/
    無関係のサーバからは暫くした後curl: (56) SSL read: errno -5961と返答(許可IPからはhtml)
    →先日はcurlでも応答があった旨書いており、logにも残っているのですが、現状はこうなりました

ので、curlでやるのが信憑性があるだろうか? という風に短絡的には思っています。ただし、情報追加修正のご指摘でも頂いておりますが、疎通確認の方法はケースにより異なるというように認識しております。ですが、その「どのケースの際にはこの確認方法」という手法がわからないため、今後のためにご助言など頂けませんでしょうか。wget, curl, telnet以外の方法や、検索ワードなどでもありがたいのですが、よろしくお願い致します。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • poyopi

    2016/10/06 10:18

    ikedasさん:TCP/IPでの接続・通信以外ではtelnetでの確認が適切でない旨ご教示ありがとうございます。どこで制限しているか、まだ確認できておりませんが、質問の意図としては、telnetが適切でない場合、他の疎通確認のための適切なコマンド(あるいは手法)が知りたいということになります。

    キャンセル

  • ikedas

    2016/10/06 12:40

    言葉を返すようでなんですが、どのレイヤでどうやって制限しているかをまずはっきりさせていただかないと、適切な確認方法も回答しようがないです。

    キャンセル

  • poyopi

    2016/10/06 13:18

    ikedasさん:仰る通りです。ご指摘の情報追加修正に関しましてはわかり次第行いますが、その部分は確認できるまでわからない点となりますので、想定していた回答の方向性としましては可能性の提示或いは「こういう場合はこう」とリストして頂く形でした。恐れ入ります。

    キャンセル

回答 5

+3

443/tcpの確認という観点では、方法自体は間違っていないと思います。
ただ、被接続側のフィルタリング設定が不適切で、本来遮断すべきIPからの接続を許可してしまっているのではないでしょうか。
被接続側のログは確認されましたでしょうか?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/10/07 13:14

    > この確認作業のゴールを明確に認識できていないので、どのツールをどう使うのか適切に選択できていない
    ご指摘の通りです。疎通確認をするという命題に当たった際、どの方法でどのような結果が返れば正常であるかということがわからずに今回のような質問に至りました。
    こちらの理解が足りないために何度も丁寧にご教示頂き申し訳ありません。ありがとうございます。

    キャンセル

  • 2016/10/07 13:24 編集

    本来確認すべきことは、fymartymさんが作ったjavaプログラムでAPIサーバに接続し、アプリケーション的に意図した応答が得られること、だと思うのです。
    確認の方法として、自分側の動作状況だけで結論を出すのではなくAPIサーバ側のログと突合するという事も必要だと思います。

    もしアプリケーション動作が上手くいかないのであれば、切り分けの定石として低いレイヤいから切り分けていけばいいと思います。
    まずはNW的に到達性があるか、ポートの応答はどうか、Webサーバの動作は、SSLは…と。

    おそらくその過程で、fymartymさんが意図しないホストからも443/tcpに接続できてしまったので混乱したのではないでしょうか。
    ただ今回のケースでは、443/tcpに接続できてよいのか悪いのかはAPI(NW)側の管理者の意図と実装の問題です。
    fymartymさんとしてはAPI側の担当者に淡々と事実を伝えればよいだけではないかと思います。

    あとはツールの出力をどう読み解くかですが、今回のケースは至極単純で「接続できた」と表示されているのなら接続できているのです。

    キャンセル

  • 2016/10/07 13:32

    > 作ったjavaプログラムでAPIサーバに接続
    > 443/tcpに接続できてよいのか悪いのかはAPI(NW)側の管理者の意図と設計の問題
    仰る通りです。特にAPIでは、どこからでも画面までのアクセスを受け付けるが許可IP以外のログイン情報はリジェクトする、というようなことをしているところもあると聞きます。そのためには何らかスクリプトなどで確認するしかないのだと理解しました。
    この度は何度もありがとうございました。質問するのにもある程度の理解がないとうまく説明できないというのを痛感しています。その部分を察して頂くような負担をおかけし、大変申し訳ない思いです。

    キャンセル

checkベストアンサー

+2

ロードバランサを介している旨の追加情報のご提供ありがとうございます。ほかのかたが指摘しておられることと重なりますが、アクセス制御より前にロードバランサがTCP/443の接続を受け付けてしまっている可能性もありますね。

ですので単に疎通だけでなく、通信内容をきちんと確認できる方法で確認したほうがいいと思います。たとえばopensslのs_client(1)を使った場合、アクセス制限がなにもなければ次のような結果が得られるはずです。

$ openssl s_client -connect 相手先ホスト名:443
CONNECTED(00000003)            <= 接続成功
ここに、証明書チェーンの詳細が表示される
ここに、TLS (SSL) ハンドシェークの詳細が表示される
TLSが確立すれば以下の内容が表示される
---
GET /APIのURI HTTP/1.1         <= APIへのリクエスト (GET等) を入力
Host: 相手先ホスト名

ここにAPIからの応答が表示される
closed


アクセス制限が行われていれば、上のどこかでアクセスを拒否されると思われます。

 ちなみに

本来、サービスが正常動作しているかどうかの判断基準やそれを確認するための手順はサービスを利用する側で検討するものではなく、サービスを設計・提供している側が明示すべきものとも考えられます。もしも差支えなければ、先方の担当者に確認手順の提示を求めてもよいのではないかと (第8層から上はこの場のスコープ外かな)。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/10/07 13:26

    opensslでの確認方法のご教示ありがとうございます。
    また、ブロック内で例示頂いていることが理解の助けとなり大変ありがたいです。
    > 判断基準やそれを確認するための手順はサービスを利用する側で検討するものではなく、サービスを設計・提供している側が明示すべきもの
    こちらもありがとうございます。以降、特段の制約がない限りは適切な確認方法について問合せるようにしたいと思います。
    改めて追加修正のやりとりを見てもかなり私が無茶を申し上げていましたが、丁寧に最後までご回答頂いてありがとうございました。

    キャンセル

+2

ヘルスチェック用のURLを叩くのが良いと思います。
アプリケーション側で/statusaliveという文字を返すように設計し、次のコマンドで
HTTPレスポンスコードが200を返す事と文字列がaliveであることを確認します。

curl -i https://example.com/status

接続先にWEBサーバ等が居ない場合は、接続先サーバで簡易WEBサーバをシェルで起動します。
次の例はポート8000で簡易Webサーバを起動します。
ポート1024以下でLISTENするにはroot権限が必要です。

while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; echo 'alive'; } | nc -l 8000; done

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/10/05 19:05

    詳細のご提案ありがとうございます。アプリに手を加えることは難しいので、参考とさせていただきます(ご教示頂いた内容たいへん勉強になります)。

    キャンセル

+2

ポート番号443のhttpsの疎通確認ですね。

nmap XXX.XXX.XXX.XXX

を実行してポートスキャンしてみて下さい。

疎通OKならば
443 https
が開いているメッセージが出るはずです。

ご参考まで

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/10/05 19:07

    nmapをインストールできない環境です。私用の方ではできますがnmapを利用することに抵抗があり・・・・・・。今後の参考とさせていただきます。
    https://www.websec-room.com/2014/02/09/1812
    > 但し、あくまで Nmap は自分の管理下にあるサーバーに対して行うようにしてください。

    キャンセル

  • 2016/10/05 19:57

    質問者さんのコメントの通り、nmapの使用には注意が必要です。
    当然相手方の同意があれば使用可ですが、nmapの話を持ち出すならその辺の注意はしてあげるべきかと思います。
    また、今回の目的に対してnmapは過剰ではないかとも思います。

    キャンセル

  • 2016/10/05 23:48

    "nmap -sT -p 443 (IPアドレス)"
    または
    "nmap -sS -p 443 (IPアドレス)"
    と、ポートを限定した方がいいと思います。

    キャンセル

  • 2016/10/06 02:53

    皆様、色々とご指摘ありがとうございます。いずれにしろポートスキャンを
    させて頂く許可を得てから実施しなければなりませんね。
    又、nmapを一から入れるくらいならばポートスキャン用の簡易ツールを
    インストールしてしまった方が楽かもしれません。

    今回はLinuxの環境とのことですが、Windows環境からポートスキャンを
    するのであれば
    http://blog.layer8.sh/ja/2012/01/09/port-scanner/
    が良いのではないかと思います。

    ご参考まで

    キャンセル

+1

wgetやcurlでHTTPプロトコルの通信を投げるのはダメなのでしょうか

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/10/05 18:37

    wget -S --spider https://XXX.XXX.XXX.XXX/としてみると、私用サーバからもConnecting to XXX.XXX.XXX.XXX:443... connected.と返り、curl -k -I https://XXX.XXX.XXX.XXX/としてみると、私用サーバからも200が返るので、ほかに何か適切な確認方法がないかと思っています。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 89.97%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る