# Phala / Intel TDX · उच्च-आश्वासन परिनियोजन

Canonical page: https://phishdestroy.github.io/TgWitness/hi/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/hi/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/hi/docs/reference/deployment/)

![तैनाती और पुनर्प्राप्ति](https://phishdestroy.github.io/TgWitness/assets/chapter-operate.svg)

उच्च-आश्वासन परिनियोजन संग्रह वातावरण के स्वतंत्र सत्यापन को अभिलेखागार सत्यापन में जोड़ता है। समीक्षक क्लाउड प्रदाता और Cloudflare के पास रखे गए परिनियोजन और पहुँच रिकॉर्ड की पूछताछ करता है, और एक Intel TDX परिनियोजन संग्रहकर्ता के वातावरण की हार्डवेयर प्रमाणीकरण जोड़ता है।

साधारण स्थानीय और Docker उपयोग अपरिवर्तित है। यहाँ कुछ भी तब तक नहीं चलता जब तक आप के साथ डिप्लॉय नहीं करते। `python -m tgwitness.cloud`, और कलेक्टर अपने होस्ट को केवल तब पढ़ता है जब डिप्लॉयमेंट सेट करता है `TGWITNESS_ASSURANCE`.

प्रवाह आरेख · ऑपरेटर → सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल (प्रदाता एपीआई); ऑपरेटर → टनल और DNS (क्लाउडफ्लेयर एपीआई); सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल → टनल और DNS (केवल आउटबाउंड); सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल → सर्वर पर बनाई गई हस्ताक्षर कुंजी; प्रमाणीकरणकर्ता, केवल-पठन टोकन → प्रदाता लॉग और फ़ायरवॉल; प्रमाणीकरणकर्ता, केवल-पठन टोकन → टनल कनेक्टर का पता और प्रवेश; प्रमाणीकरणकर्ता, केवल-पठन टोकन → हस्ताक्षरित /api/assurance statement; प्रमाणीकरणकर्ता, केवल-पठन टोकन → साक्ष्य ज़िप · ऑपरेटर · प्रमाणीकरणकर्ता, केवल-पठनटोकन · सर्वर, बिना इनबाउंड नियमोंवाला फ़ायरवॉल · प्रदाता लॉग और फ़ायरवॉल · टनल कनेक्टर का पता औरप्रवेश · हस्ताक्षरित /api/assurancestatement · साक्ष्य ज़िप · टनल और DNS · सर्वर पर बनाई गई हस्ताक्षरकुंजी · प्रदाता एपीआई · क्लाउडफ्लेयर एपीआई · केवल आउटबाउंड

**चित्र को पाठ के रूप में**

1. ऑपरेटर → सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल (प्रदाता एपीआई)
2. ऑपरेटर → टनल और DNS (क्लाउडफ्लेयर एपीआई)
3. सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल → टनल और DNS (केवल आउटबाउंड)
4. सर्वर, बिना इनबाउंड नियमों वाला फ़ायरवॉल → सर्वर पर बनाई गई हस्ताक्षर कुंजी
5. प्रमाणीकरणकर्ता, केवल-पठन टोकन → प्रदाता लॉग और फ़ायरवॉल
6. प्रमाणीकरणकर्ता, केवल-पठन टोकन → टनल कनेक्टर का पता और प्रवेश
7. प्रमाणीकरणकर्ता, केवल-पठन टोकन → हस्ताक्षरित /api/assurance statement
8. प्रमाणीकरणकर्ता, केवल-पठन टोकन → साक्ष्य ज़िप

**इस पृष्ठ पर**

- [एक सत्यापक क्या जाँच सकता है](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#what-a-verifier-can-check)
- [प्रदायक](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#providers)
- [फला क्लाउड पर गोपनीय वीएम (इंटेल टीडीएक्स)](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#confidential-vm-on-phala-cloud-intel-tdx)
- [शुरू करने से पहले](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#before-you-start)
- [पैनल से](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#from-the-panel)
- [डोमेन के बिना त्वरित सुरंग](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#quick-tunnel-without-a-domain)
- [तैनात करें](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#deploy)
- [डिबग डिप्लॉयमेंट और लॉक](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#debug-deployment-and-lock)
- [एक डिप्लॉयमेंट हटाएँ](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#remove-a-deployment)
- [कोई भी सर्वर (स्व-प्रमाणित)](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#any-server-self-attested)
- [सत्यापित करें](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#verify)
- [साक्ष्य हस्तांतरण के लिए रिपोर्ट](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#report-for-evidence-handover)
- [एक बाहरी गवाह के रूप में Cloudflare](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#cloudflare-as-an-outside-witness)
- [परिनियोजन परिणाम पढ़ना](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#reading-the-deployment-result)

## एक सत्यापक क्या जाँच सकता है

| दावा | इसकी जाँच कैसे की जाती है | द्वारा बनाए रखा |
| --- | --- | --- |
| सर्वर को प्रदाता API के माध्यम से एक ज्ञात समय पर बनाया गया था | प्रोवाइडर के अपने लॉग में सर्वर ऑब्जेक्ट और उसकी निर्माण प्रक्रिया | प्रदाता |
| किसी ने प्रदाता के एक्सेस पाथ का उपयोग नहीं किया | कंसोल अनुरोधों, रेस्क्यू, पासवर्ड रीसेट, पुनर्निर्माण, ISO, छवियाँ, बैकअप का लॉग | प्रदाता |
| कुछ भी इससे जुड़ नहीं सकता | प्रदाता फ़ायरवॉल में कोई इनबाउंड नियम नहीं हैं; SSH को पहली बूट से ही छिपा दिया जाता है। | प्रदाता (फ़ायरवॉल), होस्ट (SSH) |
| पैनल केवल टनल के माध्यम से ही पहुँचा जा सकता है | टनल प्रवेश केवल पैनल पर अग्रेषित होता है; कनेक्टर सर्वर के पते से चलता है | क्लाउडफ्लेयर |
| यह बिल्कुल वही सॉफ़्टवेयर है जो चलता है | कलेक्टर के हस्ताक्षरित सोर्स-ट्री हैश की मानता है कि यह तैनात किए गए कमिट का चेकआउट है। | कलेक्टर, Git के खिलाफ जांचा गया |
| हस्ताक्षर कुंजी उस सर्वर पर बनाई गई थी | की प्रदाता के सर्वर आईडी और प्राप्त cloud-init के हैश का नाम बताने वाले एक कथन पर हस्ताक्षर करती है। | प्रदाता के खिलाफ जांचा गया कलेक्टर |
| यह जर्नल उस कुंजी और सर्वर से संबंधित है | प्रत्येक प्रक्रिया साक्ष्य में शुरू होती है ZIP उस सर्वर के लिए होस्ट माप को वहन करता है | साक्ष्य ZIP |

कलेक्टर हस्ताक्षरित process-start और `host.state` रिकॉर्ड में SSH स्थिति, सत्र, लॉगिन इतिहास और बूट जानकारी रिकॉर्ड करता है। एक सामान्य वीएम पर ये स्थानीय इन्वेंटरी रिकॉर्ड होते हैं, जिनकी समीक्षक प्रदाता के स्वतंत्र रिकॉर्ड से तुलना करता है। नीचे दी गई 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 कॉन्फ़िगरेशन और पर्यावरण परिवर्तन, पुनरारंभ, OS अपग्रेड | जबकि एप्लिकेशन मौजूद है |
| `generic` | कोई नहीं | कोई नहीं | कोई नहीं: **स्व-प्रमाणित** | – |

प्रत्येक मामले के लिए एक समर्पित प्रोजेक्ट, टीम, खाता या उप-खाता का उपयोग करें: सत्यापनकर्ता की केवल-पठन (read-only) पहुँच तब केवल इस तैनाती को दिखाती है। प्रमाण-पत्र (Credentials) से पढ़े जाते हैं `--provider-token-file` या उपरोक्त चर, कमांड लाइन से कभी नहीं। AWS के लिए फ़ाइल में `ACCESS_KEY_ID SECRET_ACCESS_KEY [SESSION_TOKEN]`; क्षेत्र है `--location`.

प्रत्येक प्रदाता के रिकॉर्ड में जो दिखाया नहीं जा सकता, वह हर रिपोर्ट में मुद्रित होता है। संक्षेप में: Hetzner कंसोल अनुरोधों को लॉग करता है; DigitalOcean का रिकवरी कंसोल, Linode का Lish/Glish और Vultr का वेब कंसोल इस तरह से लॉग नहीं होते हैं, इसलिए पहले बूट पर रूट लॉक हो जाता है और कंसोल लॉगिन के लिए पासवर्ड रीसेट या बूट परिवर्तन की आवश्यकता होगी, जिन्हें लॉग किया जाता है। Vultr कंसोल पता उस किसी भी कुंजी को लौटाता है जो इंस्टेंस को पढ़ सकती है; न तो रिकॉर्ड और न ही रिपोर्ट इसे संग्रहीत करती है।

## फला क्लाउड पर गोपनीय वीएम (इंटेल टीडीएक्स)

के साथ `--provider phala` कलेक्टर dstack द्वारा प्रबंधित [Phala Cloud](https://phala.com/) पर एक Intel TDX कॉन्फिडेंशियल वर्चुअल मशीन में चलता है। होस्ट और Phala का स्टाफ इसकी मेमोरी नहीं पढ़ सकता है, और प्रोसेसर इस बात की एक पुष्टि पर हस्ताक्षर करता है कि मशीन ने क्या बूट किया है। वेरिफायर Phala की बात पर भरोसा नहीं करता है: `tgwitness.tdx` हर प्रमाणीकरण को स्वयं, पिन किए गए Intel SGX रूट CA तक, Intel की रद्दीकरण सूचियों और Intel के हस्ताक्षरित प्लेटफ़ॉर्म डेटा के विरुद्ध जाँचता है, और उन मशीनों को अस्वीकार कर देता है जिन्हें डीबग या माइग्रेट किया जा सकता है।

| रिपोर्ट प्रविष्टि | यह क्या दिखाता है |
| --- | --- |
| `tdx_binding` | प्रमाणिकरण कलेक्टर के हस्ताक्षरित बयान और इस अनुरोध के यादृच्छिक मान को कवर करता है। |
| `tdx_quote` | इंटेल प्रमाणीकरण की गारंटी देता है; यह केवल तभी पास होता है जब इंटेल प्लेटफ़ॉर्म को अद्यतित मानता है |
| `tdx_compose_hash` | RTMR3, जिसे dstack इवेंट लॉग से फिर से चलाया गया है, वह ऐप-कंपोज को मापता है जिसे कलेक्टर रिपोर्ट करता है |
| `tdx_compose` | वह कंपाइलेशन बाइट-दर-बाइट वही है जो तैनात किए गए कमिट के कोड द्वारा बनाया जाता है: हैश द्वारा पिन की गई स्रोत फ़ाइलें, दोनों छवियाँ डिज़ाइग द्वारा, कोई अन्य कोड नहीं। |
| `tdx_identity` | प्रमाणिकता तैनात एप्लिकेशन और इंस्टेंस से आती है, जिसमें Phala के KMS की कुंजियाँ और एक एन्क्रिप्टेड डिस्क शामिल हैं। |
| `tdx_os` | MRTD और RTMR0-2 उन मानों के बराबर होते हैं जिन्हें वेरिफायर, Dstack-TEE द्वारा प्रकाशित dstack OS इमेज से, CVM द्वारा रिपोर्ट किए गए OS इमेज हैश द्वारा खोजी गई इमेज से, और VM के आकार के लिए QEMU द्वारा बनाए गए ACPI टेबलों से गणना करता है: फर्मवेयर, कर्नेल, 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 कुंजी पेस्ट करें; क्विक टनल 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` इंटेल के प्रमाणपत्रों और रद्दीकरण सूचियों को इंटेल से डाउनलोड करने के बजाय एक फ़ाइल से पढ़ता है। गेटवे DNS यहां उपलब्ध नहीं है: फला के पास आउटगोइंग ट्रैफ़िक के लिए कोई प्रदाता फ़ायरवॉल नहीं है।

### प्रमाणपत्र

Phala deployment `verify --report certificate.md` प्रमाणपत्र भी लिखता है: एक स्वयं-निहित `certificate.html` और एक A4 `certificate.pdf` जिसमें निष्कर्ष, Intel की रूट से कलेक्टर कुंजी तक की विश्वास श्रृंखला, साधारण और उच्च-आश्वासन सर्वरों के साथ तुलना, प्रकाशित इमेज से गणना किए गए मानों के बगल में माप, प्रत्येक भाग के लिए कौन ज़मानत देता है, Intel प्रमाणपत्र श्रृंखला, हर जाँच, प्रदाता लॉग, और सत्यापन को दोहराने का तरीका शामिल है। JSON रिपोर्ट प्रामाणिक रिकॉर्ड बनी रहती है; पेज इसे प्रदर्शित करते हैं।

रिपोर्ट को `certificate.seal.json` और इसके बगल में रखी `.tsq`/`.tsr` फ़ाइलों में हस्ताक्षरों और समय-मुद्रणों के साथ डिजिटल रूप से सील किया गया है:

| सील | इसमें क्या जोड़ा गया है |
| --- | --- |
| प्रमाणित इलेक्ट्रॉनिक टाइम स्टैम्प, `http://tsa.belgium.be/connect` | बेल्जियम की संघीय सरकार के योग्य ट्रस्ट सेवा प्रदाता (FPS नीति और समर्थन, BOSA) से `certificate.json` के सटीक बाइट्स पर RFC 3161 टाइमस्टैम्प। इसकी इकाई को बेल्जियम की EU विश्वसनीय सूची में एक योग्य टाइम-स्टैम्पिंग सेवा के रूप में, अनुदानित स्थिति के साथ सूचीबद्ध किया गया है; रूट (बेल्जियम रूट CA6) और सूची की प्रविष्टियाँ, 20 अक्टूबर 2026 को जारी सूची के अनुसार, `tgwitness/tsa_roots.py` में पिन की गई हैं। नियम (ईयू) संख्या 910/2014, अनुच्छेद 41 के तहत, प्रत्येक ईयू सदस्य राज्य में इस तरह की टाइमस्टैम्प को तिथि और समय तथा डेटा की अखंडता के संबंध में सटीक माना जाता है। |
| RFC 3161 टाइमस्टैम्प, FreeTSA | एक दूसरा, स्वतंत्र टाइमस्टैम्प |
| सत्यापनकर्ता हस्ताक्षर | रिपोर्ट के SHA-256 और प्रत्येक टाइमस्टैम्प का नाम बताने वाले एक स्टेटमेंट पर Ed25519, वेरिफायर की अपनी कुंजी (`--sign-with FOLDER`, डिफ़ॉल्ट `~/.tgwitness/verifier`) के साथ; PDF में उसी कुंजी द्वारा एक हस्ताक्षर होता है |

`--timestamp URL` (दोहराने योग्य) अन्य प्राधिकरणों को चुनता है, `--timestamp none` कोई नहीं, `--sign-with
none` सील को बिना हस्ताक्षर के छोड़ देता है। `check-report` रिपोर्ट के हैश, सत्यापनकर्ता के हस्ताक्षर, प्रत्येक टाइमस्टैम्प को एक विश्वसनीय रूट और उसकी योग्य स्थिति से, और PDF के हस्ताक्षर की जाँच करता है। यूरोपीय संघ के बाहर एक योग्य टाइमस्टैम्प, और पूरी रिपोर्ट का कानूनी भार, इसे प्राप्त करने वाली अदालत या प्राधिकरण पर निर्भर करता है; सील यह दर्शाती है कि रिपोर्ट कब मौजूद थी और यह कि उसमें कोई बदलाव नहीं हुआ है।

एक प्रमाणीकरण Intel के TDX मॉड्यूल या माइक्रोकोड में किसी खामी, या मेमोरी बस तक भौतिक पहुँच को खारिज नहीं कर सकता। Phala के खाते में एप्लिकेशन को जो भी नियंत्रित करता है, वह एक और कंपोज़ तैनात कर सकता है; यह एक नए कंपोज़ हैश के साथ एक नए संस्करण के रूप में दिखाई देता है। होस्ट मशीन के समय स्रोत और नेटवर्क को नियंत्रित करता है।

डिप्लॉय, `--evidence` से सत्यापित करें, पुनरारंभ, OS इमेज की तुलना, डिजिटल रूप से सील किए गए हस्ताक्षरों और टाइमस्टैम्प वाले प्रमाणपत्र और नष्ट करें Phala Cloud पर ही चले हैं; देखें [, 4 नवंबर 2026 का रन](https://phishdestroy.github.io/TgWitness/hi/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** और, ऑडिट लॉग के लिए, **Account Settings Read**। डोमेन के बिना, एक [त्वरित टनल](https://phishdestroy.github.io/TgWitness/hi/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. चलाने के लिए commit। एक release tag एक बार अपने commit के साथ resolved होता है `git ls-remote`; सर्वर को केवल 40-अक्षर वाला कमिट ही प्राप्त होता है।

## पैनल से

अपने कंप्यूटर पर, **Extras → Server 24/7** वही चलाता है `deploy` तीन चरणों में Hetzner के लिए: यूरोप या संयुक्त राज्य अमेरिका चुनें, एक Hetzner टोकन (पढ़ें और लिखें) पेस्ट करें, फिर सर्वर का प्रकार, मासिक मूल्य, पता और संस्करण की समीक्षा करें जो पैनल ने उस टोकन के साथ पाया। आप पुष्टि करने से पहले कुछ भी नहीं बनाया जाता है। पैनल प्रत्येक चरण को इस प्रकार दिखाता है `deploy` यह रिपोर्ट करता है, फिर पता, पैनल टोकन और साइनिंग की फिंगरप्रिंट। डोमेन के बिना सर्वर को एक [त्वरित टनल](https://phishdestroy.github.io/TgWitness/hi/docs/reference/high-assurance/#quick-tunnel-without-a-domain) मिलता है; **आपके सर्वर → वर्तमान पता खोजें** पुनरारंभ के बाद फिर से इसे देखता है। अपने स्वयं के डोमेन के तहत एक स्थिर पते के लिए, **वैकल्पिक · अपना स्वयं का डोमेन** खोलें और एक Cloudflare टोकन जोड़ें (तैयार लिंक ज़ोन पढ़ें, DNS संपादन और Cloudflare टनल संपादन का चयन करता है)।

टोकन ब्राउज़र टैब से उसी कंप्यूटर पर TgWitness तक प्रत्येक अनुरोध के साथ चलते हैं और कहीं भी लिखे नहीं जाते; डिप्लॉयमेंट रिकॉर्ड, संशोधित क्लाउड-इनिट, पैनल टोकन और, एक त्वरित टनल के लिए, एड्रेस की को में रखा जाता है `deployments/NAME` डेटा निर्देशिका के अंदर। पैनल यह केवल मुख्य प्रशासक को एक सीधे लूपबैक कनेक्शन पर प्रदान करता है (`127.0.0.1`, कोई प्रॉक्सी या टनल हेडर नहीं); एक पैनल जो नेटवर्क के माध्यम से पहुँचा जाता है, उसके बजाय कमांड दिखाता है। संस्करण डिफ़ॉल्ट रूप से चल रहे पैनल के रिलीज़ टैग पर होता है, जिसे GitHub API के माध्यम से हल किया जाता है। स्थान, सर्वर का प्रकार और कीमत Hetzner की API से आते हैं: `cpx22` जहाँ यह पेश किया जाता है, अन्यथा कम से कम 2 GB मेमोरी के साथ सबसे सस्ता x86 प्रकार।

## डोमेन के बिना त्वरित टनल

`--quick-tunnel` replaces `--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` चेक में ऐसा कहता है; एक जाली पोस्ट केवल उस चेक को विफल कर सकती है, क्योंकि एड्रेस को अभी भी कलेक्टर की कुंजी से जवाब देना होगा।

इसकी लागत: कोई क्लाउडफ्लेयर खाता एक त्वरित टनल का रिकॉर्ड नहीं रखता है, इसलिए `verify` टनल, कनेक्टर और DNS जांच को अनुपलब्ध के रूप में रिपोर्ट करता है और परिणाम सर्वोत्तम स्थिति में `incomplete` होता है (Phala पर क्लाउड में जाँच इसके बजाय पास हो जाती है: कनेक्टर मापे गए डॉकर कम्पोज कॉन्फ़िगरेशन के अंदर चलता है); प्रदाता रिकॉर्ड, फ़ायरवॉल, हस्ताक्षरित बयान, होस्ट माप और इंस्टॉलर की तुलना सामान्य रूप से जाँची जाती है। संदर्भ इंस्टॉलर के साथ बाइट तुलना के लिए एक तैनात कमिट की आवश्यकता होती है जो पहले से ही `--quick-tunnel` को जानता हो; एक 0.7.0 चेकआउट डोमेन इंस्टॉलर का निर्माण करता है और अंतर की रिपोर्ट करता है। क्लाउडफ्लेयर क्विक टनल्स को कोई अपटाइम गारंटी नहीं देता, एक साथ 200 अनुरोधों की अनुमति देता है और सर्वर-सेंट इवेंट्स को नहीं ले जाता है, इसलिए पैनल के लाइव अपडेट (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` डिफ़ॉल्ट रूप से प्रत्येक प्रदाता का यूबंटू 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/hi/docs/reference/accounts/) में है। पैनल क्रियाएँ हस्ताक्षरित जर्नल में दर्ज की जाती हैं; वे SSH सत्र नहीं हैं। एक [विटनेस](https://phishdestroy.github.io/TgWitness/hi/docs/reference/witness/) पोल कर सकता है `https://case-witness.example.org`.

कोई SSH नहीं है: यदि बूटस्ट्रैप विफल हो जाता है, तो कलेक्टर कभी जवाब नहीं देता। सर्वर को हटा दें और फिर से डिप्लॉय करें, या कारण खोजने के लिए डिबग डिप्लॉयमेंट का उपयोग करें।

### उपयोगकर्ता डेटा में छिपे रहस्य

क्लाउड-इनिट दो सीक्रेट्स रखता है: पैनल टोकन और क्लाउडफ्लेयर टनल टोकन। साइनिंग की उनमें शामिल नहीं है; यह सर्वर पर बनाई जाती है। हेत्ज़नर, डिजिटलओशन और लिनोड अपनी API के माध्यम से उपयोगकर्ता डेटा वापस नहीं करते हैं। Vultr इसे किसी भी की को लौटाता है जो इंस्टेंस को पढ़ सकती है, और EC2 के माध्यम से `DescribeInstanceAttribute`. AWS के लिए वेरिफायर को केवल तालिका में तीन क्रियाएँ दें, कभी भी `ec2:Describe*`. Vultr के लिए, मान लें कि सत्यापनकर्ता की कुंजी दोनों टोकन पढ़ सकती है। एक टनल टोकन किसी को दूसरा कनेक्टर चलाने देता है: `verify` सर्वर पर नहीं होने वाले किसी भी कनेक्टर की रिपोर्ट करता है, और कलेक्टर के बयानों को इस तरह से जाली नहीं बनाया जा सकता क्योंकि प्रत्येक एक नए चुनौती पर हस्ताक्षर करता है। के साथ `--quick-tunnel` दूसरा रहस्य इसके बजाय एड्रेस की (address key) है: जो कोई भी इसे पढ़ता है, वह एक झूठा पता पोस्ट कर सकता है जिसे पैनल स्वीकार कर लेगा।

संग्रहकर्ता का सार्वजनिक बयान सर्वर का पता और लॉगिन के स्रोतों को छोड़ देता है; दोनों हस्ताक्षरित जर्नल में रहते हैं।

## डिबग डिप्लॉयमेंट और लॉक

`--debug-ssh-key KEY --debug-ssh-from 198.51.100.4` एक पते या छोटे नेटवर्क से एक कुंजी के लिए SSH को सीमित करता है, IPv4 के लिए अधिकतम एक /24 या IPv6 के लिए एक /48। `KEY` पहले से ही प्रदाता के साथ पंजीकृत है: Hetzner प्रोजेक्ट में एक SSH कुंजी का नाम या ID, DigitalOcean टीम में एक SSH कुंजी की ID या फिंगरप्रिंट, एक Linode उपयोगकर्ता नाम जिसके प्रोफ़ाइल में SSH कुंजियाँ रूट में जोड़ी जाती हैं, Vultr खाते में एक SSH कुंजी की ID, या क्षेत्र में एक EC2 कुंजी जोड़ी का नाम। ये विकल्प पर लागू नहीं होते `generic`. ऐसी तैनाती को के रूप में दर्ज किया जाता है `debug` और **कभी नहीं** को high-assurance के रूप में रिपोर्ट किया जाता है। जब आप समाप्त कर लें, तो चलाएँ `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 द्वारा सत्यापित किया जाता है, जैसा कि [Evidence](https://phishdestroy.github.io/TgWitness/hi/docs/reference/evidence/) में है।

प्रोवाइडर क्रियाओं को वर्गीकृत किया जाता है: निर्माण और निर्माण के 30 मिनट के भीतर शुरू होने वाली क्रियाएँ पास हो जाती हैं; कंसोल, रेस्क्यू, पासवर्ड रीसेट, रीबिल्ड, ISO, इमेज, स्नैपशॉट, बैकअप, सिस्टम्स मैनेजर, EC2 इंस्टेंस कनेक्ट और फ़ायरवॉल ओपनिंग विफल हो जाती हैं; पावर क्रियाएँ और कोई भी अप्रत्याशित क्रिया समीक्षा के लिए चिह्नित की जाती हैं। एक अज्ञात क्रिया कभी भी चुपचाप पास नहीं होती।

## साक्ष्य हस्तांतरण के लिए रिपोर्ट

`--report report.md` मार्कडाउन रिपोर्ट लिखता है और `report.json` इसके बगल में:

1. परिणाम, कलेक्टर कुंजी फिंगरप्रिंट, परिनियोजन, प्रदाता, कमिट, सर्वर, फ़ायरवॉल, टनल;
2. हर जाँच अपनी स्थिति और स्रोत (प्रदाता API, Cloudflare API, कलेक्टर स्टेटमेंट, सबूत जर्नल) के साथ;
3. प्रत्येक क्रिया के मूल्यांकन के साथ प्रदाता का लॉग और, जहाँ प्रदाता इसे रिकॉर्ड करता है, वहाँ कर्ता;
4. क्लाउडफ्लेयर एंडपॉइंट्स जो टनल के कनेक्शन, कॉन्फ़िगरेशन और ऑडिट लॉग को होल्ड करते हैं;
5. हस्ताक्षरित कलेक्टर वक्तव्य;
6. रिपोर्ट क्या स्थापित करती है और क्या नहीं;
7. इसे पुन: उत्पन्न करने के लिए कमांड, और इसे दी गई प्रत्येक फ़ाइल का SHA-256।

रिपोर्ट सौंपें, `report.json`, `deployment.json`, प्रकाशित इंस्टॉलर और साक्ष्य ZIP। रिपोर्ट जल्दी प्रस्तुत करें: प्रदाता लॉग सीमित समय के लिए रखे जाते हैं।

## बाहरी गवाह के रूप में क्लाउडफ्लेयर

यहाँ सब कुछ वैकल्पिक है। Cloudflare खाते के बिना भी सर्वर चलता रहता है, और इनमें से दो आज काम करते हैं:

| क्या | यह क्या दिखाता है | TgWitness में |
| --- | --- | --- |
| त्वरित टनल या आपके डोमेन का टनल | पैनल तक केवल सुरंग के माध्यम से ही पहुँचा जा सकता है | सर्वर विज़ार्ड, ऊपर देखें |
| ड्रैंड रिले `drand.cloudflare.com` | ड्रैंड राउंड के बाद रिकॉर्ड्स इससे नए होते हैं: जर्नल जैसे-जैसे लिखा गया, वैसे-वैसे तैयार हुआ। | सबूत मोड, **अधिक गवाह**, कोई खाता नहीं ([फ़ॉर्मेट](https://phishdestroy.github.io/TgWitness/hi/docs/reference/evidence/#optional-records-in-evidence-mode-drand-and-telegram-devices)) |
| टनल स्वास्थ्य सूचनाएँ | जब टनल डाउन हो, Cloudflare से ईमेल या वेबहुक द्वारा | उन्हें Cloudflare डैशबोर्ड में सेट करें |
| गेटवे DNS (`--gateway-dns`, या विज़ार्ड में **Cloudflare गेटवे DNS**) | सर्वर द्वारा खोजा गया प्रत्येक नाम, TLS पर Cloudflare द्वारा उत्तरित; Hetzner फ़ायरवॉल DNS को किसी अन्य चीज़ तक पहुँचने नहीं देता; क्या कोई गेटवे नीति उत्तरों को पुनर्लिखित कर सकती है | Hetzner, मुफ्त ज़ीरो ट्रस्ट प्लान, कोई डोमेन नहीं; `verify` फ़ायरवॉल, स्थान, लॉगिंग, नीतियों, सर्वर के क्वेरीज़ और ऑडिट लॉग की जाँच करता है; सबूत मोड लॉग की प्रतिलिपि जर्नल में कॉपी करता है |
| सर्वर पर Cloudflare One क्लाइंट के साथ गेटवे, एक आउटबाउंड फ़ायरवॉल जो केवल Cloudflare को अनुमति देता है | सर्वर द्वारा किया गया हर कनेक्शन, सिर्फ DNS नहीं | अभी तक नहीं बनाया गया |
| पैनल के सामने पहुँच | पैनल में किसने और कब साइन इन किया | बनाया नहीं गया: अपने स्वयं के डोमेन की आवश्यकता है |
| SSH कमांड लॉगिंग | डिबग सत्र में प्रत्येक कमांड | अभी तक नहीं बनाया गया |

Logpush, जो Cloudflare की अपनी प्रति R2 में रखता है, एक एंटरप्राइज़ फ़ीचर है: मुफ़्त प्लान पर Cloudflare जवाब देता है `logpush is not enabled for this account`. वहाँ इसका गेटवे लॉग 24 घंटे तक रहता है, इसलिए एविडेंस मोड इसे साइन किए गए जर्नल में कॉपी करता है (**Cloudflare गेटवे का इस सर्वर की DNS क्वेरीज़ का लॉग**, एक रीड-ओनली टोकन जिसके पास अकाउंट एनालिटिक्स रीड की अनुमति है)।

ज़ीरो ट्रस्ट योजना के बिना एक खाते का एक DNS स्थान होता है। जब Cloudflare किसी अन्य को अस्वीकार करता है, तो सर्वर मौजूदा वाले को साझा करता है और उसकी क्वेरीज़ को उसके पते से अलग बताया जाता है; उस फ़िल्टर को भी ज़ीरो ट्रस्ट PII रीड की आवश्यकता होती है, और `destroy` एक साझा स्थान छोड़ देता है। एक लॉग क्वेरी अधिकतम तीन घंटे तक फैली होती है, इसलिए कॉपी और `verify` दिन को तीन-तीन घंटे के अंतराल में पढ़ता है।

गेटवे DNS सिस्टम रिज़ॉल्वर को कवर करता है। पोर्ट 443 पर HTTPS पर दूसरे रिज़ॉल्वर को DNS, और किसी भी जगह न खोजे गए पते (जैसे टेलीग्राम के डेटा सेंटर) से कनेक्शन, इसके लॉग में नहीं होते हैं।

Cloudflare टेलीग्राम के एन्क्रिप्शन के अंदर, टेलीग्राम खाते पर अन्य डिवाइस (एविडेंस मोड की डिवाइस सूची उन्हें टेलीग्राम की ओर से रिकॉर्ड करती है) या प्रदाता के हाइपरवाइज़र को नहीं देख सकता।

## परिनियोजन परिणाम पढ़ना

एक सामान्य वीएम के लिए, प्रदाता होस्ट इंफ्रास्ट्रक्चर को नियंत्रित करता है, और प्रदाता रिकॉर्ड के साथ-साथ स्थानीय इन्वेंट्री की जाँच की जाती है। Intel TDX के लिए, सत्यापनकर्ता अतिरिक्त रूप से हार्डवेयर उद्धरण, कलेक्टर बाइंडिंग, कम्पोज़ और ओएस माप की जाँच करता है। यह देखने के लिए व्यक्तिगत परिणाम पढ़ें कि कौन सी जाँचें पास हुईं या अनुपलब्ध थीं।

ऐतिहासिक फ़ायरवॉल विवरण प्रदाता पर निर्भर करता है; Linode नियम संस्करणों को बनाए रखता है। [प्रमाणीकरण रिकॉर्ड](https://phishdestroy.github.io/TgWitness/hi/docs/reference/verification/) में परीक्षण किए गए डिप्लॉयमेंट और शेष लाइव जाँचें सूचीबद्ध होती हैं, और [प्रमाणीकरण दायरा](https://phishdestroy.github.io/TgWitness/hi/docs/reference/evidence/#verification-scope) इन पर्यावरण जाँचों को आर्काइव अधिग्रहण और अखंडता से जोड़ता है।