เมื่อเครื่องภายในเริ่มการเชื่อมต่อขาออก IP ของเครื่องจะเป็น
NAT เป็นที่อยู่หลักของเกตเวย์ ไม่ใช่ที่อยู่ที่ฉันพยายาม
ให้มัน.
สิ่งนี้ควรแก้ไขด้วย:
iptables -t nat -I โพสต์ 1 -s 10.125.0.2 -o eth0 -j SNAT --to-source <FORWARD_IP>
มันถูกเพิ่มเข้าที่ด้านหน้า ดังนั้นมันจึงเริ่มทำงานก่อน ตรวจหาแพ็กเก็ตนั้นมาจากระบบนี้และแปลเป็น IP ที่ระบุ แทนที่จะเลือกที่อยู่จากอินเทอร์เฟซ
เมื่อได้รับการเชื่อมต่อ ดูเหมือนว่าพวกเขาจะมาจาก
IP ภายในของเกตเวย์ ไม่ใช่ IP ดั้งเดิม (ควรมีวิธีแก้ไข
เนื่องจากเป็นเกตเวย์เริ่มต้น)
ปัญหานี้เชื่อมโยงกับกฎ SNAT ต่อไปนี้:
iptables -t nat -A โพสต์ -j MASQUERADE
มันคือ ทาง กว้างไป. คุณกำลัง SNAT ทุกอย่าง ใน แต่ละ ทิศทางซึ่งไม่มีประสิทธิภาพและไม่ปลอดภัย มันตรงกับทุกสิ่ง รวมถึงแพ็กเก็ต DNATed ของคุณ ปลายทางจะถูกแปลเป็นที่อยู่ส่วนตัวก่อน จากนั้นจึงแปลแหล่งที่มาโดยกฎนี้เป็นที่อยู่ที่เลือกจากอินเทอร์เฟซส่วนตัวโดยกำหนดที่อยู่ 10.x.x.x
ฉันสงสัยว่าคุณกำลังพยายามปกปิดอินเทอร์เฟซสาธารณะทั้งหมดและเครือข่ายส่วนตัวทั้งหมดด้วยกฎเดียว แม้ว่าจะมีรายการที่อยู่ใน Linux (ชุด IP) แต่ไม่มีรายการอินเทอร์เฟซ ดังนั้นจึงเป็นไปไม่ได้ที่จะทำอย่างถูกต้องด้วยกฎเพียงข้อเดียว
กรองด้วย อย่างน้อย ที่อยู่ต้นทาง (เช่น ที่ ที่อยู่สำหรับการแปลแหล่งที่มา):
iptables -t nat -A โพสต์ -s 10.125.0.0/24 -j MASQUERADE
หากคุณมีเครือข่ายส่วนตัวหลายเครือข่าย ให้เพิ่มกฎประเภทนี้
ฉันคิดว่าเป็นการดีกว่าที่จะสร้างกฎเฉพาะสำหรับอินเทอร์เฟซสาธารณะแต่ละรายการ ดังนั้นแพ็กเก็ตที่ส่งออกผ่านอินเทอร์เฟซส่วนตัวจึงไม่สามารถแปลแหล่งที่มาได้ไม่ว่าจะมีที่อยู่ต้นทางใดก็ตาม เช่น iptables -t nat -A โพสต์ -s 10.125.0.0/24 -o eth0 -j MASQUERADE และอื่น ๆ ด้วยวิธีนี้แพ็กเก็ตตั้งแต่ 10.x.x.x ถึง 172.x.x.x จะไม่ได้รับการแปลด้วย และบริการของคุณในทั้งสองเครือข่ายจะเห็น IP ของกันและกันโดยตรง โดยยังคงเหลือความเป็นไปได้ในการเลือกกรองข้อมูลเหล่านี้ในห่วงโซ่ตัวกรอง FORWARD
หากบริการกำลังฟัง 0.0.0.0 บนเกตเวย์ แสดงว่าการเชื่อมต่อเปิดอยู่
พอร์ตนั้นไม่ได้รับการเปลี่ยนเส้นทาง พวกเขาไปที่บริการนั้น
และสุดท้าย ฉันไม่เข้าใจประเด็นนี้อย่างถ่องแท้ถามในคอมเม้นแล้วคุณไม่ตอบ การเชื่อมต่อใด จากที่ไหน IP ต้นทางคืออะไร
การประมวลผล DNAT เกิดขึ้นก่อนการตัดสินใจกำหนดเส้นทาง นั่นคือเหตุผลที่เชนเรียกว่า "PREROUTING" ไม่เคยตรวจสอบว่ามีกระบวนการในเครื่องที่รับฟังพอร์ตนั้นหรือไม่ วิธีเดียวที่บริการในพื้นที่จะมีโอกาสตอบคือให้แพ็กเก็ตผ่าน INPUT chain สำหรับสิ่งนั้น รหัสเส้นทางจะต้องตัดสินใจว่าปลายทางนั้นไปยังเครื่องโลคัล ดังนั้นจึงต้องไม่มีการแปลอีเธอร์เลยหรือแปลเป็นที่อยู่บางแห่งที่ระบบนี้กำหนดไว้
ตามกฎปัจจุบัน แพ็กเก็ตที่ส่งจากเครือข่ายส่วนตัวไปยัง IP สาธารณะควร ไม่ รับการแปลเพราะพวกเขาไม่ได้เข้ามาทาง eth0. ดังนั้นพวกเขาจึงต้องให้บริการโดยบริการในท้องถิ่น แต่สิ่งนี้ไม่ได้ขึ้นอยู่กับว่าบริการในพื้นที่ทำงานอยู่หรือไม่ หากไม่ใช่คุณจะมี "การเชื่อมต่อถูกปฏิเสธ"
หากคุณต้องการแพ็กเก็ตจาก LAN ไปยัง <FORWARD_IP> เพื่อแปลตามกฎ DNAT เดียวกัน ให้วางแพ็กเก็ตนั้น -i eth0 จับคู่:
iptables -A PREROUTING -d <REDACTED_FORWARDING_IP>/32 -j DNAT --to-destination 10.125.0.2
อย่างไรก็ตาม ฉันไม่เห็นด้วยกับกฎกว้างๆ ในความคิดของฉัน จะดีกว่าหากมีกฎ DNAT ที่รัดกุมที่สุดเท่าที่จะเป็นไปได้ ดังนั้นคุณควรกรองตามโปรโตคอล (tcp/udp) และพอร์ตของบริการที่คุณใช้งานบน 10.125.0.2 หากเป็นเว็บเซิร์ฟเวอร์ ให้ส่งต่อเฉพาะ tcp/80 และ tcp/443 ดังนี้ iptables -A PREROUTING -d <REDACTED_FORWARDING_IP>/32 -p tcp -m หลายพอร์ต --dports 80,443 -j DNAT --to-destination 10.125.0.2.
มีปัญหาอะไร? สมมติว่าคุณกำลังตรวจสอบบางอย่างด้วย ping ผลการ ping นี้จะขึ้นอยู่กับสถานะของระบบภายใน ซึ่งก็คือระบบที่คุณกำลัง ping ในความเป็นจริง สิ่งนี้ทำให้เกิดความสับสน นี่ไม่ใช่พฤติกรรมที่ผู้ดูแลระบบส่วนใหญ่คาดว่าจะเห็นเมื่อพวกเขา ping เราเตอร์ ดีกว่าปล่อยให้ ping ได้รับการตอบจากโฮสต์