Windows Firewall और business apps — inbound rules installer से register करें

«Development machine पर बिना समस्या चलता है, ग्राहक पर डालते client server से नहीं जुड़ता।» «पहले start पर कोई warning आई, स्थल वाले ने Cancel कर दिया लगता है।» «netstat पर port सुन रहा है, पड़ोसी PC से नहीं पहुँचता।» — Business apps लागू करने के स्थल पर इस तरह «संचार नहीं» पूछताछ तयशुदा में तयशुदा है। और कारणों में सबसे ऊपर बैठा Windows Firewall (Windows Defender Firewall) है।

कठिनाई यह कि development machine पर समस्या दिखती नहीं। Development machine पर Visual Studio debug चलाते स्वयं अनुमति दी, या स्वयं admin थे, इसलिए default inbound block बिना देखे ship हो जाता है। ग्राहक पर चलाने वाला admin rights रहित सामान्य user है, network GPO से manage। «चलना चाहिए था नहीं चला» नहीं, «development machine संयोग से चल रही थी» वास्तविकता है।

यह लेख स्वयं develop किए app पर «ग्राहक पर संचार नहीं» झेलते business-app developers और वह पूछताछ लेने SMEs के IT कर्मियों के लिए है। Windows Firewall का default व्यवहार और profiles न्यूनतम पकड़कर inbound rule design, installer से registration, isolation प्रक्रिया, GPO/Intune management के नीचे सावधानियाँ — अगस्त 2026 तक के primary sources पर व्यवस्थित करता है।

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

• Windows Firewall का default «inbound block, outbound allow» है। Request का उत्तर न हो inbound traffic rule से न मिले तो त्यागा जाता है।¹
• Inbound rule केवल port सुनते server-type apps को चाहिए। स्वयं जुड़ने वाला client app default पर संचार कर सकता है। पहले यहीं isolate करें।¹
• Profiles तीन (Domain / Private / Public)। Domain domain controller पकड़ते अपने आप apply, Public unknown network का default। Rules profile इकाई पर enable-disable।¹
• उस «Windows Security Alert» dialog पर production न छोड़ें। Admin Cancel करे तो block rule बनता है; admin rights न हो तो कोई भी बटन block rule बनाता है। बना rule मिटाए बिना dialog फिर नहीं आता।²
• निष्कर्ष: «Business app का inbound rule installer से register करें»। Microsoft स्वयं पहले start से पहले rule रखने और inbound notifications disable करने की recommendation करता है।²
• Rules least privilege से design करें। Program + protocol + port धुरी, profile Domain/Private तक, remote IP आवश्यक subnet तक। Program path पर wildcard नहीं।²³
• Isolation Test-NetConnection → Get-NetFirewallRule → pfirewall.log क्रम है। Firewall log default नहीं लिखा जाता; त्यागे packets का record enable करने पर ही आता है।⁴⁵⁶
• Service रोककर पूरा disable करना unsupported है। GPO/Intune management में «local rule merge» disable हो सकता है, तब local rules नहीं लगते। Rule का केंद्र distribution IT से आवेदन करें।¹²

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 35, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. Default व्यवहार ठीक — inbound default block, outbound default allow

पहले नींव ठीक पकड़ें। Windows Firewall सब editions पर default enable host firewall है; default व्यवहार दो पंक्तियाँ हैं।¹

• Inbound: Request का उत्तर (solicited) हो या rule से match न खाए तो सब block
• Outbound: Rule से न मिले तो सब allow

इन दो पंक्तियों से business apps का सबसे महत्त्वपूर्ण isolation निकलता है। Inbound rule केवल «सुनने वाले पक्ष» को चाहिए।

• Internal web server, DB server, मुख्य प्रणाली से स्वयं जुड़ने वाला client app → मूलतः rule नहीं। Connection की वापसी packets «request का उत्तर» हैं, default निकलते हैं।
• TCP, gRPC, private protocol आदि से port खोलकर connection सुनने वाले server-type apps / Windows services → Inbound rule अनिवार्य।
• ध्यान: Remote से named pipes use अपवाद है। Remote named pipes app के अपने port नहीं, SMB (TCP 445) से जाते हैं, इसलिए चाहिए app का rule नहीं, file share (SMB) पक्ष का rule।
• अपवाद: Outbound default जान-बूझकर block किए high-security वातावरण। कुछ संगठनों में ही है; तब client app को भी outbound rule आवेदन चाहिए।²

flowchart TB
    accTitle: Inbound rule केवल सुनने वाले पक्ष को चाहिए
    accDescr: केवल client के रूप में जुड़ें तो inbound rule मूलतः नहीं चाहिए, port खोलकर सुनें तो installer से inbound rule register करें
    APP["स्वयं के app का संचार छाँटें"] --> Q{"Port खोलकर<br/>Connection सुनता है?"}
    Q -- "नहीं सुनता<br/>(केवल client के रूप में जुड़ता है)" --> C1["Inbound rule मूलतः नहीं<br/>Connection की वापसी «उत्तर» के रूप में निकलती है"]
    Q -- "सुनता है<br/>(Server-type・callback प्राप्ति)" --> S1["Inbound rule अनिवार्य<br/>→ Installer से registration (अध्याय 5)"]
    C1 -.-> EX["अपवाद: Outbound default block<br/>High-security वातावरण में outbound rule आवेदन"]

चित्र 1: Port सुनता हो तो inbound rule अनिवार्य; केवल client जुड़ाव मूलतः rule नहीं चाहता।

«Client समझा app वास्तव में सुनता भी है» मामला (result callback प्राप्ति, अन्य process से notification द्वार आदि) आसानी से छूटता है। स्वयं का app किस संचार तरीके से सुनता है अस्पष्ट हो तो design चरण की व्यवस्था «Process-inter communication कैसे चुनें» साथ देखें।

2.1. Profiles और «network location»

Rules network profile इकाई पर apply होते हैं। Profiles तीन हैं।¹

अभी कौन सी profile लागू है Get-NetConnectionProfile से देखें; Private/Public बदलना Set-NetConnectionProfile से।¹ स्थल की आम incident: ग्राहक workgroup वातावरण में network «Public» तय हो जाता है, Domain/Private सीमित बनाए inbound rules apply नहीं। «Rule है पर नहीं निकलता» हो तो rule की सामग्री से पहले profile match संदेह करें।

2.2. Rules की priority

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

1. स्पष्ट allow rule default block से प्राथमिक
2. स्पष्ट block rule टकराते allow rule से प्राथमिक
3. उपरोक्त 2 के विरुद्ध न जाते अधिक specific rule प्राथमिक

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

3. «Windows Security Alert» dialog की पहचान — न छोड़ने का कारण

App पहली बार port सुनना (listen) शुरू करे और उस app पर allow rule भी admin-defined rule न हो, तो Windows «This app’s some features are blocked by Windows Defender Firewall» वाला जाना-पहचाना «Windows Security Alert» dialog दिखाता है। व्यवहार spec साफ है।²

• Admin rights वाले user को दिखा: «Allow access» से allow rule बनता है। पर «Cancel» दबाने पर block rule बनता है। सामान्यतः TCP और UDP दो।
• Admin rights न हो: कोई option चुनें, block rule बनता है।
• दोनों में बना rule मिटाए बिना dialog फिर नहीं आता, संचार अवरुद्ध रहता है।

flowchart TB
    accTitle: «Windows Security Alert» dialog की शाखा
    accDescr: Rule न हो और inbound notification enable हो तो dialog आता है, Cancel या सामान्य user की क्रिया से block rule बनता है और फिर नहीं आता
    L["App port सुनना शुरू करता है"] --> Q1{"उस app से match खाता<br/>Rule है?"}
    Q1 -- "है" --> R1["Rule के अनुसार<br/>(Dialog नहीं आता)"]
    Q1 -- "नहीं" --> Q2{"Inbound notification<br/>Enable है?"}
    Q2 -- "Disable" --> R2["चुपचाप block<br/>(Rule नहीं बनता)"]
    Q2 -- "Enable" --> DLG["«Windows Security Alert» dialog"]
    DLG -- "Admin «Allow access»" --> OK["Allow rule बनता है"]
    DLG -- "Admin «Cancel»" --> NG1["Block rule बनता है"]
    DLG -- "Admin rights न user<br/>(कोई भी क्रिया)" --> NG2["Block rule बनता है"]
    NG1 --> NEVER["Rule मिटाए तक<br/>Dialog फिर नहीं आता"]
    NG2 --> NEVER

चित्र 2: Dialog Cancel या बिना rights user की क्रिया से block rule पका देता है; मिटाए बिना फिर नहीं आता।

अर्थात यह dialog «user से अनुमति माँगने का mechanism» लगता है, business apps के स्थल पर «सामान्य user छूते ही block rule पकाने का mechanism» बनकर काम करता है। लागू करने वाला admin account से पहला start कर dialog से अनुमति दे तो बना allow rule पूरे PC पर लगता है, अगले दिन से सामान्य user भी फिलहाल संचार कर सकते हैं। फिर भी incidents बचती हैं — लागू करते verification न छुआ सुनना सामान्य user पहले छुए, लागू network profile लागू करते से अलग हो, और update से exe path बदले (अध्याय 4, 5)।

Microsoft स्वयं admin के अलावा use वाले devices पर यह best practice स्पष्ट लिखता है।²

1. App के पहले start से पहले आवश्यक rules रखें (installer या management पक्ष distribution)
2. Inbound notifications disable करें (notifications काटें तो runtime अपने आप rule creation स्वयं नहीं होता)

Notifications disable Set-NetFirewallProfile -NotifyOnListen False या Group Policy से।⁷ «Dialog आए तो स्थल वाले से अनुमति दिलवाएँ» operations प्रक्रिया नहीं, incident का आरक्षण है। Inbound rules install पर register करें — यही इस लेख का निष्कर्ष है, Microsoft की recommendation से भी मेल खाता है।

4. Inbound rule design — program, port, service specified

Registered rule की सामग्री design करें। Specified तीन परिवार, अकेले या मिलाकर।

उस पर सीमा और चढ़ाएँ। Microsoft design recommendation भी «inbound rules जितना हो सके specific» है।²

• Profile सीमित: केवल internal use business apps के inbound rules Domain/Private तक, Public पर enable न करें। Notebook बाहरी Wi-Fi से जुड़ते ही सुनने वाला port दुनिया को खुल जाए — यह incident रोकता है।
• Remote IP सीमित: Source तय हो तो -RemoteAddress उस subnet तक। घर-छोटे network के लिए LocalSubnet keyword recommended।²³
• Direction और संख्या: सुनना केवल TCP हो तो TCP का एक rule काफी। Dialog अपने आप बनाए जैसे TCP/UDP दोनों आलस से न बनाएँ।

«आवश्यक पक्ष से, आवश्यक port पर, आवश्यक program ही» — inbound rule design इसी least privilege के एक वाक्य में समाता है।

5. Installer से registration — netsh और New-NetFirewallRule

5.1. पूर्वापेक्षा: Admin rights चाहिए

Firewall rules जोड़ना-हटाना पूरे computer की settings बदलना है, इसलिए admin rights (elevated process) से चलाना होगा।⁸ Installer सामान्यतः admin rights से चलता है, इसलिए rule registration install processing में रखना तर्कसंगत है। App स्वयं को admin से चलाने का कारण नहीं बनता। यह रेखा «Admin rights कब चाहिए» में विस्तार से है।

5.2. netsh advfirewall से registration

Classic पर किसी भी installer से बुलाना आसान netsh advfirewall firewall add rule है।⁸

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

rem Program-specified+port-specified+profile सीमित inbound allow rule
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 Uninstall पर: नाम से मिटाएँ
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

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

5.3. PowerShell (New-NetFirewallRule) से registration

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

# Registration (installer से elevated अवस्था में)। -Name unique identifier है,
# Reinstall・repair・update पर पुनः चलाने से समान नाम बनाना
# Error देता है। मौजूदा समान नाम मिटाकर बनाना से 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

# Uninstall पर: न हो तो भी error न दें
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

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

5.4. Update से exe path बदले

Program-specified rule पूर्ण path से लक्ष्य बाँधता है। अर्थात update से install location या exe नाम बदले तो rule बचा रहता है पर लक्ष्य खो देता है, सुनना फिर block होता है। तब नए path का exe «rule रहित app» माना जाता है; notifications enable वातावरण में अध्याय 3 का dialog फिर आता है, सामान्य user छुए तो block rule पकता है। अध्याय 3 की recommendation अनुसार notifications disable वातावरण में dialog भी बिना चुपचाप विफल। Version संख्या वाले फ़ोल्डर में रखने या self-update से स्थान हिलने पर खासकर।

flowchart TB
    accTitle: Update से exe path बदले तो rule लक्ष्य खो देता है
    accDescr: Program-specified rules पूर्ण path से बँधे हैं इसलिए install location बदले तो लक्ष्य खो देते हैं, notification हो तो dialog फिर आता है नहीं तो चुपचाप block
    V1["v1.0 लागू<br/>Rule v1.0 फ़ोल्डर के exe की ओर"] --> UP["Update से v1.1 फ़ोल्डर में रखना<br/>चलने वाले exe का path बदलता है"]
    UP --> MISS["पुराने path का rule लक्ष्य खो देता है<br/>(Rule है पर लगता नहीं)"]
    MISS --> Q{"Inbound notification<br/>Enable है?"}
    Q -- "Enable" --> DLG["Dialog फिर आता है<br/>सामान्य user छुए तो block rule"]
    Q -- "Disable" --> SILENT["Dialog भी नहीं<br/>चुपचाप block"]
    MISS -.->|"उपाय"| FIX["Path update पार स्थिर रखें<br/>या update processing में पुराना rule मिटाकर फिर register"]

चित्र 3: exe path update से बदले तो पुराना rule लक्ष्य खो देता है; path स्थिर रखें या update पर फिर register करें।

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

• Install location स्थिर रखें, exe पूर्ण path update पार न बदले
• Path बदलने वाले updates पर updater पुराना rule मिटाकर नए path से फिर register करे (5.2/5.3 के commands update processing में भी चलाएँ)

MSI हो तो rule registration फ़ाइल रखने के बाद चलने वाली custom action (uninstall पर मिटाने वाली custom action) के रूप में बाँधना तयशुदा है। WiX जैसे tools सेट में firewall rules घोषणात्मक लिखने का विस्तार भी है। Distribution तरीका चुनने से implementation स्थान बदलता है, इसलिए «Windows app deployment तरीका कैसे चुनें» भी देखें। ग्राहक deployment की एक और तयशुदा समस्या antivirus false positive «Microsoft Defender false positives» में।

6. Troubleshooting — «संचार नहीं» isolation flow

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

flowchart TB
    accTitle: «संचार नहीं» का isolation
    accDescr: Server का सुनना, client की पहुँच, profile match, ActiveStore के rules और log का त्याग (DROP) क्रम से जाँचें
    S["«Client से संचार नहीं»"] --> N["Server पक्ष: netstat -ano"]
    N -- "नहीं सुन रहा" --> APP["Firewall से पहले की समस्या<br/>App・service पक्ष जाँचें"]
    N -- "LISTENING है" --> T["Client पक्ष: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["पहुँच सामान्य<br/>App परत (authentication・protocol) जाँचें"]
    T -- "False" --> P["Server पक्ष: Get-NetConnectionProfile<br/>लागू profile देखें"]
    P -- "Rule के लक्ष्य से match नहीं" --> FIXP["Rule की profile निर्दिष्ट दोहराएँ"]
    P -- "मेल खाता है" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>Allow rule उपस्थिति・block rule मिलावट देखें"]
    R --> LOGCHK["pfirewall.log से त्याग (DROP) मापें"]

चित्र 4: netstat → Test-NetConnection → profile → ActiveStore rules → pfirewall.log का यांत्रिक isolation।

चरण 4 की पूरक। Port या program शर्त rule शरीर नहीं filter object पर हैं, इसलिए port से rule उलटा खोजने को filter से query करें।⁵⁷

# Port 50051 से संबंधित rules उलटा खोजें
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# Rule का source (local या GPO) पीछा करें
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

चरण 5 का firewall log (pfirewall.log) default कुछ नहीं लिखता। Default path %windir%\system32\logfiles\firewall\pfirewall.log, default अधिकतम आकार 4,096KB; «Dropped packets log करें» या «Successful connections log करें» enable करने पर ही लिखा जाता है।⁶ अकेली मशीन पर निम्न से enable: ⁶

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

Log text फ़ाइल है; त्याग (DROP) या allow (ALLOW), protocol, source/destination IP और port एक पंक्ति; «client SYN आकर त्यागा गया या पहुँचा ही नहीं» यहीं तय होता है। Policy से log configure वातावरण में log फ़ोल्डर write rights (service mpssvc का FullControl) कमी से फ़ाइल न बने, तब फ़ोल्डर बनाना और ACL देना चाहिए।⁶

और गहराई: Audit policy «Filtering Platform Packet Drop» enable करें तो हर त्याग पर security event 5152 दर्ज होता है। पर event मात्रा बहुत बड़ी है, Microsoft connection इकाई पर दर्ज event 5157 (Filtering Platform Connection) recommend करता है। रोज़ नहीं, isolation की देर तक का उपकरण।⁹

अंत में न करने वाला isolation स्पष्ट। Firewall service (MpsSvc) रोककर पूरा disable unsupported है; Start menu रुकना, Store apps update विफल जैसी OS समस्याएँ। Disable कर देखना हो तो service चलाते Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False से profile disable करें, पुष्टि बाद तुरंत लौटाएँ।¹⁷ कारण firewall तय हो तो उपाय disable स्थायी नहीं सही rule एक जोड़ना है।

7. संगठन management के नीचे — local rules न लगते वातावरण और आवेदन की रीति

Installer से rule register करें तब भी न लगने वाले वातावरण हैं। GPO या Intune (CSP) से firewall केंद्र manage संगठन profile-दर-profile «local rule merge» (AllowLocalPolicyMerge) disable कर सकते हैं। Disable हो तो local admin (installer सहित) बनाए rules apply नहीं, inbound connections चाहने apps के rules GPO/CSP से केंद्र distribution अनिवार्य हो जाते हैं।²

flowchart TB
    accTitle: Local rule merge disable हो तो installer registration नहीं लगता
    accDescr: AllowLocalPolicyMerge disable वातावरण में local rules हों भी तो apply नहीं होते, इसलिए GPO या CSP केंद्र distribution पर जाएँ
    GPOR["GPO/Intune से distributed rules"] --> EFF["वास्तव में लगते rules का समुच्चय<br/>(ActiveStore)"]
    LOCAL["Locally बनाए rules<br/>(Installer registration सहित)"] --> Q{"Local rule merge<br/>(AllowLocalPolicyMerge)"}
    Q -- "Enable (default)" --> EFF
    Q -- "Disable" --> DROP["Rule है पर apply नहीं<br/>→ GPO/CSP केंद्र distribution पर जाएँ"]

चित्र 5: Local rule merge disable हो तो installer rules apply नहीं; GPO/CSP से केंद्र distribution चाहिए।

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

• Installer rule registration «विफल न हो» design (registration स्वयं सफल होता है, error से पकड़ नहीं सकते। Apply बाद संचार पुष्टि प्रक्रिया में रखें)
• अध्याय 6 चरण 4 (-TracePolicyStore) से लगते rule का source local या GPO देखें⁵
• Local rules न लगते पता चले तो IT department को rule distribution आवेदन पर जाएँ

आवेदन में निम्न जानकारी एक साथ दें। Firewall rule direction, program, port, सीमा मिलकर ही बनता है; यही «business app का network spec» बन जाता है।

IT पक्ष से भी यह तालिका वाले और बिना आवेदन में काम मात्रा बिल्कुल अलग है। उलटा, केवल port संख्या «खोल दें» अध्याय 4 जैसा over-permission बन जाता है। Domain वातावरण की file share-authentication संचार आवश्यकता firewall से अलग कस (signing अनिवार्य आदि) से भी बदल रही है। साथ «SMB signing और LDAP channel binding» देखें।

8. सारांश

• Windows Firewall default inbound block, outbound allow है। Inbound rule केवल सुनते server-type apps को चाहिए; client के रूप में जुड़ना मूलतः नहीं।
• Rules profile (Domain/Private/Public) इकाई पर apply। «Rule है पर नहीं निकलता» का पहला संदिग्ध profile match न खाना है।
• «Windows Security Alert» dialog Cancel या बिना rights user क्रिया से block rule बनाता है, आगे फिर नहीं आता। Production इस dialog पर न छोड़ें।
• Business app का inbound rule installer से register करें — यही एकमात्र सिद्धांत है। Registration admin rights से, मिटाने तक -Name स्थिर कर लागू करें।
• Rules program + protocol + port धुरी, profile और remote IP से संकीर्ण। Update से exe path बदले तो rule फिर register करना न भूलें।
• Isolation netstat → Test-NetConnection → profile → Get-NetFirewallRule (ActiveStore) → pfirewall.log क्रम से यांत्रिक। Service रोककर disable unsupported है।
• GPO/Intune management में local rule merge disable हो सकता है। तब rule नाम, direction, program, port, remote IP, profile मिलाकर IT से distribution आवेदन करें।

संबंधित लेख

• Windows process-inter communication कैसे चुनें — named pipes / TCP / gRPC / shared memory / COM decision table
• Windows app deployment तरीका कैसे चुनें - MSI/MSIX/ClickOnce/xcopy/private update
• Windows पर admin privileges वास्तव में कब चाहिए? - UAC, protected areas, और design से कैसे पहचानें
• स्वयं develop किए Windows app को virus माना जाए तो — Microsoft Defender false positives और performance प्रभाव
• SMB signing और LDAP channel binding — NTLM रक्षा का «बाकी आधा» व्यवहार में बंद करना
• Windows service बनाना और operations — Task Scheduler से चुनाव से BackgroundService को service बनाना तक

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

KomuraSoft LLC server-type business apps का installer design (firewall rule registration-हटाना सहित), ग्राहक वातावरण में «संचार नहीं» की कारण जाँच, GPO management के नीचे deployment देखते network आवश्यकता व्यवस्थित करना सँभालता है। «Development machine पर चलता है, ग्राहक पर नहीं» के isolation से शुरू करना ठीक है।

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

केवल client के रूप में server से जुड़ने वाले app को भी firewall rule चाहिए?

मूलतः नहीं। Windows Firewall का default «inbound block, outbound allow» है, इसलिए स्वयं जुड़ने वाला client app default पर संचार कर सकता है। Inbound rule तब चाहिए जब port खोलकर connection की प्रतीक्षा हो — अर्थात server-type app। दो अपवाद: high-security वातावरण में outbound भी default block हो सकता है, तब outbound rule का आवेदन चाहिए। और client app भी result notification के द्वार के रूप में स्वयं port सुनता design हो तो उस भाग को inbound rule चाहिए।

«Windows Security Alert» dialog पर «Allow access» दबा देना काफी नहीं?

उस क्षण काफी लग सकता है, पर production operations नहीं सौंपा जा सकता। यह dialog admin rights वाले user के Cancel करने पर block rule बनाता है। Admin rights न हो तो कोई भी बटन block rule बनाता है। एक बार बना rule मिटाए बिना dialog फिर नहीं आता, संचार विफल रहता है। स्थल PC सामान्य user चलाते business apps में «किसी ने एक बार Cancel किया तो आगे हमेशा संचार नहीं» आसानी से बनता है। Microsoft भी app के पहले start से पहले rule रखने की recommendation करता है।

Inbound rule port-specified या program-specified — कौन सा बनाएँ?

अकेले नहीं, मिलाना मूल है। Program-specified exe के पूर्ण path से लक्ष्य संकीर्ण करता है, पर update से path बदले तो rule लक्ष्य खो देता है (wildcard नहीं)। Port-specified IT को आवेदन साफ करता है, पर उसी port पर सुनता दूसरा process भी निकल जाता है। Production business apps में «program + protocol + port» धुरी, profile Domain/Private तक सीमित, remote IP client subnet तक — यही least privilege का रूप है। Port dynamic हो तभी program-specified अकेला।

Installer का registered rule ग्राहक PC पर नहीं लग रहा। क्यों?

ग्राहक firewall GPO या Intune से केंद्र में manage हो और «local rule merge» (AllowLocalPolicyMerge) disable होने की संभावना ऊँची है। Disable हो तो locally बनाए rules profile पर दिखें भी apply नहीं होते; rules GPO/CSP से केंद्र distribution ही बचता है। Get-NetFirewallRule -PolicyStore ActiveStore से प्रभावी rules का पूरा सेट देखें और IT department से rule distribution का आवेदन करें। आवेदन में rule नाम, direction, program path, protocol और port, remote IP सीमा, profile एक साथ दें तो एक बार में निकलता है।

संचार isolate करने के लिए firewall थोड़ी देर disable कर सकते हैं?

Service (MpsSvc) रोककर disable कभी न करें। Microsoft unsupported क्रिया है; Start menu रुकना, Store apps update विफल जैसे OS पक्ष की समस्याएँ आती हैं। Isolation में disable करना हो तो service चलाते Set-NetFirewallProfile -Enabled False से profile disable करना सही तरीका है। वह भी «कारण firewall है या नहीं» कुछ मिनट में देखने तक सीमित रखें, पुष्टि होते तुरंत लौटाएँ। Disable रखकर चलाना एक rule जोड़ने जितनी समस्या के बदले पूरे PC को निर्बल बनाना है।

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

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

Go Komura

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

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