Windows फ़ायरवॉल और व्यावसायिक ऐप — इनबाउंड नियम इंस्टॉलर से पंजीकृत करें

«विकास मशीन पर बिना समस्या चलता है, ग्राहक पर डालते क्लाइंट सर्वर से नहीं जुड़ता।» «पहले स्टार्ट पर कोई चेतावनी आई, स्थल वाले ने रद्द कर दिया लगता है।» «netstat पर पोर्ट सुन रहा है, पड़ोसी PC से नहीं पहुँचता।» — व्यावसायिक ऐप लागू करने के स्थल पर इस तरह «संचार नहीं» पूछताछ तयशुदा में तयशुदा है। और कारणों में सबसे ऊपर बैठा Windows फ़ायरवॉल (Windows Defender Firewall) है।

कठिनाई यह कि विकास मशीन पर समस्या दिखती नहीं। विकास मशीन पर Visual Studio डिबग चलाते स्वयं अनुमति दी, या स्वयं व्यवस्थापक थे, इसलिए डिफ़ॉल्ट इनबाउंड ब्लॉक बिना देखे शिप हो जाता है। ग्राहक पर चलाने वाला व्यवस्थापक अधिकार रहित सामान्य उपयोगकर्ता है, नेटवर्क GPO से प्रबंधित। «चलना चाहिए था नहीं चला» नहीं, «विकास मशीन संयोग से चल रही थी» वास्तविकता है।

यह लेख स्वयं विकसित ऐप पर «ग्राहक पर संचार नहीं» झेलते व्यावसायिक-ऐप डेवलपर्स और वह पूछताछ लेने छोटे-मध्यम व्यवसाय के सूचना-प्रणाली कर्मियों के लिए है। Windows फ़ायरवॉल का डिफ़ॉल्ट व्यवहार और प्रोफ़ाइल न्यूनतम पकड़कर इनबाउंड नियम डिज़ाइन, इंस्टॉलर से पंजीकरण, पृथक्करण प्रक्रिया, GPO/Intune प्रबंधन के नीचे सावधानियाँ — अगस्त 2026 तक के प्राथमिक स्रोतों पर व्यवस्थित करता है।

1. निष्कर्ष पहले

• Windows फ़ायरवॉल का डिफ़ॉल्ट «इनबाउंड ब्लॉक, आउटबाउंड अनुमति» है। अनुरोध का उत्तर न हो इनबाउंड ट्रैफ़िक नियम से न मिले तो त्यागा जाता है।¹
• इनबाउंड नियम केवल पोर्ट सुनते सर्वर-प्रकार ऐप को चाहिए। स्वयं जुड़ने वाला क्लाइंट ऐप डिफ़ॉल्ट पर संचार कर सकता है। पहले यहीं पृथक करें।¹
• प्रोफ़ाइल तीन (डोमेन / निजी / सार्वजनिक)। डोमेन डोमेन नियंत्रक पकड़ते स्वतः लागू, सार्वजनिक अज्ञात नेटवर्क का डिफ़ॉल्ट। नियम प्रोफ़ाइल इकाई पर सक्षम-अक्षम।¹
• उस «महत्वपूर्ण चेतावनी» संवाद पर उत्पादन न छोड़ें। व्यवस्थापक रद्द करे तो ब्लॉक नियम बनता है; व्यवस्थापक अधिकार न हो तो कोई भी बटन ब्लॉक नियम बनाता है। बना नियम मिटाए बिना संवाद फिर नहीं आता।²
• निष्कर्ष: «व्यावसायिक ऐप का इनबाउंड नियम इंस्टॉलर से पंजीकृत करें»। Microsoft स्वयं पहले स्टार्ट से पहले नियम रखने और इनबाउंड सूचना अक्षम करने की अनुशंसा करता है।²
• नियम न्यूनतम अधिकार से डिज़ाइन करें। प्रोग्राम + प्रोटोकॉल + पोर्ट धुरी, प्रोफ़ाइल डोमेन/निजी तक, रिमोट IP आवश्यक सबनेट तक। प्रोग्राम पथ पर वाइल्डकार्ड नहीं।²³
• पृथक्करण Test-NetConnection → Get-NetFirewallRule → pfirewall.log क्रम है। फ़ायरवॉल लॉग डिफ़ॉल्ट नहीं लिखा जाता; त्यागे पैकेट का रिकॉर्ड सक्षम करने पर ही आता है।⁴⁵⁶
• सेवा रोककर पूरा अक्षम करना असमर्थित है। GPO/Intune प्रबंधन में «स्थानीय नियम मर्ज» अक्षम हो सकता है, तब स्थानीय नियम नहीं लगते। नियम का केंद्र वितरण सूचना प्रणाली से आवेदन करें।¹²

इस लेख का ज्ञान मानचित्र

Windows फ़ायरवॉल डिफ़ॉल्ट इनबाउंड ब्लॉक और आउटबाउंड अनुमति है; इनबाउंड नियम केवल पोर्ट सुनते सर्वर-प्रकार व्यावसायिक ऐप को चाहिए। नियम रहित ऐप सुने तो «महत्वपूर्ण चेतावनी» संवाद आता है, पर क्रिया से ब्लॉक नियम पककर संचार नहीं विफलता का कारण बनता है, इसलिए इनबाउंड नियम इंस्टॉलर से पंजीकृत करना मूल है। GPO/Intune प्रबंधन में स्थानीय नियम मर्ज अक्षम हो सकता है, तब स्थानीय पंजीकृत नियम लागू नहीं होते।

flowchart LR
    accTitle: Windows फ़ायरवॉल और व्यावसायिक ऐप का ज्ञान मानचित्र
    accDescr: Windows फ़ायरवॉल, इनबाउंड नियम, सुनने वाला ऐप, «महत्वपूर्ण चेतावनी» संवाद, इंस्टॉलर और व्यवस्थापक अधिकार, नियम संकीर्णता (प्रोग्राम निर्दिष्ट, रिमोट IP सीमित), स्थानीय नियम मर्ज, संचार नहीं विफलता और पृथक्करण आदेश के संबंध दर्शाने वाला चित्र
    windows_firewall["Windows फ़ायरवॉल"]
    inbound_rule["इनबाउंड नियम"]
    listen_app["सुनने वाला व्यावसायिक ऐप"]
    installer["इंस्टॉलर"]
    network_profile["नेटवर्क प्रोफ़ाइल"]
    communication_failure["«संचार नहीं» विफलता"]
    firewall_notification["«महत्वपूर्ण चेतावनी» संवाद"]
    exe_path_change["निष्पादन फ़ाइल पथ परिवर्तन"]
    pfirewall_log["फ़ायरवॉल लॉग (pfirewall.log)"]
    group_policy["Group Policy"]
    intune["Microsoft Intune"]
    local_policy_merge["स्थानीय नियम मर्ज"]
    mpssvc["फ़ायरवॉल सेवा (MpsSvc)"]
    port_rule["पोर्ट निर्दिष्ट नियम"]
    over_permission["नियम अति-अनुमति"]
    test_netconnection["Test-NetConnection"]
    get_netfirewallrule["Get-NetFirewallRule"]
    unsolicited_inbound["अनुरोध न इनबाउंड संचार"]
    netsh_advfirewall["netsh advfirewall"]
    new_netfirewallrule["New-NetFirewallRule"]
    admin_rights["व्यवस्थापक अधिकार"]
    remote_ip_scope["रिमोट IP सीमित"]
    program_rule["प्रोग्राम निर्दिष्ट नियम"]
    mpssvc_stop["MpsSvc सेवा रोकना"]
    firewall_disable["फ़ायरवॉल अक्षम करना"]
    named_pipe["नामित पाइप"]
    smb_445["SMB (TCP 445)"]
    get_netconnectionprofile["Get-NetConnectionProfile"]
    block_rule["ब्लॉक नियम"]
    notify_disable["इनबाउंड सूचना अक्षम"]
    service_rule["सेवा निर्दिष्ट नियम"]
    profile_limit["प्रोफ़ाइल सीमित करना"]
    updater_reregistration["अद्यतन पर नियम फिर पंजीकरण"]
    netstat["netstat"]
    listen_app -->|"अपेक्षित"| inbound_rule
    installer -->|"अनुशंसित उपाय"| inbound_rule
    network_profile -.->|"कारण बन सकता"| communication_failure
    firewall_notification -.->|"कारण बन सकता"| communication_failure
    exe_path_change -.->|"कारण बन सकता"| communication_failure
    communication_failure -->|"से जाँच योग्य"| pfirewall_log
    windows_firewall -->|"से कॉन्फ़िगर"| group_policy
    windows_firewall -->|"से कॉन्फ़िगर"| intune
    inbound_rule -.->|"अपेक्षित"| local_policy_merge
    mpssvc -->|"लागू करता है"| windows_firewall
    windows_firewall -->|"उपयोग करता है"| network_profile
    port_rule -.->|"कारण बन सकता"| over_permission
    exe_path_change -.->|"कारण बन सकता"| firewall_notification
    firewall_notification -->|"से कॉन्फ़िगर"| group_policy
    communication_failure -->|"से जाँच योग्य"| test_netconnection
    communication_failure -->|"से जाँच योग्य"| get_netfirewallrule
    windows_firewall -->|"रोकता है"| unsolicited_inbound
    inbound_rule -->|"से कॉन्फ़िगर"| netsh_advfirewall
    inbound_rule -->|"से कॉन्फ़िगर"| new_netfirewallrule
    inbound_rule -->|"अपेक्षित"| admin_rights
    remote_ip_scope -->|"कम करता है"| over_permission
    program_rule -->|"कम करता है"| over_permission
    firewall_notification -->|"अनुशंसित नहीं"| inbound_rule
    mpssvc_stop -->|"अनुशंसित नहीं"| firewall_disable
    remote_ip_scope -->|"अनुशंसित उपाय"| over_permission
    program_rule -->|"अनुशंसित उपाय"| over_permission
    named_pipe -->|"उपयोग करता है"| smb_445
    network_profile -->|"से जाँच योग्य"| get_netconnectionprofile
    firewall_notification -.->|"कारण बन सकता"| block_rule
    block_rule -->|"कारण बन सकता"| communication_failure
    notify_disable -->|"रोकता है"| firewall_notification
    service_rule -->|"कम करता है"| over_permission
    profile_limit -->|"कम करता है"| over_permission
    updater_reregistration -->|"अनुशंसित उपाय"| exe_path_change
    communication_failure -->|"से जाँच योग्य"| netstat

चित्र में ठोस रेखा हमेशा सत्य रहने वाला संबंध दर्शाती है और धराशायी रेखा सशर्त संबंध दर्शाती है (शर्तें विस्तृत पृष्ठ पर प्रत्येक संबंध के स्पष्टीकरण में दी गई हैं)। संबंधों की पूरी सूची (कुल 35, साक्ष्य और निश्चितता सहित) तथा मुख्य अवधारणाओं की परिभाषाएँ ज्ञान मानचित्र के विस्तृत पृष्ठ पर संकलित हैं (जापानी में)। डेटा: JSON-LD / Turtle

2. डिफ़ॉल्ट व्यवहार ठीक — इनबाउंड डिफ़ॉल्ट ब्लॉक, आउटबाउंड डिफ़ॉल्ट अनुमति

पहले नींव ठीक पकड़ें। Windows फ़ायरवॉल सब संस्करणों पर डिफ़ॉल्ट सक्षम होस्ट फ़ायरवॉल है; डिफ़ॉल्ट व्यवहार दो पंक्तियाँ हैं।¹

• इनबाउंड (inbound): अनुरोध का उत्तर (solicited) हो या नियम से मेल न खाए तो सब ब्लॉक
• आउटबाउंड (outbound): नियम से न मिले तो सब अनुमति

इन दो पंक्तियों से व्यावसायिक ऐप का सबसे महत्त्वपूर्ण पृथक्करण निकलता है। इनबाउंड नियम केवल «सुनने वाले पक्ष» को चाहिए।

• आंतरिक वेब सर्वर, DB सर्वर, मुख्य प्रणाली से स्वयं जुड़ने वाला क्लाइंट ऐप → मूलतः नियम नहीं। कनेक्शन की वापसी पैकेट «अनुरोध का उत्तर» हैं, डिफ़ॉल्ट निकलते हैं।
• TCP, gRPC, निजी प्रोटोकॉल आदि से पोर्ट खोलकर कनेक्शन सुनने वाले सर्वर-प्रकार ऐप / Windows सेवा → इनबाउंड नियम अनिवार्य।
• ध्यान: रिमोट से नामित पाइप उपयोग अपवाद है। रिमोट नामित पाइप ऐप के अपने पोर्ट नहीं, SMB (TCP 445) से जाते हैं, इसलिए चाहिए ऐप का नियम नहीं, फ़ाइल साझा (SMB) पक्ष का नियम।
• अपवाद: आउटबाउंड डिफ़ॉल्ट जान-बूझकर ब्लॉक किए उच्च-सुरक्षा वातावरण। कुछ संगठनों में ही है; तब क्लाइंट ऐप को भी आउटबाउंड नियम आवेदन चाहिए।²

flowchart TB
    accTitle: इनबाउंड नियम केवल सुनने वाले पक्ष को चाहिए
    accDescr: केवल क्लाइंट के रूप में जुड़ें तो इनबाउंड नियम मूलतः नहीं चाहिए, पोर्ट खोलकर सुनें तो इंस्टॉलर से इनबाउंड नियम पंजीकृत करें
    APP["स्वयं के ऐप का संचार छाँटें"] --> Q{"पोर्ट खोलकर<br/>कनेक्शन सुनता है?"}
    Q -- "नहीं सुनता<br/>(केवल क्लाइंट के रूप में जुड़ता है)" --> C1["इनबाउंड नियम मूलतः नहीं<br/>कनेक्शन की वापसी «उत्तर» के रूप में निकलती है"]
    Q -- "सुनता है<br/>(सर्वर-प्रकार・कॉलबैक प्राप्ति)" --> S1["इनबाउंड नियम अनिवार्य<br/>→ इंस्टॉलर से पंजीकरण (अध्याय 5)"]
    C1 -.-> EX["अपवाद: आउटबाउंड डिफ़ॉल्ट ब्लॉक<br/>उच्च-सुरक्षा वातावरण में आउटबाउंड नियम आवेदन"]

चित्र 1: पोर्ट सुनता हो तो इनबाउंड नियम अनिवार्य; केवल क्लाइंट जुड़ाव मूलतः नियम नहीं चाहता।

«क्लाइंट समझा ऐप वास्तव में सुनता भी है» मामला (परिणाम कॉलबैक प्राप्ति, अन्य प्रोसेस से सूचना द्वार आदि) आसानी से छूटता है। स्वयं का ऐप किस संचार तरीके से सुनता है अस्पष्ट हो तो डिज़ाइन चरण की व्यवस्था «प्रोसेस-अंतर संचार कैसे चुनें» साथ देखें।

2.1. प्रोफ़ाइल और «नेटवर्क स्थान»

नियम नेटवर्क प्रोफ़ाइल इकाई पर लागू होते हैं। प्रोफ़ाइल तीन हैं।¹

अभी कौन सी प्रोफ़ाइल लागू है Get-NetConnectionProfile से देखें; निजी/सार्वजनिक बदलना Set-NetConnectionProfile से।¹ स्थल की आम दुर्घटना: ग्राहक वर्कग्रुप वातावरण में नेटवर्क «सार्वजनिक» तय हो जाता है, डोमेन/निजी सीमित बनाए इनबाउंड नियम लागू नहीं। «नियम है पर नहीं निकलता» हो तो नियम की सामग्री से पहले प्रोफ़ाइल मेल संदेह करें।

2.2. नियमों की प्राथमिकता

कई नियम हों तो मूल्यांकन भारित क्रम सूची नहीं, ये सुसंगत सिद्धांत हैं।²

1. स्पष्ट अनुमति नियम डिफ़ॉल्ट ब्लॉक से प्राथमिक
2. स्पष्ट ब्लॉक नियम टकराते अनुमति नियम से प्राथमिक
3. उपरोक्त 2 के विरुद्ध न जाते अधिक विशिष्ट नियम प्राथमिक

व्यवहार का अर्थ: «कहीं एक ब्लॉक नियम हो तो बाद में कितने अनुमति जोड़ें, नहीं जीतते»। अगले अध्याय में ठीक यही ब्लॉक नियम वह संवाद चुपचाप बनाता है।

3. «महत्वपूर्ण चेतावनी» संवाद की पहचान — न छोड़ने का कारण

ऐप पहली बार पोर्ट सुनना (listen) शुरू करे और उस ऐप पर अनुमति नियम भी व्यवस्थापक-परिभाषित नियम न हो, तो Windows «इस ऐप की कुछ सुविधाएँ Windows Defender फ़ायरवॉल से अवरुद्ध हैं» वाला जाना-पहचाना «Windows सुरक्षा की महत्वपूर्ण चेतावनी» संवाद दिखाता है। व्यवहार विनिर्देश साफ है।²

• व्यवस्थापक अधिकार वाले उपयोगकर्ता को दिखा: «पहुँच अनुमति दें» से अनुमति नियम बनता है। पर «रद्द» दबाने पर ब्लॉक नियम बनता है। सामान्यतः TCP और UDP दो।
• व्यवस्थापक अधिकार न हो: कोई विकल्प चुनें, ब्लॉक नियम बनता है।
• दोनों में बना नियम मिटाए बिना संवाद फिर नहीं आता, संचार अवरुद्ध रहता है।

flowchart TB
    accTitle: «महत्वपूर्ण चेतावनी» संवाद की शाखा
    accDescr: नियम न हो और इनबाउंड सूचना सक्षम हो तो संवाद आता है, रद्द या सामान्य उपयोगकर्ता की क्रिया से ब्लॉक नियम बनता है और फिर नहीं आता
    L["ऐप पोर्ट सुनना शुरू करता है"] --> Q1{"उस ऐप से मेल खाता<br/>नियम है?"}
    Q1 -- "है" --> R1["नियम के अनुसार<br/>(संवाद नहीं आता)"]
    Q1 -- "नहीं" --> Q2{"इनबाउंड सूचना<br/>सक्षम है?"}
    Q2 -- "अक्षम" --> R2["चुपचाप ब्लॉक<br/>(नियम नहीं बनता)"]
    Q2 -- "सक्षम" --> DLG["«महत्वपूर्ण चेतावनी» संवाद"]
    DLG -- "व्यवस्थापक «पहुँच अनुमति दें»" --> OK["अनुमति नियम बनता है"]
    DLG -- "व्यवस्थापक «रद्द»" --> NG1["ब्लॉक नियम बनता है"]
    DLG -- "व्यवस्थापक अधिकार न उपयोगकर्ता<br/>(कोई भी क्रिया)" --> NG2["ब्लॉक नियम बनता है"]
    NG1 --> NEVER["नियम मिटाए तक<br/>संवाद फिर नहीं आता"]
    NG2 --> NEVER

चित्र 2: संवाद रद्द या बिना अधिकार उपयोगकर्ता की क्रिया से ब्लॉक नियम पका देता है; मिटाए बिना फिर नहीं आता।

अर्थात यह संवाद «उपयोगकर्ता से अनुमति माँगने का तंत्र» लगता है, व्यावसायिक ऐप के स्थल पर «सामान्य उपयोगकर्ता छूते ही ब्लॉक नियम पकाने का तंत्र» बनकर काम करता है। लागू करने वाला व्यवस्थापक खाते से पहला स्टार्ट कर संवाद से अनुमति दे तो बना अनुमति नियम पूरे PC पर लगता है, अगले दिन से सामान्य उपयोगकर्ता भी फिलहाल संचार कर सकते हैं। फिर भी दुर्घटना बचती है — लागू करते सत्यापन न छुआ सुनना सामान्य उपयोगकर्ता पहले छुए, लागू नेटवर्क प्रोफ़ाइल लागू करते से अलग हो, और अद्यतन से exe पथ बदले (अध्याय 4, 5)।

Microsoft स्वयं व्यवस्थापक के अलावा उपयोग वाले डिवाइस पर यह सर्वोत्तम अभ्यास स्पष्ट लिखता है।²

1. ऐप के पहले स्टार्ट से पहले आवश्यक नियम रखें (इंस्टॉलर या प्रबंधन पक्ष वितरण)
2. इनबाउंड सूचना अक्षम करें (सूचना काटें तो रनटाइम स्वतः नियम निर्माण स्वयं नहीं होता)

सूचना अक्षम Set-NetFirewallProfile -NotifyOnListen False या Group Policy से।⁷ «संवाद आए तो स्थल वाले से अनुमति दिलवाएँ» संचालन प्रक्रिया नहीं, दुर्घटना का आरक्षण है। इनबाउंड नियम इंस्टॉल पर पंजीकृत करें — यही इस लेख का निष्कर्ष है, Microsoft की अनुशंसा से भी मेल खाता है।

4. इनबाउंड नियम डिज़ाइन — प्रोग्राम, पोर्ट, सेवा निर्दिष्ट

पंजीकृत नियम की सामग्री डिज़ाइन करें। निर्दिष्ट तीन परिवार, अकेले या मिलाकर।

उस पर सीमा और चढ़ाएँ। Microsoft डिज़ाइन अनुशंसा भी «इनबाउंड नियम जितना हो सके विशिष्ट» है।²

• प्रोफ़ाइल सीमित: केवल आंतरिक उपयोग व्यावसायिक ऐप के इनबाउंड नियम डोमेन/निजी तक, सार्वजनिक पर सक्षम न करें। नोटबुक बाहरी Wi-Fi से जुड़ते ही सुनने वाला पोर्ट दुनिया को खुल जाए — यह दुर्घटना रोकता है।
• रिमोट IP सीमित: स्रोत तय हो तो -RemoteAddress उस सबनेट तक। घर-छोटे नेटवर्क के लिए LocalSubnet कीवर्ड अनुशंसित।²³
• दिशा और संख्या: सुनना केवल TCP हो तो TCP का एक नियम काफी। संवाद स्वतः बनाए जैसे TCP/UDP दोनों आलस से न बनाएँ।

«आवश्यक पक्ष से, आवश्यक पोर्ट पर, आवश्यक प्रोग्राम ही» — इनबाउंड नियम डिज़ाइन इसी न्यूनतम अधिकार के एक वाक्य में समाता है।

5. इंस्टॉलर से पंजीकरण — netsh और New-NetFirewallRule

5.1. पूर्वापेक्षा: व्यवस्थापक अधिकार चाहिए

फ़ायरवॉल नियम जोड़ना-हटाना पूरे कंप्यूटर की सेटिंग बदलना है, इसलिए व्यवस्थापक अधिकार (उन्नत प्रोसेस) से चलाना होगा।⁸ इंस्टॉलर सामान्यतः व्यवस्थापक अधिकार से चलता है, इसलिए नियम पंजीकरण इंस्टॉल प्रसंस्करण में रखना तर्कसंगत है। ऐप स्वयं को व्यवस्थापक से चलाने का कारण नहीं बनता। यह रेखा «व्यवस्थापक अधिकार कब चाहिए» में विस्तार से है।

5.2. netsh advfirewall से पंजीकरण

क्लासिक पर किसी भी इंस्टॉलर से बुलाना आसान netsh advfirewall firewall add rule है।⁸

rem add rule समान नाम हो तब भी जोड़ता है, इसलिए पुनर्इंस्टॉल・मरम्मत・
rem अद्यतन पर पुनः चलाने को समान नाम नियम मिटाकर फिर पंजीकृत करें
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem प्रोग्राम निर्दिष्ट+पोर्ट निर्दिष्ट+प्रोफ़ाइल सीमित इनबाउंड अनुमति नियम
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem अनइंस्टॉल पर: नाम से मिटाएँ
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule मौजूदा समान नाम नियम बदलता नहीं समान नाम से जोड़ता है, इसलिए पहले delete rule न चलाएँ तो हर पुनः चलाने पर नियम बढ़ते हैं, पथ या सीमा बदले अद्यतन बाद भी पुराना अनुमति नियम बचता है (पहले चलाने पर अग्रिम delete rule «मेल खाता नियम नहीं» लौटाता है, बैच चलना जारी रहता है, इसलिए यह क्रम ठीक है। इंस्टॉलर सफलता निकास कोड से नापें तो अंत के add rule का परिणाम देखें)। remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet जैसे स्रोत भी संकीर्ण कर सकते हैं।⁸ मिटाना नाम से मेल नियम एक साथ हटाता है, इसलिए नियम नाम कंपनी उपसर्ग सहित अद्वितीय सुरक्षित है।

5.3. PowerShell (New-NetFirewallRule) से पंजीकरण

अधिक बारीक नियंत्रण हो तो NetSecurity मॉड्यूल। -DisplayName अनिवार्य, -Profile अल्पविराम (रिक्त नहीं) से कई।³

# पंजीकरण (इंस्टॉलर से उन्नत अवस्था में)। -Name अद्वितीय पहचानकर्ता है,
# पुनर्इंस्टॉल・मरम्मत・अद्यतन पर पुनः चलाने से समान नाम बनाना
# त्रुटि देता है। मौजूदा समान नाम मिटाकर बनाना से idempotent
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 inbound)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# अनइंस्टॉल पर: न हो तो भी त्रुटि न दें
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

यहाँ -Name स्पष्ट लिखने का कारण है। -Name नियम का अद्वितीय पहचानकर्ता है; छोड़ें तो यादृच्छिक मान मिलता है। प्रदर्शन नाम (-DisplayName) लोकेल से बदल सकता है, इसलिए स्क्रिप्ट से नियम पहचानने की कुंजी -Name Microsoft का निर्देश है।³ अनइंस्टॉलर अपने नियम ही पक्का मिटाए, इसके लिए -Name स्थिर अनिवार्य समझें।

5.4. अद्यतन से exe पथ बदले

प्रोग्राम निर्दिष्ट नियम पूर्ण पथ से लक्ष्य बाँधता है। अर्थात अद्यतन से इंस्टॉल स्थान या exe नाम बदले तो नियम बचा रहता है पर लक्ष्य खो देता है, सुनना फिर ब्लॉक होता है। तब नए पथ का exe «नियम रहित ऐप» माना जाता है; सूचना सक्षम वातावरण में अध्याय 3 का संवाद फिर आता है, सामान्य उपयोगकर्ता छुए तो ब्लॉक नियम पकता है। अध्याय 3 की अनुशंसा अनुसार सूचना अक्षम वातावरण में संवाद भी बिना चुपचाप विफल। संस्करण संख्या वाले फ़ोल्डर में रखने या स्वयं-अद्यतन से स्थान हिलने पर खासकर।

flowchart TB
    accTitle: अद्यतन से exe पथ बदले तो नियम लक्ष्य खो देता है
    accDescr: प्रोग्राम निर्दिष्ट नियम पूर्ण पथ से बँधे हैं इसलिए इंस्टॉल स्थान बदले तो लक्ष्य खो देते हैं, सूचना हो तो संवाद फिर आता है नहीं तो चुपचाप ब्लॉक
    V1["v1.0 लागू<br/>नियम v1.0 फ़ोल्डर के exe की ओर"] --> UP["अद्यतन से v1.1 फ़ोल्डर में रखना<br/>चलने वाले exe का पथ बदलता है"]
    UP --> MISS["पुराने पथ का नियम लक्ष्य खो देता है<br/>(नियम है पर लगता नहीं)"]
    MISS --> Q{"इनबाउंड सूचना<br/>सक्षम है?"}
    Q -- "सक्षम" --> DLG["संवाद फिर आता है<br/>सामान्य उपयोगकर्ता छुए तो ब्लॉक नियम"]
    Q -- "अक्षम" --> SILENT["संवाद भी नहीं<br/>चुपचाप ब्लॉक"]
    MISS -.->|"उपाय"| FIX["पथ अद्यतन पार स्थिर रखें<br/>या अद्यतन प्रसंस्करण में पुराना नियम मिटाकर फिर पंजीकृत"]

चित्र 3: exe पथ अद्यतन से बदले तो पुराना नियम लक्ष्य खो देता है; पथ स्थिर रखें या अद्यतन पर फिर पंजीकृत करें।

उपाय सरल, इनमें से कोई:

• इंस्टॉल स्थान स्थिर रखें, exe पूर्ण पथ अद्यतन पार न बदले
• पथ बदलने वाले अद्यतन पर अपडेटर पुराना नियम मिटाकर नए पथ से फिर पंजीकृत करे (5.2/5.3 के आदेश अद्यतन प्रसंस्करण में भी चलाएँ)

MSI हो तो नियम पंजीकरण फ़ाइल रखने के बाद चलने वाली कस्टम क्रिया (अनइंस्टॉल पर मिटाने वाली कस्टम क्रिया) के रूप में बाँधना तयशुदा है। WiX जैसे उपकरण सेट में फ़ायरवॉल नियम घोषणात्मक लिखने का विस्तार भी है। वितरण तरीका चुनने से कार्यान्वयन स्थान बदलता है, इसलिए «Windows ऐप वितरण तरीका कैसे चुनें» भी देखें। ग्राहक परिनियोजन की एक और तयशुदा समस्या एंटीवायरस मिथ्या सकारात्मक «Microsoft Defender मिथ्या सकारात्मक» में।

6. समस्या निवारण — «संचार नहीं» पृथक्करण प्रवाह

पूछताछ मिलने की प्रक्रिया क्रम में बाँधें। पूरा प्रवाह:

flowchart TB
    accTitle: «संचार नहीं» का पृथक्करण
    accDescr: सर्वर का सुनना, क्लाइंट की पहुँच, प्रोफ़ाइल मेल, ActiveStore के नियम और लॉग का त्याग (DROP) क्रम से जाँचें
    S["«क्लाइंट से संचार नहीं»"] --> N["सर्वर पक्ष: netstat -ano"]
    N -- "नहीं सुन रहा" --> APP["फ़ायरवॉल से पहले की समस्या<br/>ऐप・सेवा पक्ष जाँचें"]
    N -- "LISTENING है" --> T["क्लाइंट पक्ष: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["पहुँच सामान्य<br/>ऐप परत (प्रमाणीकरण・प्रोटोकॉल) जाँचें"]
    T -- "False" --> P["सर्वर पक्ष: Get-NetConnectionProfile<br/>लागू प्रोफ़ाइल देखें"]
    P -- "नियम के लक्ष्य से मेल नहीं" --> FIXP["नियम की प्रोफ़ाइल निर्दिष्ट दोहराएँ"]
    P -- "मेल खाता है" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>अनुमति नियम उपस्थिति・ब्लॉक नियम मिलावट देखें"]
    R --> LOGCHK["pfirewall.log से त्याग (DROP) मापें"]

चित्र 4: netstat → Test-NetConnection → प्रोफ़ाइल → ActiveStore नियम → pfirewall.log का यांत्रिक पृथक्करण।

चरण 4 की पूरक। पोर्ट या प्रोग्राम शर्त नियम शरीर नहीं फ़िल्टर ऑब्जेक्ट पर हैं, इसलिए पोर्ट से नियम उलटा खोजने को फ़िल्टर से क्वेरी करें।⁵⁷

# पोर्ट 50051 से संबंधित नियम उलटा खोजें
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# नियम का स्रोत (स्थानीय या GPO) पीछा करें
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

चरण 5 का फ़ायरवॉल लॉग (pfirewall.log) डिफ़ॉल्ट कुछ नहीं लिखता। डिफ़ॉल्ट पथ %windir%\system32\logfiles\firewall\pfirewall.log, डिफ़ॉल्ट अधिकतम आकार 4,096KB; «त्यागे पैकेट लॉग करें» या «सफल कनेक्शन लॉग करें» सक्षम करने पर ही लिखा जाता है।⁶ अकेली मशीन पर निम्न से सक्षम: ⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

लॉग पाठ फ़ाइल है; त्याग (DROP) या अनुमति (ALLOW), प्रोटोकॉल, स्रोत/गंतव्य IP और पोर्ट एक पंक्ति; «क्लाइंट SYN आकर त्यागा गया या पहुँचा ही नहीं» यहीं तय होता है। नीति से लॉग कॉन्फ़िगर वातावरण में लॉग फ़ोल्डर लेखन अधिकार (सेवा mpssvc का FullControl) कमी से फ़ाइल न बने, तब फ़ोल्डर बनाना और ACL देना चाहिए।⁶

और गहराई: ऑडिट नीति «Filtering Platform Packet Drop» सक्षम करें तो हर त्याग पर सुरक्षा इवेंट 5152 दर्ज होता है। पर इवेंट मात्रा बहुत बड़ी है, Microsoft कनेक्शन इकाई पर दर्ज इवेंट 5157 (Filtering Platform Connection) अनुशंसा करता है। रोज़ नहीं, पृथक्करण की देर तक का उपकरण।⁹

अंत में न करने वाला पृथक्करण स्पष्ट। फ़ायरवॉल सेवा (MpsSvc) रोककर पूरा अक्षम असमर्थित है; स्टार्ट मेनू रुकना, स्टोर ऐप अद्यतन विफल जैसी OS समस्याएँ। अक्षम कर देखना हो तो सेवा चलाते Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False से प्रोफ़ाइल अक्षम करें, पुष्टि बाद तुरंत लौटाएँ।¹⁷ कारण फ़ायरवॉल तय हो तो उपाय अक्षम स्थायी नहीं सही नियम एक जोड़ना है।

7. संगठन प्रबंधन के नीचे — स्थानीय नियम न लगते वातावरण और आवेदन की रीति

इंस्टॉलर से नियम पंजीकृत करें तब भी न लगने वाले वातावरण हैं। GPO या Intune (CSP) से फ़ायरवॉल केंद्र प्रबंधित संगठन प्रोफ़ाइल-दर-प्रोफ़ाइल «स्थानीय नियम मर्ज» (AllowLocalPolicyMerge) अक्षम कर सकते हैं। अक्षम हो तो स्थानीय व्यवस्थापक (इंस्टॉलर सहित) बनाए नियम लागू नहीं, इनबाउंड कनेक्शन चाहने ऐप के नियम GPO/CSP से केंद्र वितरण अनिवार्य हो जाते हैं।²

flowchart TB
    accTitle: स्थानीय नियम मर्ज अक्षम हो तो इंस्टॉलर पंजीकरण नहीं लगता
    accDescr: AllowLocalPolicyMerge अक्षम वातावरण में स्थानीय नियम हों भी तो लागू नहीं होते, इसलिए GPO या CSP केंद्र वितरण पर जाएँ
    GPOR["GPO/Intune से वितरित नियम"] --> EFF["वास्तव में लगते नियमों का समुच्चय<br/>(ActiveStore)"]
    LOCAL["स्थानीय बनाए नियम<br/>(इंस्टॉलर पंजीकरण सहित)"] --> Q{"स्थानीय नियम मर्ज<br/>(AllowLocalPolicyMerge)"}
    Q -- "सक्षम (डिफ़ॉल्ट)" --> EFF
    Q -- "अक्षम" --> DROP["नियम है पर लागू नहीं<br/>→ GPO/CSP केंद्र वितरण पर जाएँ"]

चित्र 5: स्थानीय नियम मर्ज अक्षम हो तो इंस्टॉलर नियम लागू नहीं; GPO/CSP से केंद्र वितरण चाहिए।

विकास-लागू पक्ष की यथार्थ तैयारी:

• इंस्टॉलर नियम पंजीकरण «विफल न हो» डिज़ाइन (पंजीकरण स्वयं सफल होता है, त्रुटि से पकड़ नहीं सकते। लागू बाद संचार पुष्टि प्रक्रिया में रखें)
• अध्याय 6 चरण 4 (-TracePolicyStore) से लगते नियम का स्रोत स्थानीय या GPO देखें⁵
• स्थानीय नियम न लगते पता चले तो सूचना प्रणाली विभाग को नियम वितरण आवेदन पर जाएँ

आवेदन में निम्न जानकारी एक साथ दें। फ़ायरवॉल नियम दिशा, प्रोग्राम, पोर्ट, सीमा मिलकर ही बनता है; यही «व्यावसायिक ऐप का नेटवर्क विनिर्देश» बन जाता है।

सूचना प्रणाली पक्ष से भी यह तालिका वाले और बिना आवेदन में काम मात्रा बिल्कुल अलग है। उलटा, केवल पोर्ट संख्या «खोल दें» अध्याय 4 जैसा अति-अनुमति बन जाता है। डोमेन वातावरण की फ़ाइल साझा-प्रमाणीकरण संचार आवश्यकता फ़ायरवॉल से अलग कस (साइनिंग अनिवार्य आदि) से भी बदल रही है। साथ «SMB साइनिंग और LDAP चैनल बाइंडिंग» देखें।

8. सारांश

• Windows फ़ायरवॉल डिफ़ॉल्ट इनबाउंड ब्लॉक, आउटबाउंड अनुमति है। इनबाउंड नियम केवल सुनते सर्वर-प्रकार ऐप को चाहिए; क्लाइंट के रूप में जुड़ना मूलतः नहीं।
• नियम प्रोफ़ाइल (डोमेन/निजी/सार्वजनिक) इकाई पर लागू। «नियम है पर नहीं निकलता» का पहला संदिग्ध प्रोफ़ाइल मेल न खाना है।
• «महत्वपूर्ण चेतावनी» संवाद रद्द या बिना अधिकार उपयोगकर्ता क्रिया से ब्लॉक नियम बनाता है, आगे फिर नहीं आता। उत्पादन इस संवाद पर न छोड़ें।
• व्यावसायिक ऐप का इनबाउंड नियम इंस्टॉलर से पंजीकृत करें — यही एकमात्र सिद्धांत है। पंजीकरण व्यवस्थापक अधिकार से, मिटाने तक -Name स्थिर कर लागू करें।
• नियम प्रोग्राम + प्रोटोकॉल + पोर्ट धुरी, प्रोफ़ाइल और रिमोट IP से संकीर्ण। अद्यतन से exe पथ बदले तो नियम फिर पंजीकृत करना न भूलें।
• पृथक्करण netstat → Test-NetConnection → प्रोफ़ाइल → Get-NetFirewallRule (ActiveStore) → pfirewall.log क्रम से यांत्रिक। सेवा रोककर अक्षम असमर्थित है।
• GPO/Intune प्रबंधन में स्थानीय नियम मर्ज अक्षम हो सकता है। तब नियम नाम, दिशा, प्रोग्राम, पोर्ट, रिमोट IP, प्रोफ़ाइल मिलाकर सूचना प्रणाली से वितरण आवेदन करें।

संबंधित लेख

• Windows प्रोसेस-अंतर संचार कैसे चुनें — नामित पाइप / TCP / gRPC / साझा मेमोरी / COM निर्णय तालिका
• Windows ऐप वितरण तरीका कैसे चुनें - MSI/MSIX/ClickOnce/xcopy/निजी अद्यतन
• Windows पर व्यवस्थापक विशेषाधिकार वास्तव में कब चाहिए? - UAC, संरक्षित क्षेत्र, और डिज़ाइन से कैसे पहचानें
• स्वयं विकसित Windows ऐप वायरस माना जाए तो — Microsoft Defender मिथ्या सकारात्मक और प्रदर्शन प्रभाव
• SMB साइनिंग और LDAP चैनल बाइंडिंग — NTLM रक्षा का «बाकी आधा» व्यवहार में बंद करना
• Windows सेवा बनाना और संचालन — टास्क शेड्यूलर से चुनाव से BackgroundService को सेवा बनाना तक

संबंधित परामर्श क्षेत्र

KomuraSoft LLC सर्वर-प्रकार व्यावसायिक ऐप का इंस्टॉलर डिज़ाइन (फ़ायरवॉल नियम पंजीकरण-हटाना सहित), ग्राहक वातावरण में «संचार नहीं» की कारण जाँच, GPO प्रबंधन के नीचे परिनियोजन देखते नेटवर्क आवश्यकता व्यवस्थित करना सँभालता है। «विकास मशीन पर चलता है, ग्राहक पर नहीं» के पृथक्करण से शुरू करना ठीक है।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

केवल क्लाइंट के रूप में सर्वर से जुड़ने वाले ऐप को भी फ़ायरवॉल नियम चाहिए?

मूलतः नहीं। Windows फ़ायरवॉल का डिफ़ॉल्ट «इनबाउंड ब्लॉक, आउटबाउंड अनुमति» है, इसलिए स्वयं जुड़ने वाला क्लाइंट ऐप डिफ़ॉल्ट पर संचार कर सकता है। इनबाउंड नियम तब चाहिए जब पोर्ट खोलकर कनेक्शन की प्रतीक्षा हो — अर्थात सर्वर-प्रकार ऐप। दो अपवाद: उच्च-सुरक्षा वातावरण में आउटबाउंड भी डिफ़ॉल्ट ब्लॉक हो सकता है, तब आउटबाउंड नियम का आवेदन चाहिए। और क्लाइंट ऐप भी परिणाम सूचना के द्वार के रूप में स्वयं पोर्ट सुनता डिज़ाइन हो तो उस भाग को इनबाउंड नियम चाहिए।

«Windows सुरक्षा की महत्वपूर्ण चेतावनी» संवाद पर «पहुँच अनुमति दें» दबा देना काफी नहीं?

उस क्षण काफी लग सकता है, पर उत्पादन संचालन नहीं सौंपा जा सकता। यह संवाद व्यवस्थापक अधिकार वाले उपयोगकर्ता के रद्द करने पर ब्लॉक नियम बनाता है। व्यवस्थापक अधिकार न हो तो कोई भी बटन ब्लॉक नियम बनाता है। एक बार बना नियम मिटाए बिना संवाद फिर नहीं आता, संचार विफल रहता है। स्थल PC सामान्य उपयोगकर्ता चलाते व्यावसायिक ऐप में «किसी ने एक बार रद्द किया तो आगे हमेशा संचार नहीं» आसानी से बनता है। Microsoft भी ऐप के पहले स्टार्ट से पहले नियम रखने की अनुशंसा करता है।

इनबाउंड नियम पोर्ट निर्दिष्ट या प्रोग्राम निर्दिष्ट — कौन सा बनाएँ?

अकेले नहीं, मिलाना मूल है। प्रोग्राम निर्दिष्ट exe के पूर्ण पथ से लक्ष्य संकीर्ण करता है, पर अद्यतन से पथ बदले तो नियम लक्ष्य खो देता है (वाइल्डकार्ड नहीं)। पोर्ट निर्दिष्ट सूचना प्रणाली को आवेदन साफ करता है, पर उसी पोर्ट पर सुनता दूसरा प्रोसेस भी निकल जाता है। उत्पादन व्यावसायिक ऐप में «प्रोग्राम + प्रोटोकॉल + पोर्ट» धुरी, प्रोफ़ाइल डोमेन/निजी तक सीमित, रिमोट IP क्लाइंट सबनेट तक — यही न्यूनतम अधिकार का रूप है। पोर्ट गतिशील हो तभी प्रोग्राम निर्दिष्ट अकेला।

इंस्टॉलर का पंजीकृत नियम ग्राहक PC पर नहीं लग रहा। क्यों?

ग्राहक फ़ायरवॉल GPO या Intune से केंद्र में प्रबंधित हो और «स्थानीय नियम मर्ज» (AllowLocalPolicyMerge) अक्षम होने की संभावना ऊँची है। अक्षम हो तो स्थानीय बनाए नियम प्रोफ़ाइल पर दिखें भी लागू नहीं होते; नियम GPO/CSP से केंद्र वितरण ही बचता है। Get-NetFirewallRule -PolicyStore ActiveStore से प्रभावी नियमों का पूरा सेट देखें और सूचना प्रणाली विभाग से नियम वितरण का आवेदन करें। आवेदन में नियम नाम, दिशा, प्रोग्राम पथ, प्रोटोकॉल और पोर्ट, रिमोट IP सीमा, प्रोफ़ाइल एक साथ दें तो एक बार में निकलता है।

संचार पृथक्करण के लिए फ़ायरवॉल थोड़ी देर अक्षम कर सकते हैं?

सेवा (MpsSvc) रोककर अक्षम कभी न करें। Microsoft असमर्थित क्रिया है; स्टार्ट मेनू रुकना, स्टोर ऐप अद्यतन विफल जैसे OS पक्ष की समस्याएँ आती हैं। पृथक्करण में अक्षम करना हो तो सेवा चलाते Set-NetFirewallProfile -Enabled False से प्रोफ़ाइल अक्षम करना सही तरीका है। वह भी «कारण फ़ायरवॉल है या नहीं» कुछ मिनट में देखने तक सीमित रखें, पुष्टि होते तुरंत लौटाएँ। अक्षम रखकर चलाना एक नियम जोड़ने जितनी समस्या के बदले पूरे PC को निर्बल बनाना है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।