ไฟร์วอลล์ของฮอตสปอตของคุณบล็อก DHCP ก่อนการเช่า

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

ดูไคลเอนต์เชื่อมต่อ

ติดตามการเชื่อมต่อหนึ่งครั้งจากฝั่งไคลเอนต์ วิทยุเชื่อมต่อ ไคลเอนต์ส่งการค้นหา DHCP เซิร์ฟเวอร์เสนอ ไคลเอนต์ร้องขอ เซิร์ฟเวอร์ตอบรับ และหลังจากนั้นไคลเอนต์จึงมีที่อยู่ที่ใช้กับสิ่งอื่นได้

ทุกอย่างก่อนการตอบรับสุดท้ายนั้นเกิดขึ้นขณะที่ไคลเอนต์ยังใช้เกตเวย์กับการรับส่งปกติไม่ได้ นั่นคือช่วงเวลาที่กฎซับเน็ตลืมไป

แพ็กเก็ตแรกมีอะไรอยู่จริง

RFC 2131 ระบุว่าการออกอากาศ DHCP ของไคลเอนต์ก่อนได้ที่อยู่ใช้ที่อยู่ต้นทางเป็นศูนย์ ข้อความจากไคลเอนต์ไปเซิร์ฟเวอร์ไปที่พอร์ต UDP 67 และจากเซิร์ฟเวอร์ไปไคลเอนต์ไปที่พอร์ต UDP 68 ดังนั้นการค้นหาจึงมาพร้อม 0.0.0.0 เป็นต้นทาง และกฎที่กำหนดให้ต้นทางอยู่ในซับเน็ตฝั่งไคลเอนต์ของคุณก็ไม่ตรงกับมัน

นี่ไม่ใช่การตั้งค่าที่ผิดฝั่งไคลเอนต์ นี่คือโปรโตคอลที่ทำงานตามที่ออกแบบไว้ ในช่วงเวลาเดียวที่ทำได้

เส้นทางใดจัดการเรื่องนี้จริง

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

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

สูตรขาเข้าและขาออกทั่วไปที่คัดลอกจากฟอรัมไม่ใช่หลักฐานว่าการทำงานของคุณผ่านเชนเหล่านั้นเหมือนกัน

การตอบกลับไม่ใช่การออกอากาศเสมอไป

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

การต่ออายุการเช่าในภายหลังจะทำการแลกเปลี่ยนซ้ำในอีกสถานะหนึ่ง ดังนั้นเว้นที่ไว้ให้ด้วย ไม่ใช่แค่การเชื่อมต่อครั้งแรก

แก้ให้แคบแล้วตรวจส่วนที่เหลือ

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

การฟลัชตารางไม่ใช่ขั้นตอนการตั้งค่า DHCP ใน iptables คำสั่ง flush ลบกฎออกจากเชนหรือตารางที่เลือก และการฟลัชตาราง NAT ไม่ได้สร้างกฎแปลที่อยู่ การตั้งนโยบาย ACCEPT แบบกว้างจะลบการป้องกันที่ไม่เกี่ยวกับการเช่า จึงไม่ควรอยู่ในวิธีแก้ฮอตสปอตที่ใช้ซ้ำได้

เมื่อไคลเอนต์มีการเช่าแล้ว ให้ตรวจสอบ DNS การส่งต่อ และทางออก VPN เป็นงานแยกกัน การเช่าสร้างการกำหนดที่อยู่ภายในเท่านั้น ไม่มีอะไรมากกว่านั้น