エッジWebサーバーとしてのIIS（現在はhaproxy）

この記事では、最も典型的なシナリオではなく、生きる権利があるシナリオについて説明します。

実際には、IISを他社のWebサーバーのプロキシとして使用しています。 それがどのように実装され、どのような困難に直面したかを説明します。



問題の声明

例として、YouTrackサーバーを分析しましょう。 見苦しいsrv-youtrack-01.local.domainで表され、社内のWebサーバー上にあります。 タスクは、美しい名前yt.company.ruでインターネットからアクセスできるようにすることです。 この場合、httpsを使用する必要があります。



実装

開始するには、 URL Rewriteコンポーネントをインストールする必要があります。 これは、Webプラットフォームインストーラーを使用して、または手動で実行できます。 インストールすると、IISマネージャーに新しいショートカットが表示されます

URLの書き換え。」





このツールを使用すると、「逆プロキシ」アドレス書き換えルールを作成できます。







ルールを作成するとき、プロキシが行われるサーバーURL（http：//プレフィックスなし-IISは自動的に追加します）を指定する必要があります。 その結果、編集可能なルールを取得します。 すべてのリクエストに適用されるわけではなく、カスタマイズ可能な基準に適合するリクエストにのみ適用されます。 まず、URLがテンプレートに準拠しているかどうかがチェックされ、その後、他の基準に対するチェックが使用されます。







すぐに2つの方法があることを言わなければなりません。最初の方法は、同じIISサイト上のさまざまなリソースに対してさまざまなURLパターンを持つルールのセットを作成することです。 2つ目は、プロキシされたリソースごとにサイトを作成し、それぞれに1つのルールを作成することです。 最初のパスがよりジェダイであることを理解しているにもかかわらず、私は2番目のパスを選択しました-それほど美しくはありませんが、1つのサイトに間違った正規表現を書いてすべてのルーティングを壊す危険はありません したがって、どこにでもあるURLパターンのデフォルトは「（。*）」です。



そこで、ポート80と443のバインダーとホスト名の必須表示を使用してサイトyt.company.ruを作成し、IISがアクセスしているサイトを認識できるようにします。 443の証明書の取得とインストールについては言及しません。 httpsを使用するようにサービス自体を構成する必要がないという事実にのみ注目します。ネットワーク内部から暗号化する人はいません。外部リクエストはsslを介してエッジサーバーに接続されます。



必須要件がhttpsを使用することである限り、ポート443に着信する要求のみをプロキシし、単純な条件を作成します。 作成すると、可能なオプションのドロップダウンリストが表示されます。









さて、 yt.company.ruからのすべてのリクエストは、ユーザーに対して透過的な見苦しい名前srv-youtrack-01.local.domainで内部サーバーにプロキシされます。



ただし、すべてのyt.company.ruリクエストは 403エラーで切断されますが、これはあまり良くありません。 この問題を解決するには、リダイレクト付きのindex.htmlを作成するか、「アクション」フィールドで目的のURLへの永続的なリダイレクトを選択する別のURL書き換えルールを作成します。







サイトのルールは順番に適用されるため、最初に条件付きのルールを配置し、次に条件なしのルールを配置する必要があります。 同時に、2番目のルールは例外なくすべてのURLに適用されるため、最初のルールでは、「後続のルールの処理を停止する」チェックボックスをオンにする（チェックしたままにする）必要があります。







グラフィカルインターフェイスを操作すると、サイトのルートにweb.configが作成され、作成されたすべてのルールが含まれます。 したがって、別のサイトをプロキシする場合、これらの操作を繰り返す必要はありません。web.configをコピーしてその中の必要なURLを変更するか、グラフィカルインターフェイスを使用してコピー後にルールを変更できます。 さらに、インターフェイスをまったく使用することはできませんが、好きな人にすぐに書き込むことができます。



落とし穴

[アジャイルボード]タブに移動すると、YouTrackはyt.company.ru/rest/agile/Overview-0/sprint/Iteration+24という形式のURLを生成します。 次に、スプ​​リントを切り替えるときyt.company.ru/rest/agile/Overview-0/sprint/Iteration%252023?q= 。 これらのURLに切り替えると、IISは404エラーを返し始めました。 これは、リクエストがプロキシされていないことを示しています。 同時に、 yt.company.ru / issues / IT？q =％ 23 {Current + work} + Assigned + to％3A + me + updated％3A + {This + week}の形式の保存されたクエリ間の遷移は、非常に正しく機能しました。



問題のあるURLの中央に疑問符を追加する実験は、IISではなくYouTrackサーバーから404エラーを受け取り始めたという事実で終わりました。 これにより、何らかの理由でIIS（こんにちは、Microsoft）がURLを解釈し、これを修正する必要があるという考えが得られました。



アドレスの中央にあるプラス記号の問題は、 requestFiltering allowDoubleEscaping = "true"パラメーターを追加することで解決しました。

<system.webServer> <security> <requestFiltering allowDoubleEscaping="true" /> </security> </system.webServer>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、その後、スプリント間の切り替えはまだ機能しませんでした。 IISはそのような要求を安全でないと見なしていることが判明しました。 このチェックも無効にする必要がありました。

 <system.web> <httpRuntime requestPathInvalidCharacters="" /> </system.web>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、すべての操作後にweb.configが判明したものです。

 <?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name="ProxyToYouTrack" patternSyntax="ECMAScript" stopProcessing="true"> <match url="(.*)" negate="false" /> <action type="Rewrite" url="http://srv-youtrack-01.local.domain/{R:1}" appendQueryString="true" logRewrittenUrl="true" /> <conditions> <add input="{SERVER_PORT}" pattern="443" /> </conditions> </rule> <rule name="redir to ssl" enabled="true" stopProcessing="true"> <match url="(.*)" /> <action type="Redirect" url="https://yt.company.ru" /> </rule> </rules> <outboundRules> <preConditions> <preCondition name="ResponseIsHtml1"> <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" /> </preCondition> </preConditions> </outboundRules> </rewrite> <security> <requestFiltering allowDoubleEscaping="true" /> </security> </system.webServer> <system.web> <httpRuntime requestPathInvalidCharacters="" /> </system.web> </configuration>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まとめ

おそらく私が見つけた解決策は最適ではなく、すべてを順番に解決する代わりに、特定のケースに適したルールを慎重に規定する必要がありました。 しかし、今では動作します。 あなたの考えや提案を聞いてうれしいです。



したがって、外部アクセスを必要とするすべてのWebサーバーは、nginx、apache、svn、gitlabがあり、Webアクセスを交換する組織内で絶対にプロキシされます。



私が解決策を模索する主な問題は、多くのマイクロソフトサービスに必要なNTLM認証がプロキシを介して機能しないことです。 死んだTMG製品を使いたくないので、今は、 Webアプリケーションプロキシと呼ばれる新しいWindows Server 2012 R2サービスを理解しようとしていますが、nginxとapacheをちらっと見ていますが、NTLMをプロキシする方法もわかりません。

参照資料

http://www.ifinity.com.au/Blog/EntryId/60/404-Error-in-IIS-7-when-using-a-Url-with-a-plus-sign-in-the-path

stackoverflow.com/questions/2831142/asp-net-4-url-limitations-why-url-cannot-contain-any-3f-characters

---

大きな更新：

コメントでは、haproxyを試してみることをお勧めしました。 サイトを訪問した後、ntlmページを検索し、「NTLMのより良いサポートと静的ファームでの効率向上のための完全なHTTPキープアライブ」を見つけました。

コンソールでの数日間の活発な騒ぎの後、この素晴らしいツールを習得し、プロキシサーバーとしてIISが不要になりました。 これに関する別の記事は書く価値がないと思うので、トピックを更新することにしました。



このすべてが非常に簡単で、すぐに動作します：

1. apt-getを使用してバックポートからインストールします（Debianが望ましい）

2.設定が書き込まれます。 プロキシされるアプリケーションの設定はわずかに修正されています

3. iptablesを新しいプロキシに切り替えます



2番目のポイントについて詳しく説明します。

デフォルトセクションに設定を追加しました

  mode http balance roundrobin option redispatch http-send-name-header Host
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の項目は、ホスト名がバックエンドに渡されるために必要であり、残りは「他のすべての人のように」です。



次に、80および443ポートのフロントエンドが作成されます。これらは、いくつかの条件に応じて、要求を送信するバックエンドをリッスンして決定します。 そして、私は1つの条件しか持っていません-来たホスト名。

 frontend http bind *:80 #Define hosts acl host_yt hdr(host) -i yt.company.name acl host_ar hdr(host) -i ar.company.name acl host_portal hdr(host) -i portal.company.name acl host_crm hdr(host) -i crm.company.name acl host_git hdr(host) -i git.company.name acl host_mail hdr(host) -i mail.company.name ... use_backend yt if host_yt use_backend ar if host_ar use_backend crm_r if host_crm use_backend git_r if host_git use_backend mail_r if host_mail
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

httpsでは、もう少し複雑です。 近隣のトピックが助けになりましたが、コメントではSNIの使用が推奨されました。 そしてそれを使用しました

 frontend https bind *:443 ssl crt /etc/ssl/tfs.cer.ipk.pem crt /etc/ssl/yt.cer.ipk.pem crt /etc/ssl/crm.cer.ipk.pem crt /etc/ssl/git.cer.ipk.pem crt /etc/ssl/mail.cer.ipk.pem use_backend tfs if { ssl_fc_sni tfs.company.name } use_backend yt if { ssl_fc_sni yt.company.name } use_backend crm if { ssl_fc_sni crm.company.name } use_backend git if { ssl_fc_sni git.company.name } use_backend mail if { ssl_fc_sni mail.company.name }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは非常にシンプルであることが判明しました！ まず、すべてのバックエンドに対して証明書が生成されます-それらは顧客に与えられます。 私はMicrosoftのPKIを使用しているため、要求の生成、これらの証明書の発行、およびプロキシへの転送を少し工夫する必要がありました。 ちなみに、* .company.nameの使用は許可されていますが、特にこのような少数のバックエンドでは、どういうわけかあまり堅実ではないと判断しました。 証明書の準備ができたら、上記の例のように行にそれらを愚かに書いてから、バックエンドのルールを書く必要があります-証明書は順番にスリップされます。

sniを使用した設計は非常に単純なので、説明する必要もありません。 確かに、ほとんどのAndroidメールクライアントはsniの方法を知らない（または望まない）ため、ホスト名を指定せずにポート443にリクエストを送信します。 関係ありません！ そのような場合には

  default_backend mail
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（ちなみに、この場合、どの証明書がスリップされるかは確認しませんでした）



それでは、バックエンドについて説明します。 httpでは、すべてが簡単です。

 backend it server it.company.name srv-web-01 backend ar server ar.company.name srv-web-01
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 it.company.nameは、srv-web-01に転送されるホスト名です。 このサーバー上のIISはホスト名による認証を使用するため、これが必要です。



httpsの場合、これらはデザインです

 backend yt server yt.company.name srv-youtrack-01:80 backend tfs server tfs.company.name tfs:443 ssl verify none
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ポート80を指定してSSLをアンロードできます。クライアントとプロキシ間のトラフィックは暗号化されますが、ネットワーク内にはありません。 また、httpsを引き続き使用できます（「証明書に障害が見つからない」ことを意味することを確認しない）。 ただし、クライアントは、フロントエンドの作成時に入力した証明書を引き続き受信することを理解する必要があります。 最終的なサーバー証明書を取得する必要がある場合は、上記のトピックで説明した方法を使用できます。



別のポイント：一部のサーバーのhttpをhttpsに美しくリダイレ​​クトしたい。 これを行うために、 _r接尾辞を使用して特別なバックエンドを作成しました。これにより、疑いを持たないユーザーが慎重にhttpsにスローされます。

 backend tfs_r #redirect location https://tfs.company.name code 301 redirect scheme https
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コメントアウトされた行を意識的に削除しませんでした-そのようなオプションはもともと使用されていましたが、ユーザーが長いリンクhttp：//site.company.name/lib/doc/Russian%20 letters％20％をクリックすると非常に不便です20 titles.docx、そして彼は彼の文書を見つけることの希望なしでメインページに投げられました。 彼はそれを閉じて再びリンクをたどろうとする可能性がありますが、再び何も得られず、非常に動揺します。 これを防ぐために、 リダイレクトスキームhttpsコンストラクトが役立ちます。これにより、ユーザー全体が正確にリダイレクトされ、URL全体が置き換えられます。



ドキュメントページcbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2の設定のすべての微妙な詳細



ご清聴ありがとうございました。 私の経験が誰かに役立つと思います。