โปรโตคอล 47 กับพอร์ต TCP 47: สองเฮดเดอร์ สองกฎ

เครือข่ายโรงแรมและไฟร์วอลล์ของงานประชุมมักมีช่องอนุญาตที่กำหนดเอง และมีคนพิมพ์ 47 ลงไปโดยหวังว่า PPTP จะทำงานได้ กฎถูกสร้างขึ้น อุโมงค์ยังคงล้มเหลว และความพยายามครั้งถัดไปใช้หมายเลขอื่น ข้อผิดพลาดอยู่ในแพ็กเก็ตเอง: IPv4 มีฟิลด์โปรโตคอลที่ระบุว่าอะไรตามมาหลังเฮดเดอร์ IP ขณะที่ TCP และ UDP มีฟิลด์พอร์ตซึ่งมีอยู่ก็ต่อเมื่อคุณอยู่ภายในเฮดเดอร์ใดเฮดเดอร์หนึ่งนั้น สองสิ่งนี้ไม่ใช่การเขียนที่ต่างกันของสิทธิ์เดียวกัน

เฮดเดอร์ IPv4 ระบุโปรโตคอลถัดไป

ฟิลด์โปรโตคอลเป็นหนึ่งไบต์ในเฮดเดอร์ IPv4 และเก็บหมายเลขที่อธิบายเพย์โหลด: 6 สำหรับ TCP, 17 สำหรับ UDP, 47 สำหรับ GRE, 50 สำหรับ ESP ทุกสิ่งที่กรองแพ็กเก็ตจะอ่านค่านั้นก่อนจะมองลึกกว่านั้น เพราะเฮดเดอร์ที่ลึกกว่าจะมีความหมายก็ต่อเมื่อรู้ชนิดแล้ว เปลี่ยนพอร์ตในภายหลังของการสนทนา ฟิลด์นี้ไม่ได้ขยับ

ดังนั้นกฎที่เขียนกับโปรโตคอล 47 จึงอธิบายชั้น IP ไม่มีพอร์ตใดเข้าร่วมในการตัดสินใจเลย

พอร์ตมีอยู่ภายใน TCP และ UDP เท่านั้น

พอร์ตคือตัวระบุสิบหกบิตภายในเฮดเดอร์ TCP และ UDP หน้าที่ของมันคือแยกการสนทนาที่ใช้ที่อยู่เดียวกัน เฮดเดอร์ GRE มีค่าชนิดโปรโตคอล มักเป็น EtherType พร้อมคีย์เพิ่มเติมสำหรับการมัลติเพล็กซ์ ดังนั้นวลีพอร์ต 47 จึงไม่ได้ระบุสิ่งใดที่แพ็กเก็ต GRE จะจับคู่ได้

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

PPTP ใช้ทั้งสองชั้นพร้อมกัน

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

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

ทำไมหน้าส่งต่อพอร์ตจึงแสดง GRE ไม่ได้

แบบฟอร์มส่งต่อที่รับเฉพาะ TCP และ UDP ไม่สามารถอธิบาย GRE ได้ ไม่ว่าแบบฟอร์มจะชื่ออะไร การแปลที่อยู่เพิ่มความยากอย่างที่สอง เพราะ GRE ไม่มีพอร์ตและตัวแปลต้องติดตามตัวระบุการเรียกแทน เราเตอร์สำหรับผู้ใช้บางรุ่นมีตัวช่วยที่จัดการเรื่องนี้ หลายรุ่นไม่มี และไม่มีรายการอนุญาต TCP เพิ่มเติมใดที่จะสร้างพฤติกรรมนั้นได้

เมื่อความต้องการจริงคืออุโมงค์สมัยใหม่ ให้เลือกการออกแบบที่ใช้ TCP หรือ UDP อย่างตั้งใจแทนที่จะหวังให้ตัวแปลเดาถูก

การห่อหุ้มเป็นตัวกำหนดว่าตัวกรองเห็นอะไร

การห่อหุ้มเปลี่ยนแพ็กเก็ตชั้นนอก และแพ็กเก็ตชั้นนอกคือสิ่งที่กฎจับคู่ ESP แบบดั้งเดิมคือโปรโตคอล 50 ขณะที่การผ่าน NAT ห่อ ESP ไว้ใน UDP 4500 เพื่อให้รอดจากการแปลที่อยู่ ตัวกรองที่อนุญาต UDP 4500 จะไม่เห็นโปรโตคอล 50 เลย และตัวกรองที่เขียนสำหรับโปรโตคอล 50 จะไม่ตรงกับรูปแบบที่ห่อไว้เลย

ถามว่าลูกค้าและเกตเวย์ตกลงใช้การห่อหุ้มแบบใด แล้วเขียนกฎสำหรับรูปแบบชั้นนอกนั้นเท่านั้น ไม่มากกว่านั้น

เขียนกฎให้ใครสักคนตรวจสอบได้

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

เพิ่มการทดสอบที่พิสูจน์เรื่องนี้: เชื่อมต่อขณะดักจับบนอินเทอร์เฟซชั้นนอก และยืนยันโปรโตคอลและพอร์ตชั้นนอกที่ปรากฏจริงในร่องรอย