ไฟร์วอลล์ Windows กับแอปธุรกิจ — ลงทะเบียนกฎขาเข้าจากตัวติดตั้ง

«บนเครื่องพัฒนาทำงานไม่มีปัญหา พอใส่ที่ลูกค้าแล้วลูกข่ายเชื่อมเซิร์ฟเวอร์ไม่ได้» «ตอนเริ่มครั้งแรกมีคำเตือนอะไรสักอย่าง คนที่สนามยกเลิกไปแล้ว» «netstat เห็นพอร์ตรอรับอยู่ แต่จากพีซีข้าง ๆ ไปไม่ถึง» ── ในงานนำเข้าแอปธุรกิจ คำถาม «สื่อสารไม่ได้» ชนิดนี้เป็นของประจำในของประจำ และสิ่งที่ยังนั่งอยู่ในอันดับต้นของสาเหตุคือ ไฟร์วอลล์ 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 Firewall"]
    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["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): อนุญาตทั้งหมด เว้นแต่ตรงกฎ

จากสองบรรทัดนี้ได้การแยกที่สำคัญที่สุดสำหรับแอปธุรกิจ กฎขาเข้าจำเป็นเฉพาะ «ฝั่งที่รอรับ»

• แอปลูกข่ายที่ออกไปเชื่อมเซิร์ฟเวอร์เว็บ เซิร์ฟเวอร์ฐานข้อมูล หรือระบบหลักในองค์กรเอง → โดยหลัก ไม่ต้องมีกฎ แพ็กเก็ตกลับของการเชื่อมเป็น «คำตอบต่อคำขอ» จึงผ่านตามค่าเริ่มต้น
• แอปแบบเซิร์ฟเวอร์หรือบริการ Windows ที่ เปิดพอร์ตรอรับการเชื่อมต่อ ด้วย TCP, gRPC หรือโปรโตคอลของตนเอง → ต้องมีกฎขาเข้า
• โครงที่ใช้ named pipe จากระยะไกลเป็นข้อยกเว้น Named pipe ระยะไกลไม่ใช่พอร์ตของแอปเอง แต่ ผ่าน 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. ในขอบเขตที่ไม่ขัดสองข้อบน กฎที่ เฉพาะเจาะจง กว่ามาก่อน

นัยในงานปฏิบัติคือ «ถ้ามีกฎบล็อกหนึ่งเส้นที่ไหนก็ตาม ต่อให้เติมกฎอนุญาตทีหลังเท่าไรก็ชนะไม่ได้» ดังที่จะเห็นในหมวดถัดไป ไดอะล็อกนั้นสร้างกฎบล็อกนี้อย่างเงียบ ๆ

3. ตัวจริงของไดอะล็อก «คำเตือนสำคัญ» — เหตุผลที่ห้ามปล่อย

เมื่อแอปเริ่มรอรับพอร์ต (listen) ครั้งแรก หากยังไม่มีทั้งกฎอนุญาตสำหรับแอปนั้นและกฎที่ผู้ดูแลนิยาม Windows จะแสดง ไดอะล็อก «คำเตือนสำคัญของ Windows Security» ที่คุ้นตาว่า «บางฟังก์ชันของแอปนี้ถูกบล็อกด้วยไฟร์วอลล์ Windows Defender» สเปกการทำงานชัด²

• เมื่อแสดงต่อ ผู้ใช้ที่มีสิทธิ์ผู้ดูแล: «อนุญาตการเข้าถึง» สร้างกฎอนุญาต แต่ ถ้ากด «ยกเลิก» จะถูกสร้างกฎบล็อก โดยปกติสองเส้นสำหรับ 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: การกดยกเลิกไดอะล็อกหรือการกระทำของผู้ใช้ทั่วไปเผากฎบล็อก และจนกว่าจะลบ ไดอะล็อกจะไม่ออกอีก.

กล่าวคือไดอะล็อกนี้ดูเหมือน «กลไกขออนุญาตจากผู้ใช้» แต่ในสนามแอปธุรกิจทำงานในฐานะ «กลไกที่เผากฎบล็อกทันทีที่ผู้ใช้ทั่วไปแตะ» หากผู้รับผิดชอบนำเข้าเริ่มครั้งแรกด้วยบัญชีผู้ดูแลแล้วอนุญาตในไดอะล็อก กฎอนุญาตที่ถูกสร้างมีผลทั้งพีซี ดังนั้นผู้ใช้ทั่วไปตั้งแต่วันถัดไปสื่อสารได้ชั่วคราว อุบัติเหตุยังเหลือ ── เมื่อผู้ใช้ทั่วไปเหยียบการรอรับที่การตรวจตอนนำเข้าไม่เหยียบ เมื่อโปรไฟล์เครือข่ายที่ใช้ต่างจากตอนนำเข้า และเมื่อพาธ 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 เป็นตัวระบุไม่ซ้ำ
# การรันซ้ำตอนติดตั้งใหม่ ซ่อม หรืออัปเดตจะผิดถ้าสร้างกฎชื่อเดียวกัน
# ทำให้เป็นอุดมคติด้วยการลบกฎชื่อเดียวกันที่มีอยู่แล้วสร้างใหม่
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 ขาเข้า)" `
    -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/>กฎชี้ exe ในโฟลเดอร์ v1.0"] --> 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 หลักคือฝังการลงทะเบียนกฎเป็น custom action ที่รันหลังวางไฟล์ (ตอนถอนคือ custom action ฝั่งลบ) ชุดเครื่องมืออย่าง 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["วัดการทิ้ง (DROP) จริงด้วย pfirewall.log"]

ภาพ 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

บันทึกไฟร์วอลล์ (pfirewall.log) ในขั้นตอน 5 ไม่บันทึกอะไรตามค่าเริ่มต้น พาธค่าเริ่มต้นคือ %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 จากลูกข่ายถึงแล้วถูกทิ้ง หรือยังไม่ถึงตั้งแต่ต้น» ในสภาพแวดล้อมที่กำหนดบันทึกด้วยนโยบาย อาจไม่มีสิทธิ์เขียนไปโฟลเดอร์บันทึก (FullControl ของบริการ mpssvc) จนไฟล์ไม่ถูกสร้าง ซึ่งกรณีนั้นต้องสร้างโฟลเดอร์และให้ ACL⁶

หากขุดลึกกว่านั้น การเปิดนโยบายการตรวจสอบ «การทิ้งแพ็กเก็ตของแพลตฟอร์มกรอง» จะบันทึกเหตุการณ์ความปลอดภัย 5152 ทุกครั้งที่ทิ้ง แต่ปริมาณเหตุการณ์สูงมาก Microsoft จึงแนะนำให้ใช้เหตุการณ์ 5157 (การเชื่อมของแพลตฟอร์มกรอง) ที่บันทึกทีละการเชื่อม ไม่ใช่ของใช้ประจำ แต่เป็นเครื่องมือที่เปิดเฉพาะช่วงแยก⁹

สุดท้าย ทำให้ชัดว่าการแยกที่ห้ามทำ การปิดทั้งก้อนด้วยการหยุดบริการไฟร์วอลล์ (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.

เครื่องเตรียมที่เป็นจริงฝั่งพัฒนาและนำเข้ามีดังนี้

• ออกแบบการลงทะเบียนกฎของตัวติดตั้งให้ «ไม่ล้ม» (ตัวการลงทะเบียนสำเร็จ จึงจับด้วยข้อผิดพลาดไม่ได้ ให้รวมการยืนยันการสื่อสารหลังนำเข้าในขั้นตอน)
• ตรวจด้วยขั้นตอน 4 ของหมวด 6 (-TracePolicyStore) ว่าแหล่งที่มาของกฎที่ใช้เป็นท้องถิ่นหรือ GPO⁵
• เมื่อรู้ว่ากฎท้องถิ่นไม่ทำงาน ให้สลับเป็น คำขอให้แจกกฎ ไปฝ่ายสารสนเทศ

คำขอให้ส่งข้อมูลต่อไปนี้ครบชุด กฎไฟร์วอลล์สร้างได้เมื่อทิศทาง โปรแกรม พอร์ต และขอบเขตครบ ดังนั้นนี่กลายเป็น «เอกสารสเปกเครือข่ายของแอปธุรกิจ» ตามตัว

จากมุมฝ่ายสารสนเทศ ปริมาณงานของคำขอที่มีตารางนี้กับที่ไม่มีต่างกันสิ้นเชิง ในทางกลับกัน «ช่วยเปิด» แค่หมายเลขพอร์ต มักกลายเป็นการอนุญาตเกินดังที่เห็นในหมวด 4 ข้อกำหนดการสื่อสารรอบการแชร์ไฟล์และการรับรองในสภาพแวดล้อมโดเมนก็เปลี่ยนด้วยการรัดอีกแบบแยกจากไฟร์วอลล์ (เช่น การบังคับลายเซ็น) ให้ดู «ลายเซ็น SMB และ LDAP channel binding» คู่กัน

8. สรุป

• ค่าเริ่มต้นของไฟร์วอลล์ Windows คือบล็อกขาเข้า อนุญาตขาออก กฎขาเข้าจำเป็นเฉพาะแอปแบบเซิร์ฟเวอร์ที่รอรับ และถ้าเชื่อมในฐานะลูกข่ายอย่างเดียวโดยหลักไม่ต้องมี
• กฎถูกใช้ทีละโปรไฟล์ (โดเมน/ส่วนตัว/สาธารณะ) ผู้ต้องสงสัยอันดับแรกของ «มีกฎแต่ไม่ผ่าน» คือโปรไฟล์ไม่ตรง
• ไดอะล็อก «คำเตือนสำคัญ» สร้างกฎบล็อกเมื่อยกเลิกหรือเมื่อผู้ใช้ที่ไม่มีสิทธิ์ใช้งาน แล้วไม่แสดงอีก ห้ามปล่อยงานจริงให้ไดอะล็อกนี้
• กฎขาเข้าของแอปธุรกิจลงทะเบียนด้วยตัวติดตั้ง ── นี่คือหลักเดียว การลงทะเบียนทำด้วยสิทธิ์ผู้ดูแล และอิมพลีเมนต์รวมการลบโดยตรึง -Name
• กฎจำกัดด้วยโปรไฟล์และ IP ระยะไกล โดยแกนคือโปรแกรม+โปรโตคอล+พอร์ต หากพาธ exe เปลี่ยนตอนอัปเดต อย่าลืมลงทะเบียนกฎใหม่
• การแยกทำแบบเครื่องกลตามลำดับ netstat → Test-NetConnection → ตรวจโปรไฟล์ → Get-NetFirewallRule (ActiveStore) → pfirewall.log การปิดด้วยการหยุดบริการอยู่นอกขอบเขตการสนับสนุน
• ภายใต้การจัดการ GPO/Intune การรวมกฎท้องถิ่นอาจถูกปิด ตอนนั้นให้ขอฝ่ายสารสนเทศให้แจกโดยครบชื่อกฎ ทิศทาง โปรแกรม พอร์ต IP ระยะไกล และโปรไฟล์

บทความที่เกี่ยวข้อง

• จะเลือกการสื่อสารระหว่างโพรเซสบน Windows อย่างไร — ตารางตัดสิน named pipe / TCP / gRPC / หน่วยความจำร่วม / COM
• วิธีเลือกวิธีแจกแอป Windows — MSI/MSIX/ClickOnce/xcopy/ตัวอัปเดตของตนเอง
• เมื่อใดที่จริง ๆ แล้วต้องใช้สิทธิ์ผู้ดูแลบน Windows — UAC พื้นที่ที่ถูกป้องกัน และวิธีดูตั้งแต่ขั้นออกแบบ
• เมื่อแอป Windows ที่พัฒนาเองถูกปฏิบัติเป็นไวรัส — การรับมือการตรวจจับผิดของ Microsoft Defender และการอยู่กับผลกระทบต่อประสิทธิภาพ
• ลายเซ็น SMB และ LDAP channel binding — ปิด «อีกครึ่ง» ของการป้องกัน NTLM ในทางปฏิบัติ
• วิธีสร้างและดำเนินงานบริการ Windows — จากการเลือกระหว่างตัวจัดตารางงาน ถึงการทำให้ BackgroundService เป็นบริการ

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับออกแบบตัวติดตั้งของแอปธุรกิจแบบเซิร์ฟเวอร์ (รวมการลงทะเบียนและลบกฎไฟร์วอลล์) การสอบสวนสาเหตุ «สื่อสารไม่ได้» ในสภาพแวดล้อมลูกค้า และการจัดข้อกำหนดเครือข่ายที่มองการกางภายใต้การจัดการ GPO เริ่มจากการแยก «บนเครื่องพัฒนาทำงาน แต่ที่ลูกค้าไม่ทำงาน» ก็ได้

• พัฒนาแอป Windows
• ตรวจสอบบั๊กและหาสาเหตุ
• ที่ปรึกษาเทคนิคและรีวิวการออกแบบ
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

แอปที่เป็นแค่ลูกข่ายเชื่อมไปเซิร์ฟเวอร์ ยังต้องมีกฎไฟร์วอลล์ไหม?

โดยหลักไม่ต้อง ค่าเริ่มต้นของไฟร์วอลล์ Windows คือ «ขาเข้าบล็อก ขาออกอนุญาต» ดังนั้นแอปลูกข่ายที่ออกไปเชื่อมเองสื่อสารได้ตามค่าเริ่มต้น กฎขาเข้าจำเป็นเฉพาะฝั่งที่เปิดพอร์ตรอรับการเชื่อมต่อ คือแอปแบบเซิร์ฟเวอร์ แต่มีข้อยกเว้นสองอย่าง ในสภาพแวดล้อมความปลอดภัยสูง ขาออกอาจถูกเปลี่ยนเป็นบล็อกตามค่าเริ่มต้น ซึ่งกรณีนั้นต้องขอกฎขาออก และถ้าแอปลูกข่ายถูกออกแบบให้รอรับพอร์ตเองเป็นปากรับการแจ้งผล ส่วนนั้นต้องมีกฎขาเข้า

กด «อนุญาตการเข้าถึง» ในไดอะล็อก «คำเตือนสำคัญของ Windows Security» แล้วจบไหม?

จบในที่นั้นได้ แต่ปล่อยให้งานจริงไม่ได้ ไดอะล็อกนี้เมื่อผู้ใช้ที่มีสิทธิ์ผู้ดูแลกดยกเลิก จะถูกสร้างกฎบล็อก และถ้าเป็นผู้ใช้ที่ไม่มีสิทธิ์ผู้ดูแล ไม่ว่ากดปุ่มใดก็ถูกสร้างกฎบล็อก จนกว่าจะลบกฎที่ถูกสร้าง ไดอะล็อกจะไม่แสดงอีก และการสื่อสารล้มต่อไป ในแอปธุรกิจที่พีซีสนามถูกใช้งานโดยผู้ใช้ทั่วไป สถานะ «ใครสักคนยกเลิกครั้งเดียว แล้วสื่อสารไม่ได้ตลอด» เกิดง่าย Microsoft เองก็แนะนำให้วางกฎก่อนการเริ่มครั้งแรกของแอป

กฎขาเข้าควรสร้างแบบระบุพอร์ตหรือระบุโปรแกรม?

หลักคือไม่ใช้เดี่ยว แต่รวมกัน การระบุโปรแกรมจำกัดเป้าหมายด้วยพาธเต็มของ exe ได้ ในทางกลับกัน ถ้าพาธเปลี่ยนตอนอัปเดต กฎจะหลุดเป้า (ใช้ไวด์การ์ดไม่ได้) การระบุพอร์ตทำให้คำขอไปฝ่ายสารสนเทศชัด แต่ก็ปล่อยโพรเซสอื่นที่รอรับพอร์ตเดียวกันผ่านด้วย ในแอปธุรกิจงานจริง แกนคือ «โปรแกรม+โปรโตคอล+พอร์ต» จำกัดโปรไฟล์เหลือโดเมน/ส่วนตัว และจำกัด IP ระยะไกลเหลือซับเน็ตที่ลูกข่ายอยู่ นี่คือแบบสิทธิ์น้อยสุด ใช้ระบุโปรแกรมเดี่ยวเฉพาะเมื่อพอร์ตเป็นแบบพลวัต

กฎที่ตัวติดตั้งลงทะเบียนดูเหมือนไม่ทำงานบนพีซีลูกค้า ทำไม?

มีโอกาสสูงที่ไฟร์วอลล์ฝั่งลูกค้าถูกจัดการรวมศูนย์ด้วย GPO หรือ Intune และ «การรวมกฎท้องถิ่น» (AllowLocalPolicyMerge) ถูกปิด หากค่านี้ปิด กฎที่สร้างท้องถิ่นมีอยู่บนโปรไฟล์แต่ไม่ถูกใช้ และกฎต้องแจกรวมศูนย์ฝั่ง GPO/CSP ตรวจชุดกฎที่ใช้จริงด้วย Get-NetFirewallRule -PolicyStore ActiveStore แล้วขอฝ่ายสารสนเทศให้แจกกฎ คำขอให้ครบทั้งชื่อกฎ ทิศทาง พาธโปรแกรม โปรโตคอลกับพอร์ต ช่วง IP ระยะไกล และโปรไฟล์ จะผ่านครั้งเดียว

ปิดไฟร์วอลล์ชั่วคราวเพื่อแยกการสื่อสารได้ไหม?

ห้ามปิดด้วยการหยุดบริการ (MpsSvc) โดยเด็ดขาด เป็นการกระทำนอกขอบเขตการสนับสนุนของ Microsoft และก่อปัญหาฝั่ง OS เช่น เมนูเริ่มไม่ทำงาน การอัปเดตแอปสโตร์ล้ม หากจำเป็นต้องปิดเพื่อแยก วิธีที่ถูกคือปล่อยบริการทำงานแล้วปิดโปรไฟล์ด้วย Set-NetFirewallProfile -Enabled False แต่จำกัดไว้แค่ใช้ไม่กี่นาทีเพื่อตรวจว่าสาเหตุเป็นไฟร์วอลล์หรือไม่ แล้วคืนทันทีที่ตรวจเสร็จ การดำเนินงานที่ปิดค้างเป็นการแลกปัญหาที่เติมกฎหนึ่งเส้นก็พอ กับความไร้การป้องกันทั้งพีซี

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก