ไฟร์วอลล์ Windows เดี่ยว ๆ เป็นสวิตช์ตัดการเชื่อมต่อ VPN: รับมือได้ไหม
กฎตามชนิดอินเทอร์เฟซบล็อกอะแดปเตอร์จริงได้ แต่ทันเนลของบุคคลที่สามมักดูเหมือนแบบมีสาย ตรวจสอบการจัดประเภท เส้นทางปลายทาง แล้วจึงตรวจ DNS
ถามว่าไฟร์วอลล์ Windows ใช้เดี่ยว ๆ เป็นสวิตช์ตัดการเชื่อมต่อได้ไหม คุณจะได้คำตอบที่มั่นใจสองข้อซึ่งขัดกัน ข้อหนึ่งบอกว่ากฎตามชนิดอินเทอร์เฟซทำทั้งหมด อีกข้อบอกว่าทำไม่ได้หากไม่มีสคริปต์ ทั้งสองอธิบายกลไกเดียวกันคนละครึ่ง ไฟร์วอลล์แสดงการบล็อกได้ และผลลัพธ์จะล้มเหลวแบบปิดจริงหรือไม่ขึ้นกับสามอย่าง Windows จัดประเภทอะแดปเตอร์ทันเนลอย่างไร ข้อยกเว้นของปลายทางยังอยู่หรือไม่ และการแปลงชื่อกับ IPv6 ถูกครอบคลุมหรือไม่ ผิดข้อใดข้อหนึ่งเครื่องจะรั่วหรือสูญเสียการเชื่อมต่อทั้งหมด
สามเงื่อนไข ตามลำดับนี้
เงื่อนไขแรกคือการจัดประเภท และเป็นตัวตัดสินว่ากฎที่ต้องการแสดงออกได้หรือไม่ กฎไฟร์วอลล์ Windows จำกัดตามชนิดอินเทอร์เฟซได้ คือแบบมีสาย แบบไร้สาย หรือการเข้าถึงระยะไกล นโยบายที่บล็อกทราฟฟิกขาออกบนชนิดจริงแต่ยอมให้ทันเนลทำงานได้เฉพาะเมื่อ Windows รู้จักทันเนลว่าเป็นการเข้าถึงระยะไกล
เงื่อนไขที่สองคือข้อยกเว้นของปลายทาง ก่อนจะมีทันเนลใด ๆ ไคลเอนต์ต้องไปถึงเซิร์ฟเวอร์ VPN ผ่านอะแดปเตอร์จริง การบล็อกทั้งหมดบนอะแดปเตอร์นั้นจึงขัดขวางการเชื่อมต่อที่ทำให้การบล็อกไม่จำเป็นพอดี ข้อยกเว้นต้องระบุเซิร์ฟเวอร์และพอร์ต และแพ็กเก็ตต้องออกผ่านเกตเวย์จริงไม่ใช่เข้าไปในทันเนลที่ยังไม่ขึ้น
อย่างที่สามคือความครอบคลุม ชุดกฎที่บล็อก IPv4 แล้วลืม IPv6 หรือยอมให้ตัวแปลงชื่อภายในค้นหาปลายทางและจึงยอมให้ทุกการค้นหาอื่นล้มเหลวแบบเปิดพอดีในหน้าต่างที่สวิตช์มีไว้เพื่อครอบคลุม นี่คือช่องว่างการออกแบบ ไม่ใช่ข้อบกพร่องของไฟร์วอลล์ และเป็นช่องว่างที่รอดทุกการทดสอบบนโต๊ะ
การจัดประเภทคือประตูด่านแรก
ดูว่า Windows มองอะแดปเตอร์อย่างไรก่อนเขียนกฎสักข้อ การเชื่อมต่อ VPN แบบเนทีฟของ Windows มักปรากฏเป็นการเข้าถึงระยะไกล ไคลเอนต์บุคคลที่สามที่สร้างอะแดปเตอร์เสมือนของตนเองมักปรากฏเป็นแบบมีสาย ซึ่งหมายความว่าการบล็อกที่จำกัดเฉพาะอะแดปเตอร์มีสายก็บล็อกทันเนลด้วย
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionคำสั่งที่สามบอกว่ามีการบล็อกขาออกโดยค่าเริ่มต้นอยู่แล้วหรือไม่ ซึ่งเปลี่ยนรูปร่างทั้งหมดของการออกแบบ ถ้าค่าเริ่มต้นเป็นการบล็อกอยู่แล้ว คุณกำลังเขียนกฎอนุญาตไม่ใช่ข้อยกเว้นของฐานที่ผ่อนปรน และนั่นเป็นจุดยืนที่คิดตามได้ง่ายกว่ามาก
ถ้าอะแดปเตอร์ทันเนลรายงานว่าตนเป็นแบบมีสาย ไฟร์วอลล์เดี่ยว ๆ ไม่ใช่เครื่องมือที่เหมาะสมสำหรับการออกแบบที่ล้มเหลวแบบปิด และการปรับกฎเท่าใดก็ไม่เปลี่ยนสิ่งนี้ นี่คือกรณีที่ความเห็นที่สองในทุกกระทู้ฟอรัมถูกต้อง
ข้อยกเว้นของปลายทางต้องมีทั้งเส้นทางและกฎ
สมมติว่าการจัดประเภททำงาน ข้อยกเว้นมีสองส่วนและอาศัยอยู่ในระบบย่อยที่ต่างกัน กฎไฟร์วอลล์อนุญาตทราฟฟิก ส่วนเส้นทางโฮสต์ทำให้มันออกผ่านอินเทอร์เฟซที่ถูกต้องขณะที่ทันเนลปิดอยู่
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32หากไม่มีเส้นทาง ข้อยกเว้นจะช่วยได้เพียงตราบที่เส้นทางเริ่มต้นยังชี้ไปที่เกตเวย์จริง เมื่อไคลเอนต์ติดตั้งเส้นทางเริ่มต้นของตนเองแล้วตาย แพ็กเก็ตที่ได้รับอนุญาตไม่มีที่ไปอย่างสมเหตุสมผลและการเชื่อมต่อก็สร้างใหม่ไม่ได้ ความล้มเหลวนั้นดูเหมือนไคลเอนต์พัง แต่จริง ๆ แล้วคือเส้นทางที่หายไป
รักษาข้อยกเว้นให้แคบเท่าที่ไคลเอนต์ยอมให้ หนึ่งแอดเดรสกับหนึ่งพอร์ตตรวจสอบได้ แต่ช่วงที่ครอบเครือข่ายทั้งหมดของผู้ให้บริการตรวจสอบไม่ได้ กฎที่กว้างกว่านั้นยังอนุญาตทุกอย่างอื่นที่โฮสต์อยู่กับผู้ให้บริการรายเดียวกัน ซึ่งมักมากกว่าที่ตั้งใจ
DNS และ IPv6 คือจุดที่มันล้มเหลวแบบเปิด
การแปลงชื่อคือการรั่วไหลคลาสสิก ถ้าปลายทางเป็นชื่อโฮสต์ ไคลเอนต์ต้องแปลงชื่อก่อนมีทันเนล ซึ่งหมายความว่าต้องอนุญาตให้อะแดปเตอร์จริงเข้าถึงตัวแปลงชื่อ สิทธิ์เดียวกันนั้นปล่อยให้ทุกการค้นหาอื่นออกไปขณะทันเนลปิดอยู่ และการค้นหาครั้งเดียวก็พอจะเปิดเผยว่าคุณกำลังจะไปเยี่ยมอะไร
IPv6 คืออย่างที่สอง กฎที่เขียนสำหรับ IPv4 ไม่ครอบคลุมอีกตระกูลหนึ่ง และไคลเอนต์จำนวนมากติดตั้งเฉพาะเส้นทาง IPv4 เครื่องที่มีการเชื่อมต่อ IPv6 แบบเนทีฟจึงยังคุยกับอินเทอร์เน็ตได้ขณะที่ฝั่ง IPv4 ถูกบล็อกแน่นหนา และสวิตช์รายงานความสำเร็จตลอดเวลา
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
แถวที่สามควรค่าแก่การเข้าใจมากกว่าการหลีกเลี่ยง ไฟร์วอลล์ตัดสินเรื่องแพ็กเก็ต ไม่ใช่ว่าแอปพลิเคชันขอใช้อินเทอร์เฟซใด และโปรแกรมที่ผูกกับอินเทอร์เฟซอย่างชัดเจนอาจคุมได้ยาก นั่นคือข้อโต้แย้งเพื่อสวิตช์ฝั่งไคลเอนต์ที่ทำงานใต้แอปพลิเคชัน ไม่ใช่เพื่อกฎที่เพิ่มขึ้น
ทดสอบด้วยการหยุดไคลเอนต์ ไม่ใช่การดึงสาย
การทดสอบเดียวที่มีความหมายคือการเลียนแบบความล้มเหลวที่คุณป้องกันอยู่ หยุดบริการ ฆ่าโปรเซส หรือปิดใช้อะแดปเตอร์ที่ไคลเอนต์สร้าง แล้วลองเข้าถึงอินเทอร์เน็ตและชื่อ
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443ทั้งสามควรล้มเหลว ถ้าอันแรกสำเร็จ การบล็อกไม่ได้ผล ถ้าอันที่สองสำเร็จในที่ที่อันแรก ล้มเหลว คุณมีการรั่วไหลของ DNS ถ้าอันที่สามสำเร็จ IPv6 ไม่ถูกครอบคลุม แต่ละผลชี้ไปที่ช่องว่างข้างต้นอย่างใดอย่างหนึ่งพอดี
ทดสอบซ้ำหลังหลับและตื่น เพราะโปรไฟล์ไฟร์วอลล์อาจเปลี่ยนเมื่อ Windows ตัดสินว่าเครือข่ายเป็นสาธารณะหรือส่วนตัว และกฎที่จำกัดตามโปรไฟล์จะตามไปด้วย การออกแบบที่อยู่บนโต๊ะได้แต่ล้มเหลวบนรถไฟคือการออกแบบที่ทดสอบเพียงครั้งเดียว
ถ้าประตูการจัดประเภทหรือข้อกำหนด DNS ทำให้วิธีไฟร์วอลล์เดี่ยว ๆ ใช้ไม่ได้ สวิตช์ฝั่งไคลเอนต์ คือคำตอบที่ซื่อตรง ถ้าทันเนลไปสิ้นสุดที่เราเตอร์แทน นโยบายควรเป็นของเราเตอร์ เพราะกฎเดียวที่นั่นครอบทุกอุปกรณ์ที่อยู่ข้างหลังและไม่ขึ้นกับว่า Windows เรียกอะแดปเตอร์ว่าอะไร