- **मुख्य विशेषताएँ**: सिस्टम निगरानी, अलर्ट, रिपोर्टिंग
- **एकीकरण**: Prometheus, Grafana, Slack के साथ काम करता है```
GOOS=linux GOARCH=amd64 go build -o wcfproxy

contribute to the project. Whether you are a beginner or an experienced developer, there are many ways to get involved.

- Reporting bugs
- Suggesting enhancements
- Writing code improvements
- Improving documentation
- Helping others in discussions

## Bug Reports and Feature Requests

If you encounter a bug or have an idea for a new feature, please search the [issue tracker](https://github.com/yourproject/issues) to check if it has already been reported. If not, feel free to [open a new issue](https://github.com/yourproject/issues/new). Provide as much detail as possible to help us understand and address the issue.

## Pull Requests

1. Fork the repository.
2. Create a new branch (`git checkout -b feature-branch`).
3. Make your changes.
4. Commit your changes (`git commit -m 'Add some feature'`).
5. Push to the branch (`git push origin feature-branch`).
6. Open a pull request.

Please ensure your code adheres to our coding standards and includes appropriate tests if applicable.

## Community

Join our [Discord](https://discord.gg/example) server to connect with other users and contribute to the discussion.```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy

{
  "example": {
    "enabled": true,
    "listen": "127.0.0.1:8080",
    "target": "https://example.com/ws"
  }
}
``````json
{
	"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": {
         " ... ": " ... "
    }
}

#### 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
}

#### NTLM कॉन्फ़िगरेशन विकल्प
+ `domain` - प्रमाणीकरण के लिए डोमेन, जैसे test.local; यदि खाली छोड़ा जाता है, तो सर्वर का नाम उपयोग किया जाएगा
+ `server` - प्रमाणीकरण के लिए सर्वर का नाम; यदि खाली छोड़ा जाता है, तो वर्तमान सिस्टम का होस्ट नाम उपयोग किया जाएगा
+ `credentials` - `NtlmCredential` का सरणी (नीचे देखें)

NTLM credentials को `NtlmCredential` ऑब्जेक्ट्स की एक सरणी के रूप में पास किया जाता है, जिनकी निम्नलिखित संरचना है:```json
{
	"name": "wcflab",
	"password": "Sup3rS3cr3t",
	"nt-hash": "a8fc07dede90b0ec10bc1ef355f99292",
	"lm-hash": "3e9cb63e11a812cbc467021088dc706f"
}

#### 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"
	}
}

> [!चेतावनी]  
> जो कोई भी API तक पहुंच सकता है, वह प्रदान किए गए क्रेडेंशियल्स (NTLM या TLS क्लाइंट प्रमाणपत्र) का उपयोग करके प्रमाणित कर सकता है।
> साझा सिस्टम पर यह प्रासंगिक हो सकता है भले ही API केवल स्थानीय रूप से उपलब्ध हो।

### नियंत्रण सर्वर कॉन्फ़िगरेशन विकल्प
+ `listen` - वह TCP एंडपॉइंट जहां नियंत्रण सर्वर को सुनना चाहिए
+ `enable-contorl` - संदेश इंजेक्शन या कनेक्शन स्थापना जैसी नियंत्रण सुविधाओं को सक्षम करता है (देखें [संदेश इंजेक्शन](#message-injection))
+ `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` में दिए गए मान में बदल दिया जाएगा।

## प्रकार संकेत
बाइनरी XML, जैसा कि `MC-NBFX` द्वारा निर्दिष्ट है, बाइनरी प्रारूप (रिकॉर्ड प्रकार) में मूल प्रकार की जानकारी को एन्कोड करता है।
इस जानकारी का सभी कुछ बाइनरी XML दस्तावेज़ के (पाठ्य) XML प्रतिनिधित्व से आसानी से पुनर्प्राप्त नहीं किया जा सकता है।
इस कारण से, *wcfproxy* XML कैरेक्टर डेटा (और कुछ विशेषता) टोकन में प्रकार संकेत सम्मिलित करता है।
ये प्रकार संकेत `<h>:` का रूप लेते हैं जहाँ `<h>` एक छोटी स्ट्रिंग है जो कुछ प्रकार को एन्कोड करती है (उदा. `i` पूर्णांक के लिए, `ch` वर्णों के लिए)।
प्रकार संकेतों की पूरी सूची [typehint.go](https://github.com/syss-research/wcfproxy/blob/HEAD/binxml/typehint.go) में पाई जा सकती है।
प्रकार संकेतों के साथ छेड़छाड़ करने की सलाह नहीं दी जाती है।

## इंटरसेप्टर
इंटरसेप्टर निर्दिष्ट करते हैं कि प्राप्त ट्रैफ़िक को कैसे संभाला जाता है और [इंटरसेप्टर कॉन्फ़िगरेशन](#interceptor-configuration) के माध्यम से निर्दिष्ट किए जाते हैं।
वे दोनों दिशाओं (क्लाइंट -> सर्वर और सर्वर -> क्लाइंट) में भेजे गए ट्रैफ़िक को संभालते हैं।
वर्तमान में दो इंटरसेप्टर हैं: **log** और **http**।

### Log इंटरसेप्टर
**log** इंटरसेप्टर बाइनरी एन्कोडेड SOAP लिफाफों को नियमित टेक्स्ट-आधारित XML का उपयोग करके एन्कोड किए गए मानव-पठनीय समकक्षों में परिवर्तित करता है।
कोई सक्रिय हेरफेर (लक्ष्य विनिर्देश पुनर्लेखन को छोड़कर) नहीं किया जाता है।
आउटपुट निर्दिष्ट लॉग स्थान (डिफ़ॉल्ट रूप से `stdout`) पर भेजा जाता है।
लॉग स्तर को `info` (या `debug`) पर सेट करना सुनिश्चित करें, अन्यथा प्रासंगिक आउटपुट दबा दिया जाता है।

### HTTP इंटरसेप्टर
**http** इंटरसेप्टर बाइनरी SOAP लिफाफों को उनके टेक्स्ट-आधारित समकक्षों में परिवर्तित करता है और उन्हें `-http-url` द्वारा निर्दिष्ट HTTP एंडपॉइंट पर भेजता है।
डिकोड किए गए SOAP संदेश अनुरोध निकाय में भेजे जाते हैं।
HTTP सर्वर को आने वाले संदेशों के समान प्रारूप में एक मान्य SOAP लिफाफा लौटाना चाहिए।
इन संदेशों को फिर मूल बाइनरी प्रारूप में वापस रूपांतरित किया जाता है और अपस्ट्रीम सर्वर को भेजा जाता है।

मूल संदेश को प्रतिबिंबित करना HTTP सर्वर के लिए हमेशा एक मान्य विकल्प है।
हालांकि, संदेशों में प्रोग्रामेटिक हेरफेर एक कस्टम HTTP सर्वर प्रदान करके भी प्राप्त किया जा सकता है जो वांछित प्रतिस्थापन करता है।
SOAP संदेशों की संरचना को तोड़ने से बचने के लिए सावधानी बरतनी चाहिए।
जब तक आप यह नहीं जानते कि आप क्या कर रहे हैं, तब तक संदेशों के प्रारूप के साथ छेड़छाड़ न करने की सलाह दी जाती है।
इसके अलावा, *wcfproxy* द्वारा डाले गए प्रकार संकेतों के साथ छेड़छाड़ नहीं की जानी चाहिए, क्योंकि इससे टेक्स्ट-आधारित SOAP संदेशों को वापस बाइनरी समकक्षों में रूपांतरित करने या वैध एंडपॉइंट (क्लाइंट या सर्वर) पर संदेश पार्सिंग टूट सकती है।

*wcfproxy* एक तुच्छ HTTP सर्वर के साथ आता है जो प्राप्त HTTP अनुरोधों के निकाय को प्रतिबिंबित करता है।
यह सर्वर तब शुरू किया जाएगा जब [नियंत्रण सर्वर कॉन्फ़िगरेशन](#control-server-configuration) प्रदान किया जाता है और `enable-echo` विकल्प `true` पर सेट होता है।
वांछित HTTP सर्वर का URL [http इंटरसेप्टर कॉन्फ़िगरेशन](#http-interceptor) में `server-url` विकल्प के माध्यम से प्रदान किया जाता है।

इंटरैक्टिव हेरफेर की अनुमति देने के लिए, एक HTTP प्रॉक्सी (जैसे BurpSuite) को `proxy-url` विकल्प के माध्यम से निर्दिष्ट किया जा सकता है।
संदेश तब निर्दिष्ट HTTP प्रॉक्सी के माध्यम से HTTP सर्वर को भेजे जाएंगे।
ध्यान दें कि प्रत्येक WCF संदेश (जैसे क्लाइंट -> सर्वर) के लिए, एक HTTP अनुरोध-प्रतिक्रिया जोड़ी उत्पन्न होती है।

संदेशों को उस net.tcp कनेक्शन से सहसंबंधित करने के लिए जहां से वे उत्पन्न हुए, हेडर `X-Wcpf-Conn-Id` को **http** इंटरसेप्टर द्वारा उत्पन्न अनुरोधों में डाला जाता है।

निम्नलिखित छवि **http** इंटरसेप्टर के साथ डेटा प्रवाह को दर्शाती है।

![http-interceptor illustration](https://raw.githubusercontent.com/syss-research/wcfproxy/HEAD/doc/http-interceptor.svg)

## TLS विकल्प
WCF (net.tcp पर) परिवहन सुरक्षा के लिए TLS का उपयोग कर सकता है।
*wcfproxy* TLS कनेक्शनों (केवल TLS 1.0 - 1.3, SSL नहीं) के अवरोधन का समर्थन करता है।
सर्वर-साइड और क्लाइंट-साइड TLS सेटिंग्स को संबंधित TLS कॉन्फ़िगरेशन (देखें [TLS सर्वर कॉन्फ़िगरेशन](#tls-server-configuration) या [TLS क्लाइंट कॉन्फ़िगरेशन](#tls-client-configuration)) के साथ नियंत्रित किया जा सकता है।

## NTLM विकल्प
*wcfproxy* NTLM प्रमाणीकरण का समर्थन करता है।
वर्तमान में, प्रत्यक्ष NTLM प्रमाणीकरण या SPNEGO के माध्यम से बातचीत समर्थित है।
आपको प्रमाणित करने वाले उपयोगकर्ता(ओं) के क्रेडेंशियल्स प्रदान करने होंगे।
ये क्रेडेंशियल्स JSON प्रारूप में प्रदान किए जाते हैं, [NTLM कॉन्फ़िगरेशन](#ntlm-configuration) देखें।
हैश पास करना `nt-hash` गुण के माध्यम से हैश प्रदान करके समर्थित है।

## संदेश इंजेक्शन और कनेक्शन स्थापना
जब [नियंत्रण सर्वर](#control-server-configuration) सक्षम होता है, तो एक छोटा HTTP API प्रदान किया जाता है जिसका उपयोग कनेक्शन स्थापित करने या समाप्त करने और मौजूदा कनेक्शनों में संदेश इंजेक्ट करने के लिए किया जा सकता है।
निम्नलिखित एंडपॉइंट उपलब्ध हैं।

### GET `/connection`
वर्तमान में सक्रिय कनेक्शनों की सूची बनाएं।
केवल-सर्वर कनेक्शनों (POST /connection/new के माध्यम से बनाए गए) के लिए, क्लाइंट को `wcfproxy` के रूप में दिखाया जाएगा।

### POST `/connection/new`
एक नया कनेक्शन बनाएं।
बॉडी एक JSON ऑब्जेक्ट होना चाहिए जो इच्छित अपग्रेड (TLS या Negotiate (NTLM)) निर्दिष्ट करता हो, यदि कोई हो।
एंडपॉइंट URI `target-uri` गुण के माध्यम से प्रदान किया जाता है।

#### उदाहरण: कोई अपग्रेड नहीं
यदि किसी अपग्रेड की आवश्यकता नहीं है, तो `upgrade` गुण को छोड़ा जा सकता है।```json
{
    "target-uri":"net.tcp://127.0.0.1:9510/example/notes-nettcp"
}

#### उदाहरण: NTLM अपग्रेड
`upgrade` ऑब्जेक्ट को तंत्र के रूप में `ntlm` और प्रमाणित करने के लिए उपयोगकर्ता निर्दिष्ट करना होगा।
उपयोगकर्ता के क्रेडेंशियल `ntlm` कॉन्फ़िगरेशन के साथ प्रदान किए जाने चाहिए।```json
{
    "target-uri":"net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcp-winauth",
    "upgrade": {
		"mechanism": "ntlm",
		"ntlmuser": "wcflab"
	}
}

उपरोक्त कॉन्फ़िगरेशन (`config.json` में रखा गया) के साथ, हम इसका उपयोग नीचे दिखाए अनुसार कर सकते हैं।
प्रॉक्सी पर ट्रैफ़िक तब कंसोल (`stdout`) पर डंप किया जाना चाहिए।```
> .\wcfproxy.exe -config .\config.json -enable wcflab-plain
2025/07/10 15:03:59 dbg: local time zone (for DateTime handling): CEST
INFO:  Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201
INFO:  No server certificates given. TLS upgrade not supported.
INFO:  No client certificates given. TLS client authentication not supported.
INFO:  Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp
INFO:  [proxy] Handling new connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201
INFO:  [proxy] Connection 0 established (127.0.0.1:50216 <-> 127.0.0.1:8201)
INFO:  [proxy] Envelope (Connection 0, Client -> Server):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action>
  <a:MessageID>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:MessageID>
  <a:ReplyTo>
   <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address>
  </a:ReplyTo>
  <a:To s:mustUnderstand="c:1">ch:net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp</a:To>
 </s:Header>
 <s:Body>
  <AddInts xmlns="http://tempuri.org/">
   <a>i:1234</a>
   <b>i:37</b>
  </AddInts>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Envelope (Connection 0, Server -> Client):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action>
  <a:RelatesTo>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:RelatesTo>
  <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To>
 </s:Header>
 <s:Body>
  <AddIntsResponse xmlns="http://tempuri.org/">
   <AddIntsResult>i:1271</AddIntsResult>
  </AddIntsResponse>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Connection 0 closed (127.0.0.1:50216 <-> 127.0.0.1:8201)
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50217->127.0.0.1:8201: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201

इस कॉन्फ़िगरेशन के साथ, लॉग में कुछ भी दिलचस्प नहीं दिखता है।```
> go run ./ -config .\config.json -enable wcflab-plain-http
2025/07/10 18:06:02 dbg: local time zone (for DateTime handling): CEST
2025/07/10 18:06:02 DBG - configuring intercrptor: &{http map[proxy-url:http://127.0.0.1:8080]}
INFO:  Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201
INFO:  No server certificates given. TLS upgrade not supported.
INFO:  No client certificates given. TLS client authentication not supported.
INFO:  Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp
INFO:  [proxy] Starting control server on 127.0.0.1:9999 (echo enabled: true, control enabled: false)
INFO:  [proxy] Handling new connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:22665->127.0.0.1:8201: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201

ध्यान दें कि क्लाइंट को सर्वर प्रमाणपत्र (`server.pem`) पर भरोसा करने की आवश्यकता है।
इसके अलावा, सर्वर को *wcfproxy* के क्लाइंट भाग द्वारा प्रस्तुत प्रमाणपत्र (`client.pem`) पर भरोसा करना चाहिए।```
> .\wcfproxy.exe -config .\config.json -enable wcflab-mtls
2025/07/10 15:01:32 dbg: local time zone (for DateTime handling): CEST
INFO:  Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564)
INFO:  Listening on 127.0.0.1:7203 and connecting to 127.0.0.1:8203
INFO:  Using server certificate wcflab.local (SHA256-fingerprint: 7286ff75d3bb6dc4d96c0c8ac08dbac2204af67e0b1814b3d8c59c24d5bd781a)
INFO:  Server supports TLS versions 1.0 - 1.3
INFO:  Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564)
INFO:  Client supports TLS versions 1.0 - 1.3
INFO:  Retargeting to net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls
INFO:  [proxy] Handling new connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203
INFO:  [proxy] Connection 0 established (127.0.0.1:50214 <-> 127.0.0.1:8203)
INFO:  [proxy] Initiating TLS upgrade
INFO:  [proxy] 127.0.0.1:50214 <-> 127.0.0.1:7203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
INFO:  [proxy] 127.0.0.1:50215 <-> 127.0.0.1:8203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
INFO:  [proxy] Upgrade done
INFO:  [proxy] Envelope (Connection 0, Client -> Server):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action>
  <a:MessageID>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:MessageID>
  <a:ReplyTo>
   <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address>
  </a:ReplyTo>
  <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls</a:To>
 </s:Header>
 <s:Body>
  <AddInts xmlns="http://tempuri.org/">
   <a>i:1234</a>
   <b>i:37</b>
  </AddInts>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Envelope (Connection 0, Server -> Client):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action>
  <a:RelatesTo>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:RelatesTo>
  <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To>
 </s:Header>
 <s:Body>
  <AddIntsResponse xmlns="http://tempuri.org/">
   <AddIntsResult>i:1271</AddIntsResult>
  </AddIntsResponse>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Connection 0 closed (127.0.0.1:50214 <-> 127.0.0.1:8203)
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50215->127.0.0.1:8203: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203

ध्यान दें कि वर्तमान में स्वचालित कॉन्फ़िगरेशन पर निर्भर रहने की तुलना में `server` या `domain` फ़ील्ड के माध्यम से होस्ट नाम प्रदान करना अधिक विश्वसनीय है।
इसके अलावा, AD डोमेन संदर्भ में प्रमाणीकरण का परीक्षण नहीं किया गया है और इसलिए फ़िलहाल इसके कार्यशील न होने की संभावना है।
जब SPNEGO का उपयोग किया जाता है, तो वर्तमान में NTLM तंत्र को प्राथमिकता दी जानी चाहिए, अन्यथा वार्ता विफल हो जाएगी।```
> .\wcfproxy.exe -config .\config.json -enable wcflab-ntlm
2025/07/10 15:15:15 dbg: local time zone (for DateTime handling): CEST
INFO:  Listening on [::1]:7204 and connecting to [::1]:8204
INFO:  No server certificates given. TLS upgrade not supported.
INFO:  No client certificates given. TLS client authentication not supported.
INFO:  Retargeting to net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth
INFO:  [proxy] Handling new connection 0: [::1]:50247 <-> [::1]:8204
INFO:  [proxy] Connection 0 established ([::1]:50247 <-> [::1]:8204)
INFO:  [proxy] Initiating Negotiate upgrade
INFO:  [NTLM server] User wcflab authenticated successfully
INFO:  [proxy] [::1]:50247 <-> [::1]:7204: negotiated NTLM
INFO:  [proxy] [::1]:50248 <-> [::1]:8204: negotiated NTLM
INFO:  [proxy] Upgrade done
INFO:  [proxy] Envelope (Connection 0, Client -> Server):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action>
  <a:MessageID>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:MessageID>
  <a:ReplyTo>
   <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address>
  </a:ReplyTo>
  <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth</a:To>
 </s:Header>
 <s:Body>
  <AddInts xmlns="http://tempuri.org/">
   <a>i:1234</a>
   <b>i:37</b>
  </AddInts>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Envelope (Connection 0, Server -> Client):
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
 <s:Header>
  <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action>
  <a:RelatesTo>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:RelatesTo>
  <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To>
 </s:Header>
 <s:Body>
  <AddIntsResponse xmlns="http://tempuri.org/">
   <AddIntsResult>i:1271</AddIntsResult>
  </AddIntsResponse>
 </s:Body>
</s:Envelope>
INFO:  [proxy] Connection 0 closed ([::1]:50247 <-> [::1]:8204)
ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp [::1]:50248->[::1]:8204: i/o timeout. Entering fault state.
INFO:  [proxy] Done handling connection 0: [::1]:50247 <-> [::1]:8204