Ping ทำงานได้ทางเดียว: ทำไม Windows ถึงทิ้งเสียงสะท้อนของเซิร์ฟเวอร์

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

สองทิศทาง สองการตัดสินใจที่ต่างกัน

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

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

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

ติดตามแพ็กเก็ตจนกว่าจะหายไป

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

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

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

จำกัดกฎข้อเดียวแทนการเปิด ICMP

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

สิ่งที่กฎไม่ได้ครอบคลุม

เสียงสะท้อน IPv6 เป็นโปรโตคอลอื่นที่มีชนิดข้อความอื่น กฎ ICMPv4 จึงไม่บอกอะไรเกี่ยวกับมัน และอุโมงค์ที่บรรทุกทั้งสองตระกูลต้องมีกฎของตัวเองสำหรับอีกตระกูลหนึ่ง กฎนี้ไม่ได้เปิดอย่างอื่นด้วย: RDP การแชร์ไฟล์ และบริการอื่นทุกอย่างยังคงขึ้นอยู่กับนโยบายของตัวเอง นี่คือเหตุผลทั้งหมดของการจำกัดกฎแคบ ๆ ข้อเดียวแทนการเปิดอนุญาต ICMP แบบกว้าง การอนุญาตแบบกว้างเป็นวิธีแก้ที่ง่ายและอยู่ได้นานที่สุด เพราะหลังจากนั้นไม่มีใครสังเกตเห็น

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

อ่านผลลัพธ์ในทิศทางที่ถูกต้อง

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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