Ping ผ่าน VPN: ทำไมกฎสำหรับ echo reply ถึงพลาดเส้นทางขากลับ

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

แพ็กเก็ตเปลี่ยนชนิด ไม่ใช่พอร์ต

คำขอ echo คือ ICMP ชนิด 8 รหัส 0 และพา identifier กับหมายเลขลำดับไปด้วย คำตอบเป็นชนิด 0 รหัส 0 พร้อม identifier และลำดับเดียวกัน โดยสลับปลาย IP RFC 792 กำหนดฟิลด์เหล่านี้ และ identifier คือสิ่งที่ทำให้ผู้ส่งจับคู่คำตอบกับคำขอของตนเองได้

สิ่งที่ไม่มีก็สำคัญพอ ๆ กัน: ไม่มีส่วนหัว TCP หรือ UDP จึงไม่มีพอร์ตให้อนุญาต กฎที่ระบุพอร์ตสำหรับ echo reply ย่อมบรรยายแพ็กเก็ตที่จะไม่มีวันเกิดขึ้น นี่คือข้อผิดพลาดที่พบบ่อยที่สุดในตั๋ว ping ของ VPN กฎดูเฉพาะเจาะจง ใช้กับสิ่งใดไม่ได้เลย และปล่อยให้ความล้มเหลวอยู่ที่เดิม

สามบริบทเป็นตัวกำหนดแพ็กเก็ต

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

สามบริบทนี้มีสายกฎและตัวนับต่างกัน และการถือว่ามันเป็นหนึ่งเดียวคือเหตุผลที่ «ไฟร์วอลล์อนุญาต ICMP» ยังให้ ping ที่ล้มเหลวได้ อุโมงค์ชั้นนอกเป็นบริบทที่สี่: การอนุญาต listener ของ VPN ไม่ได้อนุญาตคำขอภายในที่ถอด encapsulation แล้วโดยอัตโนมัติ และการอนุญาตภายในไม่ได้บอกอะไรว่าอุโมงค์ชั้นนอกทำงานอยู่หรือไม่

ฟิลเตอร์แบบ stateful และ stateless จัดการคำตอบต่างกัน

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

ตรวจสอบว่าผลิตภัณฑ์ใช้แบบจำลองใดจริงก่อนเขียนอะไร กฎสำหรับคำขอ echo ไม่จำเป็นต้องครอบคลุม echo reply และผลิตภัณฑ์ที่ติดตาม ICMP query อาจใช้นโยบายต่างกับคำตอบที่มาจากอินเทอร์เฟซอื่น

จำกัดสิ่งที่คุณอนุญาต การอนุญาต echo reply ทุกอันจากทุกที่นั้นไม่เหมือนกับการทำให้ความสัมพันธ์แบบ stateful สมบูรณ์ และหมายเลขชนิดไม่ได้พิสูจน์ตัวผู้ส่ง

การแปลเปลี่ยน identifier ด้วย

ถ้าการแปลต้นทางเป็นเจตนา tuple ที่ปลายทางไกลจะไม่ตรงกับที่ไคลเอนต์ส่งไป NAT สามารถแปล identifier ของ ICMP query ไปพร้อมกับที่อยู่ ดังนั้นการยืนกรานให้หมายเลขเดียวกันปรากฏทั้งสองด้านจึงสร้างความไม่ตรงกันปลอมขึ้น

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

อย่ารวมข้อผิดพลาด ICMP เข้ากับนโยบาย echo

ข้อความ «ต้องมีการแบ่งส่วน» ที่ใช้โดยการค้นหา MTU ของเส้นทางไม่ใช่ echo reply และเพย์โหลดของมันอ้างอิงแพ็กเก็ตที่ทำให้เกิด การอนุญาตเฉพาะ echo ที่ทิ้งข้อผิดพลาดเหล่านั้นอย่างเงียบ ๆ เปลี่ยนปัญหาเรื่องขนาดให้กลายเป็นการเชื่อมต่อที่ค้าง ซึ่งตรงข้ามกับการเป็นประโยชน์

ความระวังเดียวกันใช้กับตระกูลที่อยู่ ICMPv6 ใช้ชนิดข้อความต่างกันและพาฟังก์ชันจำเป็นที่ IPv4 ไม่มี ดังนั้นการคัดลอกหมายเลขเหล่านี้ลงในกฎ IPv6 จึงผิดอย่างตรงไปตรงมา

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