ไคลเอนต์ VPN ถูกบล็อกโดยโปรไฟล์ไฟร์วอลล์สาธารณะของ Windows

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

ระบุว่าแท้จริงแล้วทราฟฟิกเข้าที่โปรไฟล์ใด

ไฟร์วอลล์ของ Windows ไม่มีโหมดส่วนกลางเดียว ทุกอินเทอร์เฟซที่เชื่อมต่อมีหมวดหมู่ และแพ็กเก็ตขาเข้าจะถูกกรองตามหมวดหมู่ของอินเทอร์เฟซที่มันเข้ามา ดังนั้นโปรไฟล์ของอะแดปเตอร์ VPN จึงเป็นตัวกำหนดว่าไคลเอนต์ในอุโมงค์เข้าถึงอะไรได้ ไม่ใช่อะแดปเตอร์ Wi-Fi หรืออีเทอร์เน็ตที่อยู่ข้าง ๆ อ่านข้อเท็จจริงทั้งสองก่อนเปลี่ยนอะไร:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

ในการติดตั้ง OpenVPN หรือ WireGuard ตามปกติ อะแดปเตอร์ VPN จะปรากฏเป็นเครือข่ายที่ไม่รู้จักและตกลงในโปรไฟล์สาธารณะ ซึ่งเป็นค่าเริ่มต้นของทุกเครือข่ายที่ Windows จัดประเภทไม่ได้: ไม่มีโดเมนคอนโทรลเลอร์ตัวใดตอบกลับผ่านมัน และไม่มีโปรไฟล์เกตเวย์ใดตรงกัน ชื่ออินเทอร์เฟซไม่สำคัญที่นี่ การเรียกอะแดปเตอร์ว่า "VPN" หรือ "Corp" จึงไม่เปลี่ยนอะไร DomainAuthenticated ต้องใช้เครื่องที่เข้าร่วมโดเมน และต้องเข้าถึงโดเมนคอนโทรลเลอร์ได้จริงผ่านอินเทอร์เฟซนั้น อุโมงค์แบบแยกที่พกเพียงซับเน็ตเดียวจะไม่ผ่านเงื่อนไขนี้

หากกฎที่คุณต้องการถูกจำกัดไว้ที่พูล VPN อยู่แล้วและมีผลกับหมวดหมู่ที่คุณเพิ่งอ่านอยู่แล้ว ให้หยุดตรงนี้ การกรองไม่ใช่ชั้นของคุณ และที่ต่อไปที่ควรดูคือการกำหนดค่าบริการ การตรวจนี้ใช้เวลาสิบวินาทีและประหยัดเวลาการแก้กฎหนึ่งชั่วโมง ชื่อหมวดหมู่และสิ่งที่แต่ละหมวดครอบคลุมมีบันทึกไว้ใน เอกสารอ้างอิง Get-NetConnectionProfile

ยืนยันว่าเป็นการกรองไม่ใช่การกำหนดเส้นทาง ก่อนแก้ไขกฎ

Ping เป็นการทดสอบที่อ่อนแอ ICMP อาจผ่านได้ในขณะที่พอร์ตบริการถูกทิ้ง และโฮสต์อาจตอบจาก LAN ในขณะที่ปฏิเสธคำขอเดียวกันผ่านอุโมงค์ ทดสอบพอร์ตที่ไคลเอนต์ต้องการ จากไคลเอนต์:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

หากการทดสอบพอร์ตล้มเหลว ให้แยกสองชั้นออกจากกัน ความผิดพลาดของอุโมงค์หรือเส้นทางมักปรากฏเป็นการไม่มีคำตอบจากที่อยู่เกตเวย์เลย ขณะที่การทิ้งโดยไฟร์วอลล์แสดงเกตเวย์ที่ตอบได้และพอร์ตบริการที่ไม่ตอบ บนเซิร์ฟเวอร์ Windows ที่เผยแพร่พูลผ่าน RRAS ให้รันการทดสอบเดียวกันจากไคลเอนต์และอ่านโปรไฟล์ของเซิร์ฟเวอร์เอง: อินเทอร์เฟซ RAS อาจอยู่ในหมวดหมู่ที่กฎขาเข้าของมันไม่เคยกล่าวถึงช่วงไคลเอนต์เลย และนั่นคือเหตุผลที่เครื่องนั้นให้บริการ LAN ของตัวเองและปฏิเสธไคลเอนต์ทุกตัวในอุโมงค์

เมื่อผลยังไม่ชัดเจน ให้บันทึกการทิ้งของโปรไฟล์ที่เกี่ยวข้องและอ่านมัน:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

รายการที่ระบุที่อยู่และพอร์ตของไคลเอนต์พร้อม DROP เป็นข้อสรุปที่แน่ชัด และยังบอกด้วยว่ากฎใดหายไป บันทึกที่ว่างเปล่าขณะที่ SYN ของไคลเอนต์ไม่เคยปรากฏชี้ไปที่ต้นน้ำของโฮสต์ ดังนั้นกลับไปที่อุโมงค์ กฎ NAT หรือเส้นทางของพูลก่อนแตะวัตถุไฟร์วอลล์อื่น

จำกัดกฎขาเข้าหนึ่งกฎไว้ที่พูลไคลเอนต์

การแก้ไขคือกฎอนุญาตขาเข้าหนึ่งกฎที่มีที่อยู่ระยะไกลเป็นพูล ไม่ใช่ทั้งโลก จากเซสชันที่ยกระดับ:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

เมื่อบริการเป็นไฟล์ไบนารีเดียว ให้เลือกกฎที่จำกัดตามโปรแกรมด้วย -Program แทนรายการพอร์ต ซึ่งจำกัดข้อยกเว้นทั้งที่โพรเซสและที่ช่วงต้นทาง

การเลือกโปรไฟล์คือจุดที่ความผิดพลาดเดียวกันเกิดขึ้นในทิศทางตรงกันข้าม -Profile Public เพียงพอเมื่ออะแดปเตอร์เป็นสาธารณะและยังคงเป็นสาธารณะ -Profile Any เป็นสิ่งที่ป้องกันได้เมื่อบริการต้องทำงานไม่ว่า Windows จะจัดประเภทอะแดปเตอร์อย่างไร แต่เฉพาะตราบเท่าที่ขอบเขตระยะไกลยังคงอยู่ สิ่งที่ป้องกันไม่ได้เลยคือ -RemoteAddress Any บนโปรไฟล์สาธารณะ: กฎนั้นติดตามแล็ปท็อปไปทุกเครือข่ายคาเฟ่และโรงแรมที่มันเข้าร่วม และเปิดพอร์ตให้ทุกคนที่แชร์ซับเน็ตนั้น

บันทึกพูลไว้ข้างกฎ -RemoteAddress 10.8.0.0/24 จะเลิกตรงกันอย่างเงียบ ๆ ในวันที่พูล VPN ถูกกำหนดเลขใหม่ และอาการก็ดูเหมือนบั๊กเดิมทุกประการ จึงต้องเสียบ่ายอีกครึ่งวัน ตั้งชื่อกฎตามบริการและช่วงต้นทาง เก็บไว้พร้อมกับ -Group และอ่านใหม่ทุกครั้งที่คำจำกัดความของพูลเปลี่ยน รายการกฎที่ตรวจสอบได้ในหน้าจอเดียวดีกว่ากฎที่ถูกต้องซึ่งไม่มีใครหาเจอ

เปลี่ยนหมวดหมู่เฉพาะเมื่อหมวดหมู่คือการตัดสินใจ

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

มีกรณีที่การจัดประเภทผิดจริง: อุโมงค์ที่เปิดตลอดเวลาหรือระหว่างไซต์ซึ่งพกซับเน็ตของออฟฟิศเป็นโครงสร้างพื้นฐานที่เชื่อถือได้ และการทำเครื่องหมายอะแดปเตอร์นั้นเป็นส่วนตัวเป็นการตัดสินใจออกแบบที่ชอบด้วยเหตุผล ซึ่งทำครั้งเดียวด้วยนโยบายไม่ใช่ทุกตั๋ว เมื่อทำแล้วให้ทำอย่างชัดเจน:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

บนอุปกรณ์ที่ได้รับการจัดการ ให้ตรวจก่อนว่าการตั้งค่าอยู่ในความดูแลของ Group Policy หรือ Baseline ของ MDM หรือไม่ หากใช่ การเปลี่ยนแปลงในเครื่องจะถูกย้อนกลับในการรีเฟรชครั้งถัดไป และ gpresult /h จะระบุชื่อนโยบายที่เป็นเจ้าของ แก้ที่นั้น ไม่ใช่ที่ปลายทาง

ตรวจสอบจากทั้งสองด้านและทิ้งร่องรอยไว้

ตรวจสอบโฟลว์ที่ผู้ใช้รายงาน จากไคลเอนต์ หลังการเปลี่ยนแปลง:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

ก่อนบอกว่าเสร็จ:

• โปรไฟล์ที่ระบุในกฎคือโปรไฟล์บนอินเทอร์เฟซที่ทราฟฟิกเข้ามา
• ขอบเขตระยะไกลคือพูล VPN และพูลนั้นตรงกับสิ่งที่เซิร์ฟเวอร์มอบให้จริง
• ไม่มีกฎใดที่คุณเพิ่มใช้ -RemoteAddress Any บนโปรไฟล์สาธารณะ
• ไม่มีอะไรถูกปิดใช้งานเพื่อให้การทดสอบผ่าน และทุกการเปลี่ยนหมวดหมู่บันทึกว่าใครอนุมัติ