Q&A
iptablesでやるよりはテストプログラム用意した方が良いと思いますが、手を加えたくないのはどのプログラムでしょう
DROPを通信NGとしたいのですか？
WebアプリケーションからWebAPIへアクセスする際に「たまたま接続できなかった」を再現する場合、プログラムコードでわざとエラーを発生させたりしていますが、コードを注入せずエラーを再現させたいのですが、方法が思いつきません。
やってみたこと
iptablesを使って特定IPアドレスのアウトバウンドをドロップすることはできましたが、特定のURLを含む場合ができませんでした。
# できた iptables -A OUTPUT -d 192.168.0.10/32 -j DROP # できなかった iptables -A OUTPUT -d 192.168.0.10/32 -m string --algo bm --string 'phpinfo' -j DROP
↑ローカルエリアのサーバーへ、「phpinfo」を含む場合はドロップする仕掛けとして考えたコマンドラインですが、疎通できてしまいます。
また同じURLでも1回目は通信NG、2回目は通信OKという具合にもテストしたく、HTTPのXヘッダーを作り、そのXヘッダーを含む外部通信を遮断したいのですが、これも方法が思い当たりません。
何かよい方法（別途ツールがあれば、それとか）がありますでしょうか。
【追記】特定URLのアウトバウンドをDROPができた
一部解決できました。
アルゴリズムを「bm」から「kmp」に変えると遮断できました。
[root@www ~]# iptables -A OUTPUT -d 192.168.0.10/32 -m string --algo kmp --string 'phpinfo' -j DROP [root@www ~]# wget http://192.168.0.10/phpinfo.php --2019-11-21 11:06:02-- http://192.168.0.10/phpinfo.php Connecting to 192.168.0.10:80... connected. HTTP request sent, awaiting response... No data received. Retrying.
※これで特定URLに対しては全DROPができましたが、Webアプリケーション内では同じURLに対して2回通信しているので、1回目はエラー、2回目は正常というテストはできません。
Webアプリケーションの環境
・PHP5.6～、nginx1.16.1
・PHPからcURLまたはソケット通信で外部へ通信
・外部のWebAPIはHTTPS接続。
実際にリクエストした接続が拒否されることが必要なのでしょうか？
それともHTTPでエラーになってもいいのでしょうか？
テストスクリプトのようなものがあってそれを実行するのでしょうか？
テストスクリプト実行時そのマシンには管理者権限でアクセスできるのでしょうか？
WebアプリケーションはPHPで作っており、あるWebAPIの専用クラスをアプリケーション側で呼び出しています。
呼び出し元プログラムも専用クラスも手を加えたくありません。
受入テストをする際に、プログラムに手を加えずサーバーやインフラ環境の設定を変えるか何かでテストできればいいのですが・・・。
WebAPIはHTTPステータスコードなどで成否が判定できますが、そもそも接続できない事を再現したかったので、iptablesで試した時はDROPにしました。
受入テストということは、ブラウザを直接手で操作してテストしているのでしょうか？
> dameo 様
接続拒否でもHTTPでエラーでもかまわなく、要はWebAPIが正常に返すコード以外でネットワーク上のエラーが再現できればいいなと思っています。
CIなどは導入していない環境です。（デプロイとかも手動でしている、昔ながらのやり方です）
シンプルに、本番環境とは別にテスト環境があり、ブラウザで操作して確認しております。
テスト担当者はコンソール等でアクセスはできます。
では、ブラウザで操作する度にiptablesを書き換えるとかではダメなのでしょうか？
ぶっちゃけ192.168.0.10のケーブル抜く/挿すとかが出来るなら、それでもいいです
> dameo 様
そうなりますよね。
WebAPIへの通信を全て遮断ならそれでいいのですが、ブラウザからWebアプリへ1回アクセスした際に、Webアプリ内ではWebAPIへの通信を2回しています。
1回目は通信エラー、2回目は成功というふうにもテストしたく、頭を悩ませています。
なるほどリトライのテストもしたいのか
WEBアプリからは任意のヘッダーやオプション付けても良いようだしやはりサーバー側のプログラム手を加えた方がいいんじゃないですかね
オプションつけなければ通常動作するんだし
回答1件
0
ベストアンサー
iptablesを使う場合
iptablesはデフォルトではL7を扱うことは出来ないのでl7-filterを使う必要があります。
が、HTTPSでの通信だと通信内容までは把握出来ないのでやっぱり無理だと思います。
多分一番簡単だが、ソースコードの設定変更が必要になる場合が多い
インターネットに出る際にHTTPSをキャプチャするような設定(mitmする設定)のProxyを経由させて、Proxy側で通信内容をキャプチャ＆ブロックする。
- ホストのデフォルト通信をそのProxy経由になるようにする
- Proxyで内容をキャプチャして一定の条件の時はブロックするような設定を行う
ソースコードを変更せずにそのまま通信できるかは採用しているHTTPクライアント次第
確実に出来るが手間が多い
- キャプチャ&ブロック用サーバをインターネット上に用意する
- 1.のサーバにテスト用URLの証明書を取得/設定する
- テスト実施サーバのhostsでテスト用FQDNを1のサーバのIPに向ける(* テスト用のFQDNを変更出来るのであれば必要無し)
- 1のサーバで全リクエストを受け付けて、特定の条件の通信があった場合はそれに合った処理を、それ以外の処理は本来のテスト用URLからの通信を受けて返却するような仕組みを作る（PHPで作っても良いし、内容によってはnginxやsquid,Apache+mod_proxy等の設定でもできそうな気もします）
投稿2019/11/21 02:21
総合スコア18727
回答ありがとうございます。
WebAPIへの通信がHTTPSなので、やっぱ無理なんですね・・・。
Proxy経由だと、接続自体を拒否する設定ができるのでしょうか？
キャプチャする前提の話は、DNSをいじってテスト用証明書を使わせるんですね
そこまでは思いついてなかったです
> XNXSXMXRさん
試してはいませんが、iptablesでは無理なんじゃないかなと思います。
> dameoさん
接続自体をどの時点で拒否できるは、採用するProxyの設定次第かなと思います。
要件的にはそこまで厳密である必要は無い様に見えたので、「X-HTTPヘッダの条件が合致すれば4XXを返す」ような設定であれば多くのProxyで割と簡単に設定可能だと思います。
> tanatさん
質問者さんが「WebAPIはHTTPステータスコードなどで成否が判定できますが、そもそも接続できない事を再現したかった」とおっしゃってたので、多分その意図にはそわないかもですよ。
そして仮に何らかの条件で接続を切れたとして、今度いつ再接続可能にするのか？とかそういう問題もあり、そんなProxyなさそうと思ってました。
> dameoさん
> 「WebAPIはHTTPステータスコードなどで成否が判定できますが、そもそも接続できない事を再現したかった」
に関しては確かに内部のProxyでは対応しきれないと思います。
一方で
>「接続拒否でもHTTPでエラーでもかまわなく、要はWebAPIが正常に返すコード以外でネットワーク上のエラーが再現できればいいなと思っています。」 ともあるので、そんなに厳密である必要は無いのかなと思っての回答と思っていただければ。
あ、確かに！見落としてました。すみません。
私はこの回答に全面的に賛成なのですが、さっき追記・修正依頼のところで質問者さんに書こうと思ってたことだけ最後に書いておきます。
個人的な感覚でいうと、受入テストでここまでしなくていいんではないか？(ブラウザからのリクエストの途中でAPI鯖が落ちた場合のテスト)と思いました笑
APIサーバの高負荷時にタイムアウトしてしまう様なケースはあり得るので、その際の挙動は確認しておくに越したことは無いのかなと。
とはいえ、そこまでテストが必要であれば、
通常はテストがしやすいような設計をする必要があるので、
後から何とかするのは中々手間がかかりますね。
iptablesでL7の制御できるんですね、知らなかった
DROP（timeout）じゃなくても正常なレスポンス以外が返ってくれば良いとなるとやりたい事明確にしてテスト出来るようにプログラム組んだ方が良い点に物凄く同意です
> dameoさん
お付き合いいただきありがとうございました。
たしかに受入テストでここまでする？というのもごもっともなのですが、今回そういう事が必要になってきましたので・・・(^^;
ご愁傷さまです・・・
> tanatさん
ご回答ありがとうございました。L7-Filterがあることは初めてしりました。
今後はご指摘のように「テストしやすい設計」も意識して考えていきたいと思います。
> hentaimanさん
お付き合いいただきありがとうございました。
テストをするために、どこまで実施するのか・許容するのか（環境を変更してよいのか、こういう挙動ならよしとするのか）も含めて、「テストしやすい設計」というのを考えていこうと思います。
あなたの回答
tips
プレビュー
