빌드

도구를 한 번 컴파일한 후 결과 바이너리를 사용하거나 "스크립트처럼" 실행할 수 있습니다 (Go 툴체인이 즉시 컴파일합니다). 개발 시에는 후자의 옵션이 편리합니다. 실제 사용 시에는 (cli 디렉터리에서) 한 번 컴파일하고 결과 실행 파일을 사용하는 것이 좋습니다. Go 컴파일러 덕분에 Linux 또는 Windows에서 빌드하고, Linux 또는 Windows용으로 빌드할 수 있습니다. 빌드하려면 Go 1.18 이상이 필요합니다 (Go 1.23으로 테스트됨).

Linux에서 빌드

Linux에서 Windows 또는 Linux용으로 빌드하려면 GOOS를 적절히 설정하세요 (cli 디렉터리에서 실행):``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

죄송합니다. 제공된 입력이 없습니다. 빈 입력이 수신되었습니다.```
GOOS=linux GOARCH=amd64 go build -o wcfproxy

Windows에서 빌드

Windows에서 빌드하려면 PowerShell에서와 같이 동등한 명령을 실행하세요:``` $env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe

입력:```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy

사용법

wcfproxy의 구성은 JSON 파일을 통해 제공됩니다. 기본적으로 config.json 구성 파일이 사용되지만, 구성 파일 경로는 -config 매개변수로 지정할 수 있습니다. 구성 파일은 임의의 많은 명명된 구성을 포함하도록 설계되었습니다. 예를 들면 다음과 같습니다:```json { "my-config": { " ... ": " ... " } }

명명된 구성 객체들의 값은 `Config` 구조체와 일치해야 합니다 ([Config structure](#config-structure) 참조).
포함된 주석이 있는 이 소스 파일은 `wcfproxy`의 구성 옵션에 대한 가장 정확한 문서 역할도 합니다.
제공된 모든 구성 중에서 사용할 구성은 `-enable` 명령줄 옵션을 통해 이름으로 식별됩니다:```
wcfproxy.exe -config config.json -enable my-config

구성 구조

각 구성 객체의 최상위 구조는 다음과 같습니다:```json { "listen": "[::1]:8000", "connect": "[::1]:9000", "retarget": "net.tcp://127.0.0.1:8000/WCFLab/WCFDemoService/nettcp", "retarget-map": { "nettcps": "net.tcp://localhost:8210/WCFLab/WCFDemoService/nettcps", "winauth": "net.tcp://localhost:8220/WCFLab/WCFDemoService/nettcp-winauth" }, "log-level": "debug|info|warn|error", "log-file": "path/to/log/file", "tls-server": { " ... ": " ... " }, "tls-client": { " ... ": " ... " }, "ntlm": { " ... ": " ... " }, "interceptor": { " ... ": " ... " }, "ctrl": { " ... ": " ... " } }

NTLM 구성이 있는 경우 TLS 구성(`tls-server` 및/또는 `tls-client`)을 제공할 수 없습니다.

### Configuration options
+ `listen` - *wcfproxy*가 수신 대기해야 하는 TCP 엔드포인트입니다(예: `127.0.0.1:8000` 또는 `[::1]:8000`)
+ `connect` - 업스트림 WCF 서버의 TCP 엔드포인트입니다(예: `127.0.0.1:9000` 또는 `[::1]:9000`)
+ `retarget` - 원래 대상 지정(및 `retarget-map`의 폴백)입니다. 설명은 [대상 재작성](#target-rewriting)을 참조하세요
+ `retarget-map` - `retarget`의 일반화입니다. 여러 엔드포인트에 대해 대상 재작성을 수행할 수 있습니다(동일한 포트에서 여러 WCF 서비스를 사용하는 경우에만 유용함)
    + `retarget-map`의 키 중 하나가 현재 대상과 일치하면 대상 URI가 업스트림 통신을 위해 지정된 값으로 대체됩니다
    + `retarget-map`의 어떤 키도 현재 대상과 일치하지 않으면 대신 `retarget`이 사용됩니다
+ `log-level` - 로그 수준입니다. 사용 가능한 값: `debug`, `info`(기본값), `warn`, `error`
+ `log-file` - 로그 파일 경로입니다. 경로가 제공되지 않으면 로그가 `stdout`에 기록됩니다
+ `tls-server` - `TlsServerConfig`의 인스턴스입니다([TLS 서버 구성](#tls-server-configuration) 참조). TLS 업그레이드를 지원해야 하는 경우에만 필요합니다
+ `tls-client` - `TlsClientConfig`의 인스턴스입니다([TLS 클라이언트 구성](#tls-client-configuration) 참조). TLS 업그레이드를 지원해야 하는 경우에만 관련됩니다
+ `ntlm` - `NtlmConfig`의 인스턴스입니다([NTLM 구성](#ntlm-configuration) 참조). NTLM 업그레이드(직접 또는 SPNEGO를 통해)를 지원해야 하는 경우에만 필요합니다
+ `interceptor` - `InterceptorConfig`의 인스턴스입니다([인터셉터 구성](#interceptor-configuration) 참조). 필수입니다
+ `ctrl` - `ControlServerConfig`의 인스턴스입니다([제어 서버 구성](#control-server-configuration) 참조). 기본 HTTP 에코 서버(HTTP 인터셉터와 함께 유용함)와 메시지 흐름 제어를 위한 소형 API(아직 개발 중)를 제공할 수 있습니다

### TLS 서버 구성
TLS 서버 측 구성은 일반적으로 관련된 TLS 서버 설정을 대부분 제어할 수 있습니다.
다음 구조를 가집니다:```json
{
	"cert-pem": "path/to/certificate",
	"cert-key": "path/to/certificate-key",
	"max-version": "1.0|1.1|1.2|1.3",
	"min-version": "1.0|1.1|1.2|1.3",
	"client-roots": "path/to/client-ca1,path/to/client-ca2",
	"client-auth": "none|request|require-any|verify-if-given|require-and-verify",
	"keylog": "path/to/keylog-file"
}

TLS 서버 구성 옵션

• cert-pem - X.509 인증서 경로 (PEM 형식)
• cert-key - 인증서에 해당하는 키의 경로
• max-version - 허용 가능한 최대 TLS 버전; 1.0, 1.1, 1.2, 1.3 (기본값) 중 하나
• min-version - 허용 가능한 최소 TLS 버전; 1.0 (기본값), 1.1, 1.2, 1.3 중 하나
• client-roots - 클라이언트 인증을 위한 허용 가능한 루트 인증서(PEM) 경로의 쉼표로 구분된 목록; 선택 사항
• client-auth - 클라이언트 인증 정책; 가장 유용한 값: none (기본값), require-and-verify
• keylog - NNS 형식으로 TLS 비밀을 기록할 파일

TLS 클라이언트 구성

TLS 클라이언트 측 구성은 가장 일반적으로 관련된 TLS 클라이언트 설정을 제어합니다. 다음과 같은 구조를 가집니다:```json { "cert-pem": "path/to/certificate", "cert-key": "path/to/certificate-key", "max-version": "1.0|1.1|1.2|1.3", "min-version": "1.0|1.1|1.2|1.3", "roots": "path/to/root-ca1,path/to/root-ca2", "server-name": "therealone.local", "skip-verify": false }

#### TLS 클라이언트 구성 옵션
+ [TLS 서버 구성 옵션](#tls-server-configuration-options)과 유사
+ `roots` - 루트 CA(PEM)의 쉼표로 구분된 경로 목록; `skip-verify`와 함께 선택 사항
+ `server-name` - 서버 이름(SNI); 선택 사항
+ `skip-verify` - bool; 클라이언트가 서버 인증서 검증을 생략할지 여부 (기본값: `false`)

### NTLM 구성
NTLM 구성은 도메인, 서버 이름 및 사용자 자격 증명을 지정합니다.
프록시에 대해 인증할 수 있어야 하는 각 사용자에 대해 유효한 자격 증명이 제공되어야 합니다.```json
{
	"domain": "test.local",
	"server": "server.local",
	"credentials": [
		{ 
            " ... ": " ... "
        }
	]
}

NTLM 구성 옵션

• domain - 인증할 도메인 (예: test.local); 비워두면 서버 이름이 사용됩니다
• server - 인증할 서버 이름; 비워두면 현재 시스템의 호스트 이름이 사용됩니다
• credentials - NtlmCredential 객체의 배열 (아래 참조)

NTLM 자격 증명(credentials)은 다음과 같은 구조의 NtlmCredential 객체 배열로 전달됩니다:```json { "name": "wcflab", "password": "Sup3rS3cr3t", "nt-hash": "a8fc07dede90b0ec10bc1ef355f99292", "lm-hash": "3e9cb63e11a812cbc467021088dc706f" }

+ `name` - 사용자 이름
+ `password` - 사용자의 비밀번호; 이로부터 해시가 생성됨; 사용자에 대해 주어진 해시보다 우선 적용됨
+ `nt-hash` - 사용자 비밀번호의 NT 해시(16진수); 비밀번호 대신 사용 가능
+ `lm-hash` - 사용자 비밀번호의 LM 해시(16진수); 비밀번호 대신 사용 가능; 대부분의 경우 필요하지 않음

비밀번호가 제공되면 LM 해시(모든 비밀번호에 대해 가능하지는 않음)와 NT 해시가 계산됩니다.
이 사용자에 대해 제공된 모든 해시 값은 계산된 해시로 덮어쓰여집니다.
사용자 해시만 제공하는 것도 가능합니다.
LM 해시는 대부분의 시나리오에서 필요하지 않습니다.


### 인터셉터 구성
인터셉터 구성은 사용할 인터셉터(이름으로 지정)와 선택적으로 인터셉터별 인수를 지정합니다.
인터셉터에 대한 설명은 [인터셉터](#interceptors)를 참조하십시오.

#### 로그 인터셉터
로그 인터셉터를 사용하려면 다음 인터셉터 구성을 사용하면 됩니다.
출력은 주요 로깅 위치에 기록되며, `log-file` 구성에 따라 파일 또는 `stdout`일 수 있습니다.```json
{
	"name": "log"
}

Http 인터셉터

HTTP 인터셉터를 사용하려면, server-url 및 proxy-url에 적합한 옵션과 함께 다음의 인터셉터 구성을 사용하십시오.```json { "name": "http", "args": { "server-url": "http://127.0.0.1:9999/echo", "proxy-url": "http://127.0.0.1:8080" } }

+ `args.server-url` - HTTP 서버 가로채기 엔드포인트의 URL (예: 간단한 에코 엔드포인트); HTTP 인터셉터 작동 방식에 대한 자세한 내용은 [HTTP 인터셉터](#http-interceptor-1)를 참조하세요.
+ `args.proxy-url` - HTTP 프록시의 URL; 선택 사항

### 제어 서버 구성
*wcfproxy*는 두 가지 기능을 제공하는 내장 웹 서버와 함께 제공됩니다.
첫째, 전송된 모든 콘텐츠를 단순히 반사하는 HTTP 엔드포인트를 제공할 수 있습니다.
이는 [HTTP 인터셉터](#http-interceptor-1)와 함께 사용할 때 유용합니다.```json
{
	"ctrl": {
		"listen": "127.0.0.1:9999",
		"enable-control": false,
		"enable-echo": true
	}
}

[!WARNING]
API에 접근할 수 있는 모든 사용자는 제공된 자격 증명(NTLM 또는 TLS 클라이언트 인증서)을 사용하여 인증할 수 있습니다. 공유 시스템의 경우 API가 로컬에서만 사용 가능하더라도 이는 관련될 수 있습니다.

제어 서버 구성 옵션

• listen - 제어 서버가 수신 대기해야 하는 TCP 엔드포인트
• enable-contorl - 메시지 주입 또는 연결 설정과 같은 제어 기능을 활성화합니다 (메시지 주입 참조)
• enable-echo - http://{listen}/echo 에서 간단한 HTTP 에코 서버를 활성화합니다

세부 사항

다음 섹션에서는 WCF와 일부 구성 옵션을 더 잘 이해하는 데 도움이 될 수 있는 배경 정보를 제공합니다.

대상 재작성

의도된 WCF 엔드포인트는 net.tcp 프리앰블과 SOAP 봉투에 전송되는 To 헤더에 인코딩됩니다. 서버는 이 엔드포인트 사양이 예상된 것과 일치하는지 확인할 수 있습니다. 클라이언트가 원래 서버 대신 프록시에 연결하도록 조작되면 이 엔드포인트 사양이 변경될 가능성이 높으며 서버가 통신을 거부할 수 있습니다. 따라서 일반적으로 서버로 나가는 트래픽에서 엔드포인트 사양을 수정하는 것이 좋습니다. 이를 위해 구성 파일의 retarget 옵션에 원래 엔드포인트 사양(예: 클라이언트 구성에서 얻은)을 제공하십시오. 엔드포인트 사양은 일반적으로 다음과 같습니다: net.tcp://some/endpoint.

여러 WCF 엔드포인트를 동시에 작업할 때 모든 엔드포인트에 대해 대상 재작성을 수행해야 할 수 있습니다. 이를 위해 retarget-map 옵션이 있으며, 이 옵션은 대상 URI 간의 매핑을 정의합니다. retarget-map에서 일치하는 항목이 없으면 대상 URI는 retarget에 지정된 값으로 변경됩니다.

유형 힌트

MC-NBFX에 의해 지정된 바이너리 XML은 기본 유형 정보를 바이너리 형식(레코드 유형)으로 인코딩합니다. 이 정보의 일부는 바이너리 XML 문서의 (텍스트) XML 표현에서 쉽게 복구할 수 없습니다. 이러한 이유로 wcfproxy는 XML 문자 데이터(및 일부 속성) 토큰에 유형 힌트를 삽입합니다. 이러한 유형 힌트는 <h>: 형식을 가지며, 여기서 <h>는 일부 유형을 인코딩하는 짧은 문자열입니다(예: 정수의 경우 i, 문자의 경우 ch). 전체 유형 힌트 목록은 typehint.go에서 확인할 수 있습니다. 유형 힌트를 조작하는 것은 권장되지 않습니다.