# Phala / Intel TDX · اعلیٰ یقین دہانی کے ساتھ تعیناتی

Canonical page: https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/

Hetzner یا Phala Cloud پر ایک سیل شدہ 24/7 سرور، Gateway DNS اور وہ چیکس جنہیں تیسری پارٹی دہرا سکتی ہے۔

[Project context and measured scale](https://phishdestroy.github.io/TgWitness/docs/reference/overview/)

[Documentation index](https://phishdestroy.github.io/TgWitness/ur/llms.txt)

Translation coverage: this edition includes material from the English original.

Hetzner یا Phala Cloud پر ایک سیل شدہ 24/7 سرور، Gateway DNS اور وہ چیکس جنہیں تیسری پارٹی دہرا سکتی ہے۔

[ٹی جی وٹنس](https://github.com/phishdestroy/TgWitness/blob/main/README.md) / [دستاویزات](https://github.com/phishdestroy/TgWitness/blob/main/docs/README.md) · [تیناری اور بحالی](https://phishdestroy.github.io/TgWitness/ur/docs/reference/deployment/)

![تیناری اور بحالی](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg)

اعلیٰ یقین والی تعیناتی آرکائیو کی تصدیق میں جمع کرنے کے ماحول کی آزادانہ جانچ شامل کرتی ہے۔ جائزہ لینے والا کلاؤڈ فراہم کنندہ اور Cloudflare کے پاس موجود تعیناتی اور رسائی کے ریکارڈز کو دریافت کرتا ہے، اور Intel TDX تعیناتی جمع کرنے والے کے ماحول کی ہارڈویئر تصدیق شامل کرتی ہے۔

عام مقامی اور Docker استعمال میں کوئی تبدیلی نہیں آئی۔ یہاں کچھ بھی نہیں چلتا جب تک آپ کو `python -m tgwitness.cloud` کے ساتھ تعینات کریں، اور کلیکٹر صرف اسی وقت اپنے ہوسٹ کو پڑھتا ہے جب تعیناتی سیٹ کرتی ہے۔ `TGWITNESS_ASSURANCE`.

دھارے کا خاکہ · آپریٹر → سرور، فائر وال بغیر ان باؤنڈ قواعد کے (فراہم کنندہ API); آپریٹر → ٹنل اور DNS (Cloudflare API); سرور، فائر وال بغیر ان باؤنڈ قواعد کے → ٹنل اور DNS (صرف آؤٹ باؤنڈ); سرور، فائر وال بغیر ان باؤنڈ قواعد کے → سرور پر بنائی گئی دستخطی کلید; تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → پراویڈر لاگ اور فائر وال; تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → ٹنل کنیکٹر کا پتہ اور داخلہ; تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → دستخط شدہ /api/assurance بیان; تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → شواہد کا زپ · آپریٹر · تصدیق کنندہ، صرف پڑھنے کےلیے ٹوکنز · سرور، فائر وال بغیر انباؤنڈ قواعد کے · پراویڈر لاگ اور فائر وال · ٹنل کنیکٹر کا پتہ اورداخلہ · دستخط شدہ /api/assuranceبیان · شواہد کا زپ · ٹنل اور DNS · سرور پر بنائی گئی دستخطیکلید · فراہم کنندہ API · Cloudflare API · صرف آؤٹ باؤنڈ

**ڈایاگرام بطور متن**

1. آپریٹر → سرور، فائر وال بغیر ان باؤنڈ قواعد کے (فراہم کنندہ API)
2. آپریٹر → ٹنل اور DNS (Cloudflare API)
3. سرور، فائر وال بغیر ان باؤنڈ قواعد کے → ٹنل اور DNS (صرف آؤٹ باؤنڈ)
4. سرور، فائر وال بغیر ان باؤنڈ قواعد کے → سرور پر بنائی گئی دستخطی کلید
5. تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → پراویڈر لاگ اور فائر وال
6. تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → ٹنل کنیکٹر کا پتہ اور داخلہ
7. تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → دستخط شدہ /api/assurance بیان
8. تصدیق کنندہ، صرف پڑھنے کے لیے ٹوکنز → شواہد کا زپ

**اس صفحے پر**

- [ایک تصدیق کنندہ کیا چیک کر سکتا ہے](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#what-a-verifier-can-check)
- [فراہم کنندگان](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#providers)
- [Phala Cloud پر خفیہ VM (Intel TDX)](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx)
- [شروع کرنے سے پہلے](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#before-you-start)
- [پینل سے](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#from-the-panel)
- [ڈومین کے بغیر فوری سرنگ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#quick-tunnel-without-a-domain)
- [نشر کریں](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#deploy)
- [ڈی بیگ تعیناتی اور لاک](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#debug-deployment-and-lock)
- [ایک تعیناتی ہٹائیں](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#remove-a-deployment)
- [کوئی بھی سرور (خود تصدیق شدہ)](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#any-server-self-attested)
- [تصدیق کریں](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#verify)
- [شواہد کی حوالگی کے لیے رپورٹ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#report-for-evidence-handover)
- [Cloudflare بطور بیرونی گواہ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#cloudflare-as-an-outside-witness)
- [تینفاذ کے نتیجے کی پڑھائی](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#reading-the-deployment-result)

## ایک تصدیق کنندہ کیا چیک کر سکتا ہے

| دعویٰ | اس کی تصدیق کیسے کی جاتی ہے | کیپٹ بائی |
| --- | --- | --- |
| سرور کو ایک معلوم وقت پر فراہم کنندہ کی API کے ذریعے تخلیق کیا گیا تھا۔ | سرور آبجیکٹ اور اس کی تخلیق فراہم کنندہ کے اپنے لاگ میں | فراہم کنندہ |
| کسی نے بھی فراہم کنندہ کے رسائی کے راستے استعمال نہیں کیے | کنسول درخواستوں، ریسکیو، پاس ورڈ ری سیٹ، دوبارہ تعمیر، ISO، تصاویر، بیک اپ کا ریکارڈ | فراہم کنندہ |
| اس سے کچھ بھی منسلک نہیں ہو سکتا | پراویڈر فائر وال میں کوئی ان باؤنڈ قواعد نہیں ہیں؛ SSH کو پہلی بوٹ سے ہی چھپا دیا جاتا ہے۔ | فراہم کنندہ (فائر وال)، میزبان (SSH) |
| پینل صرف سرنگ کے ذریعے ہی پہنچا جا سکتا ہے۔ | ٹنل انگریس صرف پینل کی جانب فارورڈ ہوتا ہے؛ کنیکٹر سرور کے پتے سے چلتا ہے۔ | کلاؤڈ فلئیر |
| یہ بالکل یہی سافٹ ویئر چلتا ہے | کلیکٹر کے دستخط شدہ سورس ٹری ہیش تعینات کردہ کمٹ کے چیک آؤٹ کے برابر ہوتا ہے۔ | کلیکٹر، گٹ کے خلاف چیک کیا گیا |
| دستخطی کلید اسی سرور پر بنائی گئی تھی۔ | کلیدی بیان کو دستخط کرتی ہے جس میں فراہم کنندہ کے سرور آئی ڈی اور موصول شدہ cloud-init کے ہیش کا ذکر ہوتا ہے۔ | کلیکٹر، فراہم کنندہ کے خلاف چیک کیا گیا |
| یہ جرنل اُس کلید اور سرور کا ہے۔ | ہر عمل ثبوت میں شروع ہوتا ہے ZIP اس سرور کے لیے میزبان کی پیمائش کو لے کر جاتا ہے۔ | شواہد ZIP |

جمع کرنے والا SSH کی حالت، سیشنز، لاگ ان کی تاریخ اور بوٹ کی معلومات کو دستخط شدہ process-start اور `host.state` ریکارڈز میں درج کرتا ہے۔ ایک عام VM پر یہ مقامی انوینٹری ریکارڈز ہوتے ہیں، جن کا جائزہ لینے والا فراہم کنندہ کے آزاد ریکارڈز سے موازنہ کرتا ہے۔ ذیل میں Intel TDX تعیناتی اضافی طور پر ہارڈویئر کی پشت پناہی والے پیمائشوں کی تصدیق بھی کرتی ہے۔

## فراہم کنندگان

| `--provider` | اسناد | تصدیق کنندہ کی صرف پڑھنے کی اجازت | تصدیق کنندہ کے لیے فراہم کنندہ کا لاگ | کے لیے محفوظ |
| --- | --- | --- | --- | --- |
| `hetzner` | `HCLOUD_TOKEN` | اسی پروجیکٹ کا ٹوکن پڑھیں | سرور اور فائر وال کی کارروائیاں | جب تک یہ وسائل موجود ہیں |
| `digitalocean` | `DIGITALOCEAN_TOKEN` | صرف پڑھنے کے لیے ذاتی رسائی ٹوکن | ڈراپلیٹ ایکشنز | جب ڈراپلیٹ موجود ہو |
| `linode` | `LINODE_TOKEN` | `linodes`, `firewall`, `events` صرف پڑھنے کے دائرہ کار | اکاؤنٹ کے واقعات، فائر وال قواعد کے ورژنز | 90 دن |
| `vultr` | `VULTR_API_KEY` | وہ صارف جسے پڑھنے کی اجازت ہو اور `activity_logs` کی اجازت | اکاؤنٹ کی سرگرمی کا لاگ (طریقہ، راستہ، انجام دہندہ) | 30 دن، آڈٹ لاگ کی رکنیت کے ساتھ زیادہ طویل |
| `aws` | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` | `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups`, `cloudtrail:LookupEvents` | CloudTrail ایونٹ ہسٹری | 90 دن |
| `phala` | `PHALA_CLOUD_API_KEY` | اسی ورک اسپیس کی ایک API کلید | ایپلیکیشن میں ترامیم اور CVM آپریشنز: Docker Compose کی تشکیلات اور ماحول میں تبدیلیاں، دوبارہ آغاز، آپریٹنگ سسٹم کی اپ گریڈز | جبکہ یہ ایپلیکیشن موجود ہے |
| `generic` | کوئی نہیں | کوئی نہیں | کوئی نہیں: **خود تصدیق شدہ** | – |

ہر کیس کے لیے ایک مخصوص پروجیکٹ، ٹیم، اکاؤنٹ یا ذیلی اکاؤنٹ استعمال کریں: توثیق کنندہ کی صرف پڑھنے کی اجازت پھر صرف اسی تعیناتی کو دکھائے گی۔ اسناد سے پڑھی جاتی ہیں `--provider-token-file` یا اوپر دیے گئے متغیر سے، کبھی بھی کمانڈ لائن سے نہیں۔ AWS کے لیے فائل محفوظ کرتی ہے `ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]`؛ خطہ ہے `--location`.

جو کچھ ہر فراہم کنندہ کے ریکارڈز میں دکھایا نہیں جا سکتا، وہ ہر رپورٹ میں چھاپا جاتا ہے۔ مختصراً: ہیٹزنر کنسول کی درخواستوں کو لاگ کرتا ہے؛ ڈیجیٹل اوشن کا ریکوری کنسول، لائنوڈ کا لِش/گِش اور ولٹر کا ویب کنسول اس طرح لاگ نہیں ہوتے، لہٰذا پہلی بوٹ پر روٹ لاک ہو جاتا ہے اور کنسول لاگ ان کے لیے پاس ورڈ ری سیٹ یا بوٹ تبدیلی کی ضرورت ہوگی، جو لاگ کیے جاتے ہیں۔ ولٹر کنسول کا پتہ کسی بھی کی (key) کو واپس کر دیتا ہے جو انسٹنس کو پڑھ سکتی ہو؛ نہ ریکارڈ اور نہ ہی رپورٹ اسے محفوظ کرتی ہے۔

## فالا کلاؤڈ پر خفیہ ورچوئل مشین (Intel TDX)

کے ساتھ `--provider phala` کلیکٹر dstack کے زیرِ انتظام [Phala Cloud](https://phala.com/) پر ایک Intel TDX کنفیڈینشل ورچوئل مشین میں چلتا ہے۔ ہوسٹ اور Phala کا عملہ اس کی میموری نہیں پڑھ سکتا، اور پروسیسر اس بات کی تصدیق نامہ پر دستخط کرتا ہے کہ مشین نے کیا بوٹ کیا ہے۔ ویریفائر Phala کی بات پر یقین نہیں کرتا: `tgwitness.tdx` ہر تصدیق نامے کو خود، پن کیے گئے Intel SGX روٹ سی اے تک، Intel کی منسوخی کی فہرستوں اور Intel کے دستخط شدہ پلیٹ فارم ڈیٹا کے خلاف چیک کرتا ہے، اور ان مشینوں کو مسترد کر دیتا ہے جنہیں ڈی بگ یا منتقل کیا جا سکتا ہے۔

| رپورٹ اندراج | یہ کیا دکھاتا ہے |
| --- | --- |
| `tdx_binding` | تصدیق میں کلیکٹر کے دستخط شدہ بیان اور اس درخواست کی بے ترتیب قدر شامل ہے۔ |
| `tdx_quote` | Intel اس تصدیق کی ضمانت دیتا ہے؛ یہ صرف اس وقت منظور ہوتی ہے جب Intel پلیٹ فارم کو اپ ٹو ڈیٹ قرار دیتا ہے۔ |
| `tdx_compose_hash` | RTMR3، جو dstack ایونٹ لاگ سے دوبارہ چلایا گیا ہے، ایپ کمپوز کو ماپتا ہے جس کی رپورٹ کلیکٹر کرتا ہے۔ |
| `tdx_compose` | یہ کمپوز بائٹ بہ بائٹ وہی ہے جو تعینات کردہ کمٹ کے کوڈ سے بنتا ہے: ماخذ فائلیں ہیش کے ذریعے پن کی گئی ہیں، دونوں تصاویر ڈائجسٹ کے ذریعے، کوئی دوسرا کوڈ نہیں۔ |
| `tdx_identity` | تصدیق تعینات شدہ ایپلیکیشن اور مثال سے آتی ہے، جس میں Phala کے KMS کی چابیاں اور ایک خفیہ شدہ ڈسک شامل ہیں۔ |
| `tdx_os` | MRTD اور RTMR0-2 اُن اقدار کے برابر ہیں جو ویریفائر dstack OS امیج سے نکالتا ہے، جو Dstack-TEE شائع کرتا ہے، OS امیج ہیش کے ذریعے دریافت کی جاتی ہیں جو CVM رپورٹ کرتا ہے، اور ACPI ٹیبلز سے جو QEMU VM کی شکل کے لیے بناتا ہے: فرم ویئر، کرنل، initrd، کمانڈ لائن جس میں روٹ فائل سسٹم ہیش، میموری، vCPUs اور ڈیوائسز شامل ہیں۔ ایک ڈیولپمنٹ امیج ناکام ہو جاتا ہے۔ |

The OS image (about 180 MB, of which 21 MB are kept) is downloaded once from [Dstack-TEE/meta-dstack](https://github.com/Dstack-TEE/meta-dstack/releases) into `dstack-images` beside the record; `--tdx-image FOLDER` uses another folder or an unpacked image, `--tdx-image none` skips the comparison. The measurement follows `dstack-mr` and the `qemu-acpi` crate of Dstack-TEE/dstack. Private measurement regressions compare QEMU's own ACPI output and a retained Phala Cloud quote; live qualification also needs the published image. `--tdx-measurements` still compares MRTD and RTMR0-2 given as JSON instead.

جرنل میں ریکارڈ ہونے والا کلیکٹر کا ہر آغاز اس طرح کی تصدیق کے ساتھ ہوتا ہے، لہٰذا `verify --evidence` ہر آغاز اور اس کے بوٹ کردہ OS امیج کی جانچ کرتا ہے۔ Phala کی ایپلیکیشن کی ترامیم اور CVM کے آپریشنز بطور فراہم کنندہ لاگ کام کرتے ہیں: تعیناتی کے بعد تبدیل ہونے والی Docker Compose کنفیگریشن رپورٹ میں ناکام ہوتی ہے اور جائزے کے لیے دوبارہ آغاز کی فہرست دی جاتی ہے۔

پینل میں **Extras** → **Server 24/7** کے تحت **Confidential virtual machine · Phala Cloud** منتخب کریں اور Phala Cloud API کلید پیسٹ کریں؛ Quick Tunnel Hetzner کی طرح کام کرتا ہے۔ کمانڈ لائن سے:

```
python -m tgwitness.cloud deploy --provider phala --name case-1 --server-type tdx.small \
    --ref v0.8.0 --repository https://github.com/phishdestroy/TgWitness --quick-tunnel \
    --provider-token-file phala-key.txt
python -m tgwitness.cloud verify --record deployments/case-1/deployment.json \
    --provider-token-file phala-key.txt --cloud-init deployments/case-1/docker-compose.yaml \
    --source CHECKOUT_OF_COMMIT --fingerprint COLLECTOR_FINGERPRINT --report certificate.md
python -m tgwitness.cloud check-report --report certificate.pdf --verifier-fingerprint VERIFIER_KEY
```

`--tdx-collateral` Intel کے سرٹیفیکیٹس اور منسوخی کی فہرستیں Intel سے ڈاؤن لوڈ کرنے کے بجائے ایک فائل سے پڑھتا ہے۔ گیٹ وے DNS یہاں دستیاب نہیں ہے: Phala کے پاس آؤٹ گوئنگ ٹریفک کے لیے پرووائیڈر فائر وال نہیں ہے۔

### تصدیقی سرٹیفکیٹ

Phala کی تعیناتی کے لیے `verify --report certificate.md` بھی سرٹیفکیٹ لکھتا ہے: a خود کفیل `certificate.html` اور ایک A4 `certificate.pdf` جس میں فیصلہ، اعتماد کی زنجیر شامل ہوتی ہے جو Intel کے روٹ سے لے کر کلیکٹر کلید تک ہوتی ہے، عام اور اعلیٰ یقین دہانی والے سرورز کے ساتھ موازنہ، شائع شدہ امیج سے نکلی ہوئی اقدار کے ساتھ پیمائشوں کا موازنہ، ہر حصے کی ضمانت کون دیتا ہے، Intel کی سرٹیفیکیٹ چین، ہر چیک، فراہم کنندہ کا لاگ، اور توثیق کو دوبارہ کیسے دہرایا جائے۔ JSON رپورٹ مستند ریکارڈ کے طور پر رہتی ہے؛ صفحات اسے پیش کرتے ہیں۔

رپورٹ کو ڈیجیٹل طور پر دستخط اور ٹائم اسٹیمپ کے ساتھ `certificate.seal.json` اور اس کے ساتھ موجود `.tsq`/`.tsr` فائلوں میں مہر بند کیا گیا ہے:

| سیل | یہ جو شامل کرتا ہے |
| --- | --- |
| مستند الیکٹرانک ٹائم اسٹیمپ، `http://tsa.belgium.be/connect` | RFC 3161 ٹائم اسٹیمپ بلجیئم کی وفاقی حکومت کے کوالیفائیڈ ٹرسٹ سروس فراہم کنندہ (FPS پالیسی اور سپورٹ، BOSA) کے `certificate.json` کے عین بائٹس پر۔ اس کی اکائی کو بیلجیم کی EU قابلِ اعتماد فہرست میں ایک مستند ٹائم اسٹیمپنگ سروس کے طور پر درج کیا گیا ہے؛ اس کا درجہ منظور شدہ ہے؛ روٹ (Bелгиум روٹ CA6) اور اس فہرست کی اندراجات کو 20 اکتوبر 2026 کو جاری ہونے والی فہرست کے مطابق `tgwitness/tsa_roots.py` میں پن کیا گیا ہے۔ ریگولیشن (EU) نمبر 910/2014 کی شق 41 کے تحت، ایسی ٹائم اسٹیمپ کو ہر EU رکن ملک میں تاریخ و وقت اور ڈیٹا کی سالمیت کے اعتبار سے درست سمجھا جاتا ہے۔ |
| آر ایف سی 3161 ٹائم اسٹیمپ، فری ٹی ایس اے | ایک دوسرا، آزاد ٹائم اسٹیمپ |
| تصدیق کنندہ کا دستخط | ایک بیان کے اوپر Ed25519 جو رپورٹ کے SHA-256 اور ہر ٹائم اسٹیمپ کا نام لیتا ہے، ویریفائر کی اپنی کلید (`--sign-with FOLDER`، ڈیفالٹ `~/.tgwitness/verifier`) کے ساتھ؛ PDF اسی کلید کے ذریعے دستخط شدہ ہے |

`--timestamp URL` (دوبارہ قابلِ عمل) دوسرے حکام کو منتخب کرتا ہے، `--timestamp none` کوئی نہیں، `--sign-with
none` مہر کو بغیر دستخط کے چھوڑ دیتا ہے۔ `check-report` رپورٹ کے ہیش، تصدیق کنندہ کے دستخط، ہر ٹائم اسٹیمپ کو ایک قابلِ اعتماد روٹ اور اس کی مستند حیثیت سے، اور PDF کے دستخط کی جانچ کرتا ہے۔ EU کے باہر ایک مستند ٹائم اسٹیمپ، اور مجموعی طور پر رپورٹ کا قانونی وزن، اس عدالت یا اتھارٹی پر منحصر ہے جو اسے وصول کرتی ہے؛ سیل یہ ظاہر کرتا ہے کہ رپورٹ کب موجود تھی اور یہ کہ اس میں کوئی تبدیلی نہیں ہوئی۔

ایک تصدیق Intel کے TDX ماڈیول یا مائیکروکوڈ میں کسی خامی کو یا میموری بس تک جسمانی رسائی کو خارج نہیں کر سکتی۔ جو بھی Phala کے اکاؤنٹ میں ایپلیکیشن کو کنٹرول کرتا ہے وہ ایک اور کمپوز تعینات کر سکتا ہے؛ یہ ایک نئے کمپوز ہیش کے ساتھ ایک نئی نظر ثانی کے طور پر ظاہر ہوتا ہے۔ ہوسٹ مشین کے وقت کے ماخذ اور نیٹ ورک کو کنٹرول کرتا ہے۔

ڈپلائے، `--evidence` کے ساتھ تصدیق کریں، ری اسٹارٹس، OS امیج کا موازنہ، ڈیجیٹلی مہر بند دستخط اور ٹائم اسٹیمپ والا سرٹیفیکیٹ اور ڈسٹرائی Phala Cloud پر خود چل چکے ہیں؛ دیکھیں [، 4 نومبر 2026 کا رن](https://phishdestroy.github.io/TgWitness/ur/docs/reference/verification/#live-phala-cloud-deployment--4-november-2026)۔

## شروع کرنے سے پہلے

1. ایک Cloudflare زون، اس کا اکاؤنٹ آئی ڈی، اور ایک API ٹوکن جس میں **Cloudflare Tunnel Edit**، **Zone Read** اور **DNS Edit** شامل ہیں، دیا گیا `--cloudflare-token-file` یا `CLOUDFLARE_API_TOKEN`تصدیق کنندہ کے لیے: **Cloudflare Tunnel Read**، **DNS Read** اور آڈٹ لاگ کے لیے **اکاؤنٹ سیٹنگز ریڈ**۔ ڈومین کے بغیر، ایک [فوری ٹنل](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#quick-tunnel-without-a-domain) کو ان میں سے کسی کی بھی ضرورت نہیں ہوتی۔
2. فراہم کنندہ کی اسناد جن کے پاس ایک مخصوص پروجیکٹ میں لکھنے کی اجازت ہو؛ `lock` استعمال کرتا ہے:

   - Hetzner: API ٹوکن جس میں پڑھنے اور لکھنے کی اجازت ہو؛
   - DigitalOcean: لکھنے کی اجازت والا ذاتی رسائی ٹوکن؛
   - Linode: ذاتی رسائی ٹوکن کے ساتھ `linodes`, `firewall` اور `events` ریڈ/رائٹ اسکوپس کے ساتھ؛
   - Vultr: وقف کردہ اکاؤنٹ یا ذیلی اکاؤنٹ کی API کلید؛
   - AWS: IAM کریڈینشلز کی اجازت دی گئی `ec2:DescribeVpcs`, `ec2:DescribeImages`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:RunInstances`, `ec2:CreateTags`, `ec2:DescribeInstances`, `ec2:DescribeSecurityGroupRules` اور `ec2:RevokeSecurityGroupIngress`.
3. چلانے کے لیے کمٹ۔ ریلیز ٹیگ ایک مرتبہ اپنے کمٹ کے ساتھ حل ہوتا ہے `git ls-remote`; سرور کو صرف 40-حرفوں والا کمٹ موصول ہوتا ہے۔

## پینل سے

اپنے کمپیوٹر پر، **Extras → Server 24/7** ایک ہی `deploy` ہٹزنر کے لیے تین مراحل میں: یورپ یا ریاستہائے متحدہ کا انتخاب کریں، ایک ہٹزنر ٹوکن (ریڈ اینڈ رائٹ) پیسٹ کریں، پھر سرور کی قسم، ماہانہ قیمت، پتہ اور وہ ورژن جائزہ لیں جو پینل نے اس ٹوکن کے ساتھ پایا۔ آپ کی تصدیق سے پہلے کچھ بھی نہیں بنایا جاتا۔ پینل ہر مرحلے کو اس طرح دکھاتا ہے `deploy` رپورٹ کرتا ہے، پھر ایڈریس، پینل ٹوکن اور سگننگ کی فنگر پرنٹ۔ ڈومین کے بغیر سرور کو ایک [فوری ٹنل](https://phishdestroy.github.io/TgWitness/ur/docs/reference/high-assurance/#quick-tunnel-without-a-domain) مل جاتا ہے؛ **آپ کے سرورز → موجودہ ایڈریس تلاش کریں** دوبارہ شروع کرنے کے بعد دوبارہ تلاش کرتا ہے۔ اپنے ڈومین کے تحت ایک مستقل ایڈریس کے لیے، **اختیاری · اپنا ڈومین** کھولیں اور ایک Cloudflare ٹوکن شامل کریں (تیار شدہ لنک زون ریڈ، DNS ایڈیٹ اور Cloudflare ٹنل ایڈیٹ کا انتخاب کرتا ہے)۔

ٹوکن براؤزر ٹیب سے TgWitness تک ہر درخواست کے ساتھ اسی کمپیوٹر پر سفر کرتے ہیں اور کہیں بھی لکھے نہیں جاتے؛ تعیناتی ریکارڈ، ترمیم شدہ cloud-init، پینل ٹوکن اور، تیز ٹنل کے لیے، ایڈریس کی کو میں محفوظ رکھا جاتا ہے `deployments/NAME` ڈیٹا ڈائریکٹری کے اندر۔ پینل یہ سہولت صرف مرکزی منتظم کو براہِ راست لوپ بیک کنکشن پر فراہم کرتا ہے (`127.0.0.1`، کوئی پروکسی یا ٹنل ہیڈرز نہیں)؛ نیٹ ورک کے ذریعے پہنچا گیا پینل اس کی بجائے کمانڈز دکھاتا ہے۔ ورژن خود بخود چلنے والے پینل کے ریلیز ٹیگ پر سیٹ ہوتا ہے، جسے GitHub API کے ذریعے حل کیا جاتا ہے۔ مقام، سرور کی قسم اور قیمت Hetzner کی API سے آتی ہیں: `cpx22` جہاں یہ پیش کیا جاتا ہے، ورنہ کم از کم 2 GB میموری کے ساتھ سب سے سستا x86 قسم۔

## ڈومین کے بغیر فوری ٹنل

`--quick-tunnel` متبادل `--zone`, `--cloudflare-account` اور `--panel-host`؛ کوئی Cloudflare اکاؤنٹ یا ٹوکن شامل نہیں ہے:

```
python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --quick-tunnel --provider-token-file hetzner.token
```

سرور پر، cloudflared پینل کے لیے ایک [تیز سرنگ](https://developers.cloudflare.com/tunnel/get-started/quick-tunnels/) کھولتا ہے: ایک بے ترتیب `https://….trycloudflare.com` ایک پتے کو تبدیل کرتا ہے جب بھی cloudflared یا سرور دوبارہ شروع ہوتا ہے۔ سرور پر ایک چھوٹی سی سروس ہر پتے کو ایک بے ترتیب ntfy.sh موضوع پر پوسٹ کرتی ہے، جس پر دستخط (HMAC-SHA256) ایک ایسی کلید سے کیے گئے ہیں جو صرف تعیناتی ڈائریکٹری میں موجود ہے (`address-key.txt`)، اور اسے ہر تین گھنٹے بعد دہراتا ہے کیونکہ ntfy.sh پوسٹس کو 12 کے لیے محفوظ رکھتا ہے۔ `deploy` اور **موجودہ پتا تلاش کریں** صرف دستخط شدہ پوسٹس قبول کرتے ہیں، اس لیے کوئی جعلی پوسٹ آپ کو، اور آپ کے پینل ٹوکن کو، کسی اور کے پتے پر نہیں بھیج سکتی۔ موضوع ریکارڈ میں موجود ہے اور شائع شدہ cloud-init میں بھی: جس کے پاس یہ ہوں وہ موجودہ پتہ پڑھ سکتا ہے، جو اب بھی پینل ٹوکن مانگتا ہے۔ سرور کسی بھی صورت میں کوئی ان باؤنڈ پورٹ استعمال نہیں کرتا۔

ایک ویریفائر کے پاس ایڈریس کی نہیں ہوتی، اور کوئی بھی شخص جو موضوع پڑھتا ہے وہ اس میں پوسٹ کر سکتا ہے۔ لہٰذا کلیکٹر بھی خود ایڈریس پوسٹ کرتا ہے، جو اس کی اپنی Ed25519 کی کے ساتھ دستخط شدہ ہوتی ہے، اور `verify` تعیناتی ریکارڈ میں کلیکٹر کی کے ساتھ دستخط شدہ تازہ ترین پوسٹ کو لیتا ہے؛ پوسٹس کو اس وقت کے مطابق ترتیب دیا جاتا ہے جب ntfy.sh نے انہیں موصول کیا، نہ کہ اس وقت کے مطابق جو وہ دعویٰ کرتی ہیں۔ اس تبدیلی سے پہلے کا ایک کلیکٹر کچھ بھی سائن نہیں کرتا، اور پھر `verify` تازہ ترین پوسٹ کو لے لیتا ہے اور `statement` چیک میں ایسا ہی بتاتا ہے؛ ایک جعلی پوسٹ صرف اس چیک کو ناکام کر سکتی ہے، کیونکہ ایڈریس کو اب بھی کلیکٹر کی کلید کے ساتھ جواب دینا چاہیے۔

اس کی لاگت: کوئی Cloudflare اکاؤنٹ ایک فوری ٹنل کے ریکارڈز محفوظ نہیں رکھتا، لہٰذا `verify` ٹنل، کنیکٹر اور DNS چیک کو غیر دستیاب رپورٹ کرتا ہے اور نتیجہ بہترین صورت میں `incomplete` ہوتا ہے (Phala پر چیک کے بجائے کلاؤڈ پاس ہو جاتا ہے: کنیکٹر ماپے گئے ڈاکر کمپوز کنفیگریشن کے اندر چلتا ہے)؛ فراہم کنندہ کے ریکارڈز، فائر وال، دستخط شدہ بیان، ہوسٹ کی پیمائش اور انسٹالر کا موازنہ معمول کے مطابق چیک کیے جاتے ہیں۔ ریفرنس انسٹالر کے ساتھ بائٹ کا موازنہ ایک تعینات کردہ کمٹ کی ضرورت ہے جو پہلے سے `--quick-tunnel` کو جانتا ہو؛ ایک 0.7.0 چیک آؤٹ ڈومین انسٹالر بناتا ہے اور فرق کی رپورٹ کرتا ہے۔ Cloudflare فوری ٹنلز فراہم کرتا ہے جن کی اپ ٹائم کی کوئی گارنٹی نہیں ہوتی، ایک وقت میں 200 درخواستوں کی اجازت دیتا ہے اور سرور سے بھیجی جانے والی ایونٹس (Server-Sent Events) کو منتقل نہیں کرتا، لہٰذا پینل کی لائیو اپ ڈیٹس (0.7.0 کے بعد کے ورژن) ممکنہ طور پر ایک کے ذریعے نہیں پہنچیں گی اور ویو کو دوبارہ لوڈ کرنے کی ضرورت ہوگی؛ اس حصے کو آزمایا نہیں گیا ہے۔ ایک ایسے کیس کے لیے جو برقرار رہنا ہو، اپنا ڈومین استعمال کریں۔

## تینشر کریں

سب سے پہلے وہ سب کچھ دیکھیں جو بھیجا جائے گا۔ `plan` کوئی فراہم کنندہ یا Cloudflare درخواست نہیں کرتا:

```
python -m tgwitness.cloud plan --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org
```

پھر انہی اختیارات اور اسناد کے ساتھ تعینات کریں:

```
python -m tgwitness.cloud deploy --provider hetzner --name case-2026-11 --server-type cpx22 \
    --ref 0123456789abcdef0123456789abcdef01234567 --zone example.org \
    --cloudflare-account CLOUDFLARE_ACCOUNT_ID --panel-host case.example.org \
    --witness-host case-witness.example.org \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token
```

شروع کرنے کے لیے سرور کی اقسام: `cpx22` (Hetzner)، `s-1vcpu-2gb` (DigitalOcean), `g6-standard-1` (Linode), `vc2-1c-2gb` (Vultr)، `t3.small` (AWS). `--location` اور `--image` ہر فراہم کنندہ کے یورپی خطے میں Ubuntu 24.04 کو بطورِ ڈیفالٹ۔

`--repository` یہ دوسری https Git ریپوزیٹری سے کمٹ لیتا ہے، URL میں کریڈینشلز کے بغیر (ڈیفالٹ `https://github.com/phishdestroy/TgWitness.git`). `deploy` بھی قبول کرتا ہے `--out` کسی دوسری ڈیپلائمنٹ ڈائریکٹری کے لیے (ڈیفالٹ `deployments/NAME`؛ ایک ایسی ڈائریکٹری جس میں پہلے ہی ایک تعیناتی موجود ہے اسے مسترد کر دیا جاتا ہے) اور `--wait`، کلیکٹر کے دستخط شدہ بیان کے انتظار کے منٹ: 1 سے 240، ڈیفالٹ 20، یا 60 کے لیے `generic`.

کمانڈ:

1. ایک Cloudflare سرنگ بناتا ہے جس کا داخلہ پینل ہوسٹ نیم کو پینل تک آگے بھیجتا ہے اور، اگر دیا گیا ہو تو، گواہ ہوسٹ نیم کو `/api/witness/head` اور `/api/assurance` صرف؛
2. وہ ان ہوسٹ نیموں کے لیے پروکسی شدہ CNAME ریکارڈز بناتا ہے، اور پہلے سے موجود ناموں کو مسترد کر دیتا ہے؛
3. ایک پرووائیڈر فائر وال بناتا ہے جس میں ان باؤنڈ قواعد نہیں ہوتے اور اس کے پیچھے ایک سرور بغیر SSH کلید، بغیر بیک اپ، بغیر کنسول ایجنٹ، اور cloud-init کے ساتھ جو SSH کو چھپاتا ہے، روٹ کو لاک کرتا ہے، انسٹال کرتا ہے `cloudflared`، بالکل صحیح کمٹ حاصل کرتا ہے، اسے چیک کرتا ہے اور TgWitness کو ایک مضبوط شدہ systemd سروس کے طور پر شروع کرتا ہے؛
4. کلیکٹر کے دستخط شدہ بیان کا انتظار کرتا ہے اور چیک کرتا ہے کہ آیا اس میں اس سرور اور اس cloud-init کے ہیش کا ذکر ہے۔

`deployments/case-2026-11/` پھر شامل کرتا ہے:

| فائل | فہرست | شیئر کریں؟ |
| --- | --- | --- |
| `deployment.json` | آئی ڈیز، ہیشز، کی گئی API کالز (میتھڈ، پاتھ، اسٹیٹس) اور پہلا دستخط شدہ بیان | جی ہاں، ویریفائر کے ساتھ |
| `cloud-init.redacted.yaml` | اصلی cloud-init جس کے دو سیکرٹس کو تبدیل کر کے `REDACTED` | جی ہاں |
| `panel-token.txt` | پینل ٹوکن | نہیں |

پراویڈر کا روٹ پاس ورڈ، ٹنل ٹوکن اور پینل ٹوکن کبھی بھی لکھے نہیں جاتے `deployment.json`۔ آخر میں درج کلیکٹر فنگر پرنٹ کو صرف ایک ایسے چینل کے ذریعے شائع کریں جس پر آپ اکیلے قابو نہ رکھتے ہوں، مثال کے طور پر ایک وِٹنس چینل یا وصول کنندہ کو پیغام کے ذریعے۔

Telegram میں سائن ان کریں `https://case.example.org` پینل ٹوکن کے ساتھ ٹیلیگرام میں سائن ان کریں، جیسا کہ [اکاؤنٹ گائیڈ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/accounts/) میں ہے۔ پینل ایکشنز دستخط شدہ جرنل میں ریکارڈ کیے جاتے ہیں؛ یہ SSH سیشنز نہیں ہیں۔ ایک [گواہ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/witness/) پول کر سکتا ہے `https://case-witness.example.org`.

کوئی SSH نہیں ہے: اگر بوٹ اسٹریپ ناکام ہو جائے تو کلیکٹر کبھی جواب نہیں دیتا۔ سرور کو حذف کریں اور دوبارہ تعینات کریں، یا وجہ معلوم کرنے کے لیے ڈیبگ تعیناتی استعمال کریں۔

### صارف کے ڈیٹا میں راز

کلاؤڈ-اِنِٹ دو راز رکھتا ہے: پینل ٹوکن اور کلاؤڈفلئیر ٹنل ٹوکن۔ دستخطی کلید ان میں شامل نہیں ہے؛ یہ سرور پر بنائی جاتی ہے۔ Hetzner، DigitalOcean اور Linode اپنی API کے ذریعے صارف کا ڈیٹا واپس نہیں کرتے۔ Vultr اسے کسی بھی کلید کو واپس کرتا ہے جو انسٹنس کو پڑھ سکتی ہے، اور EC2 کے ذریعے `DescribeInstanceAttribute`. AWS کے لیے صرف تین ایکشنز دیں جو ٹیبل میں ہیں، کبھی `ec2:Describe*`. Vultr کے لیے فرض کریں کہ ویریفائر کی کلید دونوں ٹوکنز پڑھ سکتی ہے۔ ایک ٹنل ٹوکن کسی کو دوسرا کنیکٹر چلانے کی اجازت دیتا ہے: `verify` سرور پر موجود نہ ہونے والے کسی بھی کنیکٹر کی رپورٹ کرتا ہے، اور کلیکٹر کے بیانات اس طرح جعلسازی نہیں کیے جا سکتے کیونکہ ہر ایک ایک تازہ چیلنج پر دستخط کرتا ہے۔ کے ساتھ `--quick-tunnel` دوسرا راز اس کی بجائے ایڈریس کی ہوتا ہے: جو بھی اسے پڑھتا ہے وہ ایک جعلی پتہ پوسٹ کر سکتا ہے جسے پینل قبول کر لے گا۔

جمع کرنے والے کا عوامی بیان سرور کے پتے اور لاگ ان کے ذرائع کو شامل نہیں کرتا؛ دونوں دستخط شدہ جرنل میں موجود رہتے ہیں۔

## ڈیباگ تعیناتی اور لاک

`--debug-ssh-key KEY --debug-ssh-from 198.51.100.4` ایک ایڈریس یا چھوٹے نیٹ ورک سے ایک کلید کے لیے SSH کو محفوظ رکھتا ہے، زیادہ سے زیادہ IPv4 کے لیے /24 یا IPv6 کے لیے /48۔ `KEY` پہلے ہی فراہم کنندہ کے ساتھ رجسٹرڈ ہے: Hetzner پروجیکٹ میں SSH کلید کا نام یا شناختی نمبر، DigitalOcean ٹیم میں SSH کلید کی شناختی نمبر یا فنگر پرنٹ، ایک Linode صارف نام جس کی پروفائل SSH کلیدیں روٹ میں شامل کی جاتی ہیں، Vultr اکاؤنٹ میں SSH کلید کی شناختی نمبر، یا خطے میں EC2 کلید کے جوڑے کا نام۔ یہ اختیارات پر لاگو نہیں ہوتے `generic`۔ ایسی تعیناتی کو بطور درج کیا جاتا ہے `debug` اور اسے **کبھی بھی** ہائی-ایشورنس کے طور پر رپورٹ نہیں کیا جاتا۔ جب آپ ختم کر لیں، تو چلائیں `sudo tgwitness-lock` آخری SSH سیشن کے آخری کمانڈ کے طور پر چلائیں، پھر:

```
python -m tgwitness.cloud lock --record deployments/case-2026-11/deployment.json --provider-token-file hetzner.token
```

فائر وال ہر ان باؤنڈ قاعدہ کھو دیتا ہے۔ رپورٹس پھر دکھاتی ہیں کہ SSH کب اجازت دی گئی اور کب اسے بند کیا گیا؛ وہ ونڈو دکھائی دیتی رہتی ہے۔

## ایک تعیناتی ہٹائیں

`destroy` سرور اور اس کے فائر وال کو حذف کر دیتا ہے، جو تعیناتی کے لیبل سے پایا جاتا ہے تاکہ ایک تعیناتی جو آدھے راستے میں ناکام ہوئی ہو بھی ہٹا دی جائے، پھر وہ DNS ریکارڈز جو اس کی سرنگ کی طرف اشارہ کرتے ہیں، اور سرنگ۔ سرور کا جرنل اور دستخطی کلید اس کے ساتھ حذف کر دیے جاتے ہیں: ثبوت کو پہلے برآمد کریں۔ ریکارڈ برقرار رہتا ہے، نشان زد `removed`، ہٹانے کے API کالز کے ساتھ۔

```
python -m tgwitness.cloud destroy --record deployments/case-2026-11/deployment.json --confirm case-2026-11 \
    --provider-token-file hetzner.token --cloudflare-token-file cloudflare.token
```

Hetzner کے لیے API کے ذریعے ہٹانے کا عمل نافذ کیا گیا ہے۔ دوسرے فراہم کنندگان کے لیے `destroy` کچھ بھی حذف کرنے سے پہلے رک جاتا ہے اور فراہم کنندہ کے کنسول میں حذف کیے جانے والے لیبل کا نام بتاتا ہے۔ ایک ہاتھ سے انسٹال کردہ سرور (`generic`) صرف اپنے ٹنل اور DNS ریکارڈز کھو دیتا ہے۔ ایک فوری ٹنل تعیناتی کو Cloudflare ٹوکن کی ضرورت نہیں ہوتی: اس کا ٹنل سرور کے ساتھ ختم ہوتا ہے، اور اس کی پوسٹس ntfy.sh سے 12 گھنٹوں کے اندر ختم ہو جاتی ہیں۔

## کوئی بھی سرور (خود تصدیق شدہ)

`--provider generic` اس کا استعمال ایسے سرور کے لیے ہوتا ہے جو خریدا گیا ہو یا دستی طور پر انسٹال کیا گیا ہو۔ `deploy` سرنگ اور DNS بناتا ہے، لکھتا ہے `install.sh` (نجی) اور `install.redacted.sh` (شائع کرنے کے لیے)، اور انتظار کرتا ہے۔ کاپی کریں `install.sh` کو تازہ انسٹال شدہ Ubuntu 24.04 سرور پر کاپی کریں اور اسے وہاں چلائیں:

```
sudo bash install.sh
```

یہ ہوسٹ کو جیسا تھا ویسا ریکارڈ کرتا ہے (لاگ انز، اکاؤنٹس، `authorized_keys`، لسننگ ساکٹس، سروسز، شیڈولڈ جابز، پیکجز)، کمٹ انسٹال کرتا ہے، ہوسٹ فائر وال کو فعال کرتا ہے، خود کو حذف کر دیتا ہے، SSH کو چھپا دیتا ہے اور سیشن ختم کر دیتا ہے۔ ایسے سرور کے لیے رپورٹ زیادہ سے زیادہ **خود تصدیق شدہ (SELF-ATTESTED)** ہوتی ہے: جس نے بھی انسٹالر چلایا تھا اسے پہلے سے روٹ رسائی حاصل تھی، اور تصدیق کرنے والے کے لیے کوئی فراہم کنندہ ریکارڈ دستیاب نہیں ہوتا۔ یہ پھر بھی ایک غیر واضح سرور سے بہتر ہے: انوینٹری، انسٹالر ہیش اور ہر بعد کی لاگ ان پر دستخط کیے جاتے ہیں۔

## تصدیق کریں

تصدیق کنندہ کو درکار ہے `deployment.json`، شائع شدہ انسٹالر، صرف پڑھنے کے لیے شناختی دستاویزات اور، مثالی طور پر، کمٹ کا ایک چیک آؤٹ اور ایک ثبوت ZIP:

```
git clone -c core.autocrlf=false https://github.com/phishdestroy/TgWitness.git checkout
git -C checkout checkout 0123456789abcdef0123456789abcdef01234567
python -m tgwitness.cloud verify --record deployment.json \
    --provider-token-file read-only.token --cloudflare-token-file cloudflare-read.token \
    --fingerprint COLLECTOR_FINGERPRINT --cloud-init cloud-init.redacted.yaml \
    --source checkout --evidence tgwitness-evidence.zip --report report.md
```

ہر فراہم کنندہ اور Cloudflare کی قدر اسی وقت تصدیق کنندہ کی طرف سے طلب کی جاتی ہے؛ ریکارڈ صرف ان آئی ڈیز کی فراہمی کرتا ہے جن کے بارے میں پوچھا جانا ہے۔ نکلنے کا کوڈ **PASS** کے لیے 0، **FAIL** کے لیے 1 اور **REVIEW**، **INCOMPLETE** یا **SELF-ATTESTED** کے لیے 2 ہوتا ہے۔ `--fingerprint` ایک آزاد چینل سے آنا چاہیے؛ اس کے بغیر کلید کا موازنہ صرف آپریٹر کے ریکارڈ سے کیا جاتا ہے۔ `python verify.py` ابھی بھی ثبوت کو خودZIP کے ذریعے تصدیق کرتا ہے، جیسا کہ [ثبوت](https://phishdestroy.github.io/TgWitness/ur/docs/reference/evidence/) میں ہے۔

پرووائیڈر ایکشنز درجہ بندی کے تحت آتے ہیں: تخلیق اور تخلیق کے 30 منٹ کے اندر آغاز پاس؛ کنسول، ریسکیو، پاس ورڈ ری سیٹ، ری بلڈ، ISO، تصاویر، اسنیپ شاٹس، بیک اپس، سسٹمز مینیجر، EC2 انسٹنس کنیکٹ اور فائر وال کی کھلنے کی کارروائیاں ناکام؛ پاور ایکشنز اور غیر متوقع کوئی بھی چیز جائزے کے لیے نشان زد کی جاتی ہے۔ ایک نامعلوم ایکشن کبھی بھی خاموشی سے منظور نہیں ہوتا۔

## شواہد کے حوالگی کے لیے رپورٹ

`--report report.md` مارک ڈاؤن رپورٹ لکھتا ہے اور `report.json` اس کے ساتھ:

1. نتیجہ، کلیکٹر کی فنگر پرنٹ، تعیناتی، فراہم کنندہ، کمٹ، سرور، فائر وال، سرنگ؛
2. ہر چیک اس کی حیثیت اور ماخذ کے ساتھ (پرووائیڈر API، کلاؤڈ فلئیر API، کلیکٹر اسٹیٹمنٹ، ثبوت جرنل)؛
3. فراہم کنندہ کا لاگ جس میں ہر ایکشن کا جائزہ شامل ہوتا ہے اور جہاں فراہم کنندہ اسے ریکارڈ کرتا ہے، وہاں ایکٹر بھی شامل ہوتا ہے؛
4. کلوڈفلئیر کے وہ اینڈ پوائنٹس جو سرنگ کے کنکشنز، تشکیلات اور آڈٹ لاگ کو محفوظ رکھتے ہیں؛
5. دستخط شدہ کلیکٹر بیان؛
6. رپورٹ کیا ثابت کرتی ہے اور کیا ثابت نہیں کرتی؛
7. اسے دوبارہ پیدا کرنے کے لیے کمانڈز، اور ہر فائل کے لیے دی گئی تمامSHA-256 تصاویر۔

رپورٹ حوالے کریں، `report.json`, `deployment.json`، شائع شدہ انسٹالر اور شواہد ZIP۔ رپورٹ جلد فراہم کریں: فراہم کنندہ کے لاگز محدود مدت کے لیے محفوظ رکھے جاتے ہیں۔

## بہ طور بیرونی گواہ کلاؤڈ فلئیر

یہاں سب کچھ اختیاری ہے۔ Cloudflare اکاؤنٹ کے بغیر بھی سرور چلتا رہتا ہے، اور ان میں سے دو آج کام کر رہے ہیں:

| کیا | یہ کیا دکھاتا ہے | TgWitness میں |
| --- | --- | --- |
| تیزی سے ٹنل یا آپ کے ڈومین کا ٹنل | پینل صرف سرنگ کے ذریعے ہی پہنچا جا سکتا ہے۔ | سرور وِزارڈ، اوپر دیکھیں |
| ڈراںڈ ریلے `drand.cloudflare.com` | ڈرانڈ راؤنڈ کے بعد کے ریکارڈز اس سے زیادہ نئے ہیں: جرنل جیسے جیسے لکھا گیا ویسا ہی محفوظ کیا گیا۔ | شواہد موڈ، **مزید گواہ**، کوئی اکاؤنٹ ([فارمیٹ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/evidence/#optional-records-in-evidence-mode-drand-and-telegram-devices)) |
| سرنگ کی صحت کے نوٹیفیکیشن | جب ٹنل بند ہو، تو ای میل یا Cloudflare کے ویب ہُک کے ذریعے | انہیں Cloudflare ڈیش بورڈ میں سیٹ کریں |
| گیٹ وے DNS (`--gateway-dns`، یا وزرڈ میں **Cloudflare Gateway DNS**) | ہر نام جسے سرور نے تلاش کیا، TLS کے ذریعے Cloudflare نے جواب دیا؛ Hetzner کا فائر وال DNS کو کسی اور چیز تک رسائی نہیں دیتا؛ آیا کوئی گیٹ وے پالیسی جوابات کو دوبارہ لکھ سکتی ہے | Hetzner، مفت Zero Trust پلان، کوئی ڈومین نہیں؛ `verify` فائر وال، مقام، لاگنگ، پالیسیاں، سرور کے سوالات اور آڈٹ لاگ چیک کرتا ہے؛ ثبوت موڈ لاگ کو جرنل میں کاپی کرتا ہے |
| سرور پر Cloudflare One کلائنٹ کے ساتھ گیٹ وے، ایک آؤٹ باؤنڈ فائر وال جو صرف Cloudflare کی اجازت دیتا ہے۔ | سرور کے ہر کنکشن کو ریکارڈ کیا جاتا ہے، صرف DNS ہی نہیں۔ | ابھی تیار نہیں ہوا |
| پینل کے سامنے رسائی | پینل میں کس نے اور کب سائن ان کیا | تیار نہیں: اپنے ڈومین کی ضرورت ہے |
| SSH کمانڈ لاگنگ | ڈیبگ سیشن میں ہر کمانڈ | ابھی تیار نہیں ہوا |

Logpush، جو Cloudflare کی اپنی کاپی R2 میں محفوظ رکھتا ہے، ایک انٹرپرائز فیچر ہے: مفت پلان پر Cloudflare جواب دیتا ہے `logpush is not enabled for this account`اس کا گیٹ وے لاگ وہاں 24 گھنٹے رہتا ہے، لہٰذا ایویڈنس موڈ اسے سائن شدہ جرنل میں کاپی کر لیتا ہے (**Cloudflare گیٹ وے کا اس سرور کی DNS کوئریز کا لاگ**، ایک ریڈ-اونلی ٹوکن جس کے ساتھ اکاؤنٹ اینالیٹکس ریڈ ہے)۔

زیرو ٹرسٹ پلان کے بغیر ایک اکاؤنٹ کا ایک DNS مقام ہوتا ہے۔ جب Cloudflare کسی اور کو مسترد کرتا ہے، سرور موجودہ مقام کو شیئر کرتا ہے اور اس کی کوئریاں اس کے پتے کی بنیاد پر الگ کی جاتی ہیں؛ اس فلٹر کے لیے بھی Zero Trust PII Read درکار ہے، اور `destroy` ایک مشترکہ مقام چھوڑ دیتا ہے۔ ایک لاگ کوئری زیادہ سے زیادہ تین گھنٹے محیط ہوتی ہے، لہٰذا کاپی اور `verify` دن کو تین تین گھنٹے کے وقفوں میں پڑھتی ہے۔

گیٹ وے DNS سسٹم ریزولور کا احاطہ کرتا ہے۔ پورٹ 443 پر HTTPS کے ذریعے کسی دوسرے ریزولور کو DNS، اور ایسی ایڈریس سے کنکشنز جو کہیں بھی تلاش نہیں ہوتے (مثلاً ٹیلیگرام کے ڈیٹا سینٹرز)، اس کے لاگ میں شامل نہیں ہوتے۔

Cloudflare ٹیلیگرام کی انکرپشن کے اندر نہیں دیکھ سکتا، ٹیلیگرام اکاؤنٹ پر موجود دیگر آلات (evidence mode کی ڈیوائس لسٹ انہیں ٹیلیگرام کی جانب سے ریکارڈ کرتی ہے) یا فراہم کنندہ کے ہائپروائزر کو بھی نہیں۔

## تینخانے کے نتیجے کی پڑھائی

ایک عام VM کے لیے، فراہم کنندہ ہوسٹ انفراسٹرکچر اور مقامی انوینٹری کو کنٹرول کرتا ہے، اور اسے فراہم کنندہ کے ریکارڈز کے ساتھ چیک کیا جاتا ہے۔ Intel TDX کے لیے، تصدیق کنندہ اضافی طور پر ہارڈویئر کوٹ، کلیکٹر بائنڈنگ، کمپوز اور OS کی پیمائشوں کو چیک کرتا ہے۔ یہ دیکھنے کے لیے انفرادی نتائج پڑھیں کہ کون سی چیک پاس ہوئیں یا دستیاب نہیں تھیں۔

تاریخی فائر وال کی تفصیل فراہم کنندہ پر منحصر ہے؛ Linode قواعد کے ورژنز کو برقرار رکھتا ہے۔ [تصدیقی ریکارڈ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/verification/) میں آزمائش شدہ تعیناتیوں اور باقی ماندہ لائیو چیکس کی فہرست ہوتی ہے، اور [تصدیقی دائرہ کار](https://phishdestroy.github.io/TgWitness/ur/docs/reference/evidence/#verification-scope) ان ماحولیاتی چیکس کو آرکائیو حصول اور سالمیت سے جوڑتا ہے۔