URL 다시 쓰기 v2 및 애플리케이션 요청 라우팅을 사용하여 역방향 프록시

아티클
07/19/2023

이 연습에서는 URL 다시 쓰기 모듈 및 ARR( 애플리케이션 요청 라우팅)을 사용하여 여러 백 엔드 애플리케이션에 대한 역방향 프록시 서버를 구현하는 방법을 안내합니다.

사전 요구 사항

이 연습을 실행하려면 다음이 있어야 합니다.

ASP.NET 역할 서비스를 사용하도록 설정된 IIS 7 이상
URL 다시 쓰기 모듈이 설치됨(응답 다시 쓰기에 대한 부분을 완료하려면 버전 2.0이 필요합니다.)
애플리케이션 요청 라우팅 버전 1.0 또는 버전 2.0이 설치됨

소개

URL 다시 쓰기 모듈 및 애플리케이션 요청 라우팅을 사용하여 복잡하고 유연한 부하 분산 및 역방향 프록시 구성을 구현할 수 있습니다. 매우 일반적인 역방향 프록시 시나리오는 인터넷을 통해 여러 내부 웹 애플리케이션을 사용할 수 있도록 하는 것입니다. 인터넷에 액세스할 수 있는 웹 서버는 웹 요청을 수신한 다음 처리를 위해 여러 인트라넷 애플리케이션에 전달하는 역방향 프록시 서버로 사용됩니다. 다음 그림에서는 역방향 프록시 시나리오에 대한 일반적인 구성을 보여 줍니다.

ARR 서버에 도메인 이름이 http://contoso.com있다고 가정하면 다음 URL을 사용하여 각 웹 애플리케이션에 액세스할 수 있습니다.

http://contoso.com/webmail/
http://contoso.com/payroll/

에 대한 요청이 이루어지 http://contoso.com/webmail/default.aspx면 ARR은 URL http://webmail/default.aspx을 사용하여 이러한 요청을 내부 서버로 전달합니다. 마찬가지로 에 대한 요청은 http://contoso.com/payroll/ 로 전달됩니다 http://payroll/default.aspx.

또한 내부 애플리케이션이 해당 애플리케이션의 다른 위치에 연결되는 응답 HTML에 링크를 삽입하는 경우 응답이 클라이언트에 반환되기 전에 해당 링크를 수정해야 합니다. 예를 들어 의 페이지에 http://webmail/default.aspx 다음과 같은 링크가 포함될 수 있습니다.

<a href="/default.aspx?id=1">link</a>

그런 다음 ARR 서버는 이 링크를 다음으로 변경해야 합니다.

<a href="/webmail/default.aspx?id=1">link</a>

예제 웹 사이트 만들기

간단히 하기 위해 이 연습에서 사용할 역방향 프록시 시나리오는 단일 서버에서 구현되며, IIS "기본 웹 사이트"는 역방향 프록시 사이트 역할을 하고 동일한 서버의 별도 IIS 웹 사이트에 호스트되는 웹 메일 및 급여 애플리케이션으로 작동합니다.

예제 웹 사이트를 만들려면 다음을 수행합니다.

다음 폴더에 "webmail" 및 "payroll"라는 두 개의 폴더를 만듭니다.
```
%SystemDrive%\inetpub\ folder.
```
아래%SystemDrive%\inetpub\의 해당 폴더를 가리키는 "webmail" 및 "payroll"라는 두 개의 IIS 웹 사이트를 만듭니다. 각 사이트에 대해 서로 다른 IP 포트를 사용합니다.
다음 명령을 사용하여 사이트를 만들 수 있습니다.
```
%windir%\System32\inetsrv\appcmd.exe add site /name:"webmail" /bindings:http/*:8081: /physicalPath:"%SystemDrive%\inetpub\webmail"

%windir%\System32\inetsrv\appcmd.exe add site /name:"payroll" /bindings:http/*:8082: /physicalPath:"%SystemDrive%\inetpub\payroll"
```
다음 폴더에 default.aspx라는 파일을 만듭니다.
```
%SystemDrive%\inetpub\webmail
```

다음 ASP.NET 태그를 복사하여 파일에 붙여넣고 파일을 저장합니다.

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Reverse Proxy Test - WebMail Application</title>
</head>
<body>
    <h1>Reverse Proxy Test Page - WebMail Application</h1>
    <p>Requested URL path is <%= Request.ServerVariables["SCRIPT_NAME"] %><p>
    <p><a href="<%= Request.ServerVariables["SCRIPT_NAME"] %>">Here</a> is the link to this page.</p>
</body>
</html>

다음 폴더에 default.aspx라는 파일을 만듭니다.
```
%SystemDrive%\inetpub\payroll
```

다음 ASP.NET 태그를 복사하여 파일에 붙여넣고 파일을 저장합니다.

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Reverse Proxy Test - Payroll Application</title>
</head>
<body>
    <h1>Reverse Proxy Test Page - Payroll Application</h1>
    <p>Requested URL path is <%= Request.ServerVariables["SCRIPT_NAME"] %><p>
    <p><a href="<%= Request.ServerVariables["SCRIPT_NAME"] %>">Here</a> is the link to this page.</p>
</body>
</html>

사이트가 제대로 작동하는지 확인하려면 웹 찾아보기를 열고 다음 URL을 요청합니다.
```
http://localhost:8081/default.aspx
```
```
http://localhost:8082/default.aspx
```

역방향 프록시에 대한 규칙 구성

연습의 이 섹션에서는 만든 예제 웹 사이트에서 작동하도록 역방향 프록시 기능을 구성합니다.

역방향 프록시 기능 사용

역방향 프록시 기능은 기본적으로 사용하지 않도록 설정되므로 먼저 사용하도록 설정해야 합니다.

IIS 관리자 열기
왼쪽의 트리 뷰에서 서버 노드를 선택하고 "애플리케이션 요청 라우팅" 기능을 클릭합니다.
"프록시 사용" 검사 확인란을 선택합니다. 이 페이지의 다른 모든 설정에 대한 기본값은 그대로 둡니다.

웹 메일 애플리케이션에 대한 규칙 만들기

두 개의 다시 쓰기 규칙을 만듭니다.

요청된 URL 경로가 "webmail"로 시작하는 한 에서 웹 메일 애플리케이션에 http://localhost:8081/ 대한 모든 요청을 프록시하는 다시 쓰기 규칙입니다.
요청된 URL 경로가 "급여"로 시작하는 한 급여 애플리케이션에 http://localhost:8082/ 대한 모든 요청을 프록시하는 재작성 규칙입니다.

역방향 프록시 다시 쓰기 규칙을 추가하려면 다음을 수행합니다.

다음 위치에 있는 web.config 파일을 엽니다.
```
%SystemDrive%\inetpub\wwwroot\
```

/configuration/system.webServer 요소 아래에 다음을 추가한 다음 파일을 저장합니다.

<rewrite>
    <rules>
        <rule name="Reverse Proxy to webmail" stopProcessing="true">
            <match url="^webmail/(.*)" />
            <action type="Rewrite" url="http://localhost:8081/{R:1}" />
        </rule>
        <rule name="Reverse Proxy to payroll" stopProcessing="true">
            <match url="^payroll/(.*)" />
            <action type="Rewrite" url="http://localhost:8082/{R:1}" />
        </rule>
    </rules>
</rewrite>

다시 쓰기 규칙을 만드는 방법에 대한 자세한 내용은 URL 다시 쓰기 모듈에 대한 다시 쓰기 규칙 만들기를 참조하세요.

역방향 프록시 기능 테스트

웹 브라우저를 열고 에 요청합니다 http://localhost/webmail/default.aspx. 웹 메일 테스트 페이지의 응답이 표시됩니다. 또한 에 요청합니다 http://localhost/payroll/default.aspx. 급여 테스트 페이지의 응답이 표시됩니다.

두 경우 모두 응답 내의 링크는 를 가리킵니다 http://localhost/default.aspx. 이 링크를 클릭하면 서버에서 404(파일을 찾을 수 없음) 응답이 발생합니다. 다음 섹션에서는 애플리케이션에서 생성된 응답 HTML 링크를 수정하는 아웃바운드 규칙을 만드는 방법을 알아봅니다.

응답 다시 쓰기에 대한 규칙 구성

설명서의 이 섹션은 IIS 7용 URL 다시 쓰기 모듈 버전 2.0에 적용됩니다.

다음과 같이 응답 HTML 내의 모든 링크를 대체하는 아웃바운드 규칙을 정의합니다.

<a href="/default.aspx">...</a>

는 다음으로 대체됩니다.

<a href="/webmail/default.aspx">...</a>

(웹 메일 애플리케이션에서 응답이 제공된 경우)

및

<a href="/payroll/default.aspx">...</a>

(급여 신청에서 응답이 나온 경우)

경고

응답 헤더 또는 응답 콘텐츠가 아웃바운드 다시 쓰기 규칙에 의해 수정되는 경우 응답에 삽입되는 텍스트에 클라이언트 쪽 실행 코드가 포함되어 있지 않아 사이트 간 스크립팅 취약성이 발생할 수 있도록 주의해야 합니다. 이는 다시 쓰기 규칙이 HTTP 헤더 또는 쿼리 문자열과 같은 신뢰할 수 없는 데이터를 사용하여 HTTP 응답에 삽입될 문자열을 빌드하는 경우에 특히 중요합니다. 이러한 경우 대체 문자열은 HtmlEncode 함수를 사용하여 HTML로 인코딩되어야 합니다.예:

<action type="Rewrite" value="{HtmlEncode:{HTTP_REFERER}}" />

규칙을 만들려면 다음 단계를 수행합니다.

IIS 관리자로 이동
"기본 웹 사이트"를 선택합니다.
기능 보기에서 "URL 다시 쓰기"를 클릭합니다.
오른쪽의 작업 창에서 "규칙 추가..."를 클릭합니다. "규칙 추가" 대화 상자의 "아웃바운드 규칙" 범주에서 "빈 규칙"을 선택하고 확인을 클릭합니다.

이제 실제 아웃바운드 규칙을 정의해야 합니다. URL 재작성 모듈 2.0에서 아웃바운드 다시 쓰기 규칙은 다음 정보를 지정하여 정의됩니다.

규칙의 이름입니다.
이 규칙을 응답에 적용할지 여부를 제어하는 선택적 사전 조건입니다.
응답에서 문자열을 일치시키는 데 사용할 패턴입니다.
선택적 조건 집합입니다.
패턴이 일치하고 모든 조건 검사가 성공하면 수행할 작업입니다.

규칙 이름 지정

"이름" 텍스트 상자에 규칙을 고유하게 식별하는 이름(예: "애플리케이션 접두사 추가")을 입력합니다.

사전 조건 정의

사전 조건은 응답에서 아웃바운드 규칙 평가를 수행해야 하는지 여부를 평가하는 데 사용됩니다. 예를 들어 HTML 콘텐츠를 수정하는 규칙의 경우 콘텐츠 형식 헤더가 "text/html"로 설정된 HTTP 응답만 이 규칙에 대해 평가해야 합니다. 아웃바운드 규칙 평가 및 콘텐츠 다시 쓰기는 웹 애플리케이션의 성능에 부정적인 영향을 줄 수 있는 CPU 집약적 작업입니다. 따라서 사전 조건을 사용하여 아웃바운드 규칙이 적용되는 경우의 범위를 좁힐 수 있습니다.

만드는 규칙은 HTML 응답에만 적용되어야 하므로 HTTP 응답 헤더 콘텐츠 형식 이 "text/html"에 같은지 여부를 확인하는 전제 조건을 정의합니다.

사전 조건을 정의하려면 다음을 수행합니다.

사전 조건 목록에서 "<새 사전 조건 만들기...>"를 선택합니다.
이렇게 하면 사전 조건 편집기 대화 상자로 이동하여 사전 조건을 정의해야 합니다. 다음과 같이 사전 조건 설정을 지정합니다.
- 이름: "IsHTML"
- 사용: "정규식"
- "추가"를 클릭하여 "조건 추가" 대화 상자를 표시합니다. 이 대화 상자에서 다음을 지정합니다.
  - 조건 입력: "{RESPONSE_CONTENT_TYPE}"
  - 입력 문자열 확인: "패턴과 일치"
  - 패턴: "^text/html"
확인을 클릭하여 사전 조건을 저장하고 "규칙 편집" 페이지로 돌아갑니다.

일치하는 scope 정의

아웃바운드 다시 쓰기 규칙은 HTTP 헤더의 콘텐츠 또는 응답 본문 콘텐츠에서 작동할 수 있습니다. 이 규칙은 응답 콘텐츠의 링크를 바꿔야 하므로 "일치 범위" 드롭다운 목록에서 "응답"을 선택합니다.

태그 필터 정의

태그 필터는 규칙의 패턴에 대해 전체 응답을 평가하는 대신 특정 HTML 요소에만 일치하는 패턴을 scope 데 사용됩니다. 패턴 일치는 매우 CPU 집약적인 작업이며 전체 응답이 패턴에 대해 평가되는 경우 웹 애플리케이션 응답 시간이 크게 느려질 수 있습니다. 태그 필터를 사용하면 패턴 일치가 특정 HTML 태그의 콘텐츠 내에서만 적용되도록 지정할 수 있으므로 정규식 패턴에 대해 평가해야 하는 데이터의 양을 크게 줄일 수 있습니다.

태그 필터를 정의하려면 드롭다운 목록 "내 콘텐츠 일치: " 를 확장한 다음 검사 상자 "A(href 특성)"를 선택하고 검사.

이렇게 하면 다음 예제와 같이 하이퍼링크의 href 특성 값에만 패턴을 적용하는 규칙이 설정됩니다.

<a href="this string will be used for pattern matching">Some link</a>

패턴 정의

"패턴" 텍스트 상자에 다음 문자열을 입력합니다.

^/(.*)

이 문자열은 패턴이 "/" 기호로 시작하는 URL 경로 문자열과 일치하게 지정하는 정규식입니다.

패턴 내에서 괄호를 사용합니다. 이러한 괄호는 나중에 백 참조를 사용하여 규칙에서 참조할 수 있는 캡처 그룹을 만듭니다.

조건 정의

응답이 웹 메일 또는 급여 애플리케이션에서 온 경우에만 응답 HTML의 링크를 변경해야 합니다. 검사 클라이언트에서 요청한 URL 경로를 분석하는 조건을 사용합니다. 또한 요청된 URL에서 애플리케이션 폴더를 캡처하는 조건 패턴을 정의하므로 해당 규칙은 응답에서 링크를 다시 쓸 때 다시 사용할 수 있습니다.

조건 그룹 상자를 확장합니다.
"추가..."를 클릭합니다. 단추를 눌러 조건을 정의하기 위한 대화 상자를 표시합니다.
"조건 입력:"에 "{URL}" 문자열을 입력합니다. 이렇게 하면 웹 클라이언트에서 요청한 URL 경로를 사용하도록 URL 다시 쓰기 모듈이 구성됩니다.
드롭다운 콤보 상자에서 "패턴 일치"를 선택합니다.
패턴 텍스트 상자에 를 입력 ^/(webmail|payroll)/.* 합니다. 이 정규식은 또는 /payroll로 시작하는 /webmail URL 경로를 일치시키는 데 사용됩니다. 패턴 내의 괄호는 일치하는 URL 문자열의 일부를 캡처하므로 대체 URL을 생성할 때 사용할 수 있습니다.
확인을 클릭하여 조건을 저장하고 "규칙 추가" UI로 돌아갑니다.

작업 정의

"작업" 그룹 상자에 나열된 "다시 쓰기" 작업 유형을 선택합니다. "값" 텍스트 상자에 다음 문자열을 입력합니다.

/{C:1}/{R:1}

이 문자열은 링크 주소를 다시 작성할 새 값을 지정합니다. {C:1}은(는) 조건 패턴 캡처 그룹에 대한 백 참조이며 "webmail" 또는 "payroll" 문자열로 대체됩니다. {R:1}은(는) 규칙 패턴 캡처 그룹에 대한 백 참조이며, 이 경우 하이퍼링크에서 사용된 원래 URL 경로로 대체됩니다.

다른 모든 설정에 대한 기본값을 그대로 둡니다. "아웃바운드 규칙 편집" 속성 페이지는 다음과 같습니다.

오른쪽에서 "적용" 작업을 클릭하여 규칙을 저장합니다.

방금 만든 규칙의 구성을 검사 에 있는 %SystemDrive%\inetput\wwwroot\web.config 파일을 엽니다. 이 파일에는 이 규칙 정의가 포함된 섹션이 표시됩니다 <rewrite> .

<rewrite>
    <rules>
        <rule name="Reverse Proxy to webmail" stopProcessing="true">
            <match url="^webmail/(.*)" />
            <action type="Rewrite" url="http://localhost:8081/{R:1}" />
        </rule>
        <rule name="Reverse Proxy to payroll" stopProcessing="true">
            <match url="^payroll/(.*)" />
            <action type="Rewrite" url="http://localhost:8082/{R:1}" />
        </rule>
    </rules>
    <outboundRules>
        <rule name="Add application prefix" preCondition="IsHTML">
            <match filterByTags="A" pattern="^/(.*)" />
            <conditions>
                <add input="{URL}" pattern="^/(webmail|payroll)/.*" />
            </conditions>
            <action type="Rewrite" value="/{C:1}/{R:1}" />
        </rule>
        <preConditions>
            <preCondition name="IsHTML">
                <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
            </preCondition>
        </preConditions>
    </outboundRules>
</rewrite>

규칙 테스트

규칙이 응답에서 URL을 올바르게 다시 작성하는지 테스트하려면 웹 브라우저를 열고 또는 http://localhost/payroll/default.aspx에 http://localhost/webmail/default.aspx 요청합니다. 아웃바운드 다시 쓰기 규칙이 HTML 응답 내에서 링크를 변경한 것을 볼 수 있습니다.

요약

이 연습에서는 역방향 프록시 시나리오를 구현하도록 URL 다시 쓰기 모듈 및 애플리케이션 요청 라우팅을 구성하는 방법을 알아보았습니다. 또한 URL 재작성 모듈 2.0의 새로운 아웃바운드 다시 쓰기 기능을 사용하여 웹 클라이언트에 제공하기 전에 애플리케이션 응답의 링크를 수정하는 방법을 알아보았습니다.

역방향 프록시를 사용하는 경우 HTTP 응답 헤더를 다시 작성해야 하는 경우가 많습니다. URL 다시 쓰기 모듈 2.0을 사용하여 응답 HTTP 헤더를 수정하는 방법을 알아보려면 HTTP 응답 헤더 수정을 참조하세요.