Soft::IISの最近のブログ記事

過去、IISの応答を書き換えたが、ひょんなことから、今度は要求を書き換える必要が出てきた。

んで、調べると、やはりリクエストもフィルタを用意せにゃならんらしい。

面倒です。

でも、ちょっとづつやらかします。

今度は、ちゃんとやるですよ。
＃応答書き換えは適当。
https://blog.fne.jp/2010/01/iis.html

ちょっとしたアレで、Windows Server 2012にIISを入れて、ASP.NETなもの動かそうと思ったんだけど、なんかうまくいかない。

ASP.NET自体、機能になってるからそれをインストールすればいいんだろうけど、それだけの選択ができないというか、よくわからない。

仕方ないので、Web Platform Installerを導入して、ASP.NET 4.5をインストールし、何とか対応。

当然、ローカル環境だけで対応可能な方法があるはずなのだが、・・・

結局、ルート認証局の仮想マシンをローカルに展開して手元で作成。

失敗しつつも、何とか更新まで完了。

やはり、年1回だと忘れちゃうよね。

ってことでこれとかこれとか参考。

1年後にはまた忘れちゃうんだろうけど。

このブログサーバのメモリが増えたので、仮想マシンを立てた。
WindowsServerをインストールし、SharePointServerを入れてみた。

でもこのままではアクセスできない。
IPアドレスは1つだから、ARRを経由させる必要がある。

せっかくだから、ARecX6の中継と同様、定期的・自動的に認証情報を変える仕組みを持たせたい。
その認証結果をもって、ユーザアカウントに結び付けてSharePointの認証までやっちまいたいと思ってるんだけど、偽装した結果のARR通過ができるのかどうか、そこら辺がいまのところ不鮮明なんだけどな。

近いうちにやってみようと思う。

解決はしていない。

とあるサイトというのは、某ショップのサイトだったわけだが。

とりあえず、店舗の方に直接確認してもらった。
＃こういうとき、WiMaxだと持ち運び自由で便利。

だけど、原因、掴めないままで、結局、店舗サイトをfne.jpでリバースプロキシすることに。

で、その設定が何とかできたのだが・・・なんだかおかしい現象に。

URL Rewriteのバージョンが古いのかも知れないけれど、リダイレクトヘッダの書き換えがおかしい。

http://Aのパターンをhttps://nA.fne.jpに書き換え、https://Aのパターンをhttps://sA.fne.jpに書き換えているとすると、リダイレクトヘッダのLocationで、明らかに後者なのに前者に書き換えられてしまう。
後続HTMLコンテンツ内の後者パターンはちゃんと書き換えできているのに。

よくわからないけれど、このままではいろいろと問題なので、URLパターンを解析して、強制的に自主的リダイレクトを追加。
これによって何とか、何とか。

本当は汎用のリバースプロキシを実装すればいいんだけど、文字コードの件もあるので、それは追々。

前回までは・・・

Hostヘッダが怪しいんじゃねぇ？→Host名.fne.jpサイトを作ってアクセス→プロキシ動作させるのに悪戦苦闘の末成功→当初の目的を忘れる。

だったわけだが、今回、hostsを書き換えて、完全同一ホスト名でアクセス可能かやってみたわけよ。

結果、プロキシアクセス成功。
なんでやねん！！

サイトA(仮)へのアクセスで、Wimax経由だと、レスポンスが無いという現象に見舞われている。

サイトAを運営しているところへ問い合わせをしたが、アクセスログ的にはレスポンスは返されているらしい。

その応答パケットがロストするということは、経路上のどこかで意図的か非意図的か不明だが、フィルタリングされている可能性が高く、A以外のサイトでは発生したことが無いとなれば、ホスト名がキーになっている可能性も捨てきれない・・・と。

このブログで使ってるBフレッツ経由だとアクセスできるため、ARRを駆使してリバースプロキシっぽいものを構成すれば・・・と思ったが、ARRのリバースプロキシはARecX以外うまくできたためしが無かったのも事実である。

前記事からの続き。

結局無線LANアクセスポイントの設定画面をARRでリモートアクセス可能にした。
＃当然SSLのみの設定。

久しぶりだったので設定でちょっと詰まった。

• 拡張子拒否で401エラー。
• 圧縮を切ってなかったので500エラー。
  ＃これは俺の環境だけかも。

忘れないようにメモ↑。

今回、認証は設定画面のBASIC認証をそのまま使ったので、別途認証の設定は無し。
＃いつもは認証モジュールを組み込む。

にしても、ARR、非常に使える。

成功するまではちょっと不安もないわけじゃない。

今まではPHSで速度不足のため、ほんの僅かしか視聴できなかったが、もしかして、何か不都合アリ？とか思ったりもした。

というわけで、実際に外出先からアクセスできる機会を得たので、視聴してみた。

まったく問題なく視聴できることに少し感動。

通常時でも、hostsファイル書き換えて外部からトンネル刺さってるIPアドレスへアクセスしてるから、出来て当たり前と言えば当たり前なんだけど・・・

いや、当たり前のことが当たり前にできることは、実はとても重要なんだと思う。
そのための確認ってのはやる意味がなさそうに感じられるけれど、実は一番必要なことなのかも知れない。

などと考えつつ、ARecX6の視聴を楽しむのであった。

ARR経由でARecX6のファームPOSTが404応答になってた理由、分かっちゃえば単純。