بناء

يمكنك إما تجميع الأداة مرة واحدة ثم استخدام الملف الثنائي الناتج، أو تشغيلها "مثل السكربت" (ستقوم سلسلة أدوات Go بتجميعها أثناء التشغيل). للتطوير، الخيار الثاني مريح. للاستخدام الإنتاجي، يُوصى بتجميعها مرة واحدة (من دليل cli) واستخدام الملف التنفيذي الناتج. بفضل مترجم Go، يمكنك البناء من أجل Linux أو Windows ومنهما. يلزم إصدار 1.18 على الأقل من Go للبناء (مُختبر مع Go 1.23).

البناء من Linux

للبناء من Linux من أجل Windows أو Linux، ما عليك سوى تعيين GOOS بشكل مناسب (نفذ من دليل cli):``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

- بالنسبة لـ `ns_query`: للاستعلام عن خادم الأسماء لنطاق ما.
- بالنسبة لـ `ns_answer`: الرد من الخادم .
- بالنسبة لـ `ns_query`: منافذ المصدر والوجهة.```
GOOS=linux GOARCH=amd64 go build -o wcfproxy

البناء من Windows

للبناء من Windows، نفذ الأوامر المكافئة، على سبيل المثال من PowerShell:``` $env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe

تمت كتابة وحدة التحكم وواجهة المستخدم الرسومية باستخدام [Stuart](https://github.com/Bee-Mar/mmpm) وهي مباشرة جدًا وسهلة الاستخدام. يوجد ملف تكوين في `$HOME/.config/mmpm/config.json` يتم تحريره من خلال واجهة المستخدم الرسومية، لتجنب التحرير اليدوي للملف مباشرةً. كما يتم عرض جميع حزم MagicMirror المُثبّتة في واجهة المستخدم الرسومية أيضًا.

يستخدم MMPM حزمة طرف ثالث من [MagicMirror](https://magicmirror.builders) تُدعى [web-scraper](https://github.com/Bee-Mar/mmpm/wiki/MagicMirror-Package-Lists#mmpm-list-of-available-magicmirror-packages)، والتي تقدم للمجتمع تجربة أكثر اتساقًا ودقة وسهولة في الصيانة.```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy

الاستخدام

يتم توفير الإعدادات الخاصة بـ wcfproxy عبر ملف JSON. افتراضيًا، يتم استخدام ملف الإعدادات config.json، ولكن يمكن تحديد مسار ملف إعدادات باستخدام الوسيط -config. ملف الإعدادات مصمم لاحتواء عدد غير محدود من الإعدادات المسماة، كما يلي:

{
  "configs": {
    "default": {
      "listen": "0.0.0.0:8080",
      "target": "192.168.1.100:80"
    }
  }
}
``````json
{
	"my-config": { 
        " ... ": " ... " 
    }
}

قيمة كائنات التهيئة المُسماة يجب أن تتطابق مع بنية Config (انظر هيكل التهيئة). يعمل ملف المصدر هذا مع التعليقات المضمنة أيضًا كأفضل وثائق دقيقة لخيارات التهيئة لـ 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": {
         " ... ": " ... "
    }
}

لاحظ أن تكوين TLS (tls-server و/أو tls-client) لا يمكن توفيره في حالة وجود تكوين NTLM.

خيارات التهيئة

• listen - نقطة نهاية TCP التي يجب أن يستمع إليها wcfproxy، مثلاً 127.0.0.1:8000 أو [::1]:8000
• connect - نقطة نهاية TCP لخادم WCF العلوي، مثلاً 127.0.0.1:9000 أو [::1]:9000
• retarget - مواصفات الهدف الأصلي (والاحتياطي لـ retarget-map)؛ للشرح انظر إعادة كتابة الهدف
• retarget-map - تعميم لـ retarget؛ يسمح بإجراء إعادة كتابة الهدف لنقاط نهاية متعددة (مفيد فقط عند العمل مع خدمات WCF متعددة على نفس المنفذ)
  • إذا تطابق أحد المفاتيح في retarget-map مع الهدف الحالي، سيتم استبدال URI الهدف بالقيمة المحددة للاتصال العلوي
  • إذا لم يتطابق أي مفتاح في retarget-map مع الهدف الحالي، سيتم استخدام retarget بدلاً من ذلك
• log-level - مستوى السجل؛ القيم المتاحة: debug، info (افتراضي)، warn، error
• log-file - مسار ملف السجل؛ إذا لم يتم توفير مسار، يُكتب السجل إلى stdout
• tls-server - مثيل لـ TlsServerConfig (انظر تكوين خادم TLS)؛ مطلوب فقط إذا كان يجب دعم ترقية TLS
• tls-client - مثيل لـ TlsClientConfig (انظر تكوين عميل TLS)؛ ذو صلة فقط إذا كان يجب دعم ترقية TLS
• ntlm - مثيل لـ NtlmConfig (انظر تكوين NTLM)؛ مطلوب فقط إذا كان يجب دعم ترقية NTLM (مباشرة أو عبر SPNEGO)
• interceptor - مثيل لـ InterceptorConfig (انظر تكوين المعترض)؛ مطلوب
• ctrl - مثيل لـ ControlServerConfig (انظر تكوين خادم التحكم) والذي يمكن أن يوفر خادم HTTP افتراضي للصدى (مفيد مع معترض HTTP) بالإضافة إلى واجهة برمجة تطبيقات صغيرة للتحكم في تدفق الرسائل (لا يزال قيد التطوير)

تكوين خادم 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` - ملف لكتابة أسرار TLS بتنسيق NNS

### تكوين عميل 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
• roots - المسار إلى قائمة مفصولة بفواصل لمسارات شهادات الجذر (PEM)؛ اختياري مع skip-verify
• server-name - اسم الخادم (SNI)؛ اختياري
• skip-verify - منطقي؛ ما إذا كان يجب على العميل تخطي التحقق من شهادة الخادم (الافتراضي: false)

تكوين NTLM

يحدد تكوين NTLM اسم المجال واسم الخادم بالإضافة إلى بيانات اعتماد المستخدم. لكل مستخدم يجب أن يكون قادرًا على المصادقة عبر الوكيل، يجب توفير بيانات اعتماد صالحة.```json { "domain": "test.local", "server": "server.local", "credentials": [ { " ... ": " ... " } ] }

#### خيارات تكوين NTLM
+ `domain` - المجال الذي سيتم المصادقة ضده، على سبيل المثال test.local؛ إذا تُرك فارغًا، سيتم استخدام اسم الخادم
+ `server` - اسم الخادم الذي سيتم المصادقة ضده؛ إذا تُرك فارغًا، سيتم استخدام اسم المضيف للنظام الحالي
+ `credentials` - مصفوفة من `NtlmCredential` (انظر أدناه)

يتم تمرير بيانات اعتماد NTLM كمصفوفة من كائنات `NtlmCredential`، والتي لها الهيكل التالي:```json
{
	"name": "wcflab",
	"password": "Sup3rS3cr3t",
	"nt-hash": "a8fc07dede90b0ec10bc1ef355f99292",
	"lm-hash": "3e9cb63e11a812cbc467021088dc706f"
}

• name - اسم المستخدم
• password - كلمة مرور المستخدم؛ سيتم اشتقاق التجزئات منها؛ تتجاوز التجزئات المعطاة للمستخدم
• nt-hash - تجزئة NT (سداسي عشري) لكلمة مرور المستخدم؛ بديل لكلمة المرور
• lm-hash - تجزئة LM (سداسي عشري) لكلمة مرور المستخدم؛ بديل لكلمة المرور؛ لا ينبغي أن تكون مطلوبة في معظم الحالات

إذا تم تقديم كلمة مرور، يتم حساب تجزئة LM (غير ممكنة لجميع كلمات المرور) وتجزئة NT منها. سيتم الكتابة فوق أي قيم تجزئة معطاة لهذا المستخدم بواسطة التجزئات المحسوبة. من الممكن أيضًا تقديم تجزئة (تجزئات) المستخدم فقط. لا ينبغي أن تكون تجزئة LM مطلوبة في معظم السيناريوهات.