เนื่องจากการตัดสินใจในการออกแบบเครือข่ายที่ไม่ดี (ส่วนใหญ่) หลายครั้งเมื่อหลายปีก่อนเพื่อประหยัดเงินไม่กี่ดอลลาร์ที่นี่และที่นั่น ฉันมีเครือข่ายที่ได้รับการออกแบบมาอย่างดีในระดับย่อย ฉันกำลังมองหาคำแนะนำเพื่อปรับปรุงสถานการณ์ที่ไม่น่าพอใจนี้

เราเป็นองค์กรไม่แสวงหาผลกำไรที่มีแผนกไอทีที่ทำงานบน Linux และมีงบประมาณจำกัด (หมายเหตุ: อุปกรณ์ Windows ที่เราใช้งานไม่ได้ทำอะไรที่พูดกับอินเทอร์เน็ตและเราไม่มีผู้ดูแลระบบ Windows คอยดูแลอยู่)

ประเด็นสำคัญ:

  • เรามีสำนักงานใหญ่และไซต์ระยะไกลประมาณ 12 แห่งที่เพิ่มเครือข่ายย่อยของ NAT เป็นสองเท่าด้วยสวิตช์แยกทางกายภาพ (ไม่มี VLAN และความสามารถจำกัดในการดำเนินการกับสวิตช์ปัจจุบัน)
  • ตำแหน่งเหล่านี้มีซับเน็ต "DMZ" ที่เป็น NAT บนซับเน็ต 10.0.0/24 ที่กำหนดเหมือนกันในแต่ละไซต์ ซับเน็ตเหล่านี้ไม่สามารถพูดคุยกับ DMZ ที่ตำแหน่งอื่นได้ เนื่องจากเราไม่ได้กำหนดเส้นทางไปที่ใดเลย ยกเว้นระหว่างเซิร์ฟเวอร์และ "ไฟร์วอลล์" ที่อยู่ติดกัน
  • ตำแหน่งเหล่านี้บางแห่งมีการเชื่อมต่อ ISP หลายรายการ (T1, เคเบิล และ/หรือ DSL) ที่เรากำหนดเส้นทางด้วยตนเองโดยใช้เครื่องมือ IP ใน Linux ไฟร์วอลล์เหล่านี้ทำงานบนเครือข่าย (10.0.0/24) และส่วนใหญ่เป็นไฟร์วอลล์ระดับ "มืออาชีพ" (Linksys, Netgear เป็นต้น) หรือโมเด็ม DSL ที่ ISP จัดหาให้
  • การเชื่อมต่อไฟร์วอลล์เหล่านี้ (ผ่านสวิตช์ธรรมดาที่ไม่มีการจัดการ) เป็นเซิร์ฟเวอร์ตั้งแต่หนึ่งเครื่องขึ้นไปที่ต้องสามารถเข้าถึงได้โดยสาธารณะ
  • เชื่อมต่อกับเครือข่ายย่อย 10.0.0/24 ของสำนักงานใหญ่ ได้แก่ เซิร์ฟเวอร์สำหรับอีเมล, VPN ทางไกล, เซิร์ฟเวอร์ VPN สำหรับสำนักงานระยะไกล, เราเตอร์หลักไปยังซับเน็ต 192.168/24 ภายใน สิ่งเหล่านี้จะต้องเข้าถึงได้จากการเชื่อมต่อ ISP เฉพาะตามประเภทการรับส่งข้อมูลและแหล่งที่มาของการเชื่อมต่อ
  • การกำหนดเส้นทางทั้งหมดของเราดำเนินการด้วยตนเองหรือด้วยคำสั่งเส้นทางของ OpenVPN
  • การรับส่งข้อมูลระหว่างสำนักงานต้องผ่านบริการ OpenVPN ในเซิร์ฟเวอร์ 'เราเตอร์' หลักซึ่งมี NAT อยู่ด้วย
  • ไซต์ระยะไกลมีเซิร์ฟเวอร์เพียงเครื่องเดียวที่ติดตั้งในแต่ละไซต์ และไม่สามารถซื้อเซิร์ฟเวอร์หลายเครื่องได้เนื่องจากข้อจำกัดด้านงบประมาณ เซิร์ฟเวอร์เหล่านี้เป็นเซิร์ฟเวอร์ LTSP ทั้งหมดที่มีเทอร์มินัล 5-20 ตัว
  • ซับเน็ต 192.168.2/24 และ 192.168.3/24 เป็นส่วนใหญ่ แต่ไม่ใช่ทั้งหมดบนสวิตช์ Cisco 2960 ที่สามารถทำ VLAN ได้ ส่วนที่เหลือคือสวิตช์ DLink DGS-1248 ที่ฉันไม่แน่ใจว่าดีพอที่จะใช้กับ VLAN ยังมีข้อกังวลภายในที่ยังหลงเหลืออยู่เกี่ยวกับ VLAN เนื่องจากมีเพียงเจ้าหน้าที่เครือข่ายอาวุโสเท่านั้นที่เข้าใจวิธีการทำงาน

การรับส่งข้อมูลทางอินเทอร์เน็ตปกติทั้งหมดต้องผ่านเซิร์ฟเวอร์เราเตอร์ CentOS 5 ซึ่งจะเปลี่ยน NATs 192.168/24 ซับเน็ตไปยังซับเน็ต 10.0.0.0/24 ตามกฎการกำหนดเส้นทางที่กำหนดค่าด้วยตนเองซึ่งเราใช้เพื่อชี้การรับส่งข้อมูลขาออกไปยังการเชื่อมต่ออินเทอร์เน็ตที่เหมาะสมตาม คำสั่งการกำหนดเส้นทาง '-host'

ฉันต้องการลดความซับซ้อนของสิ่งนี้และเตรียมทุกสิ่งสำหรับการจำลองเสมือนของ ESXi รวมถึงบริการสาธารณะเหล่านี้ มีวิธีแก้ไขปัญหาที่ไม่มีต้นทุนหรือต้นทุนต่ำที่จะกำจัด Double-NAT และฟื้นฟูสติเล็กน้อยให้กับความยุ่งเหยิงนี้เพื่อที่การทดแทนในอนาคตของฉันจะไม่ตามล่าฉันหรือไม่

ไดอะแกรมพื้นฐานสำหรับสำนักงานใหญ่: ใส่คำอธิบายภาพที่นี่

นี่คือเป้าหมายของฉัน:

  • เซิร์ฟเวอร์สาธารณะที่มีอินเทอร์เฟซบนเครือข่าย 10.0.0/24 กลางนั้นจะถูกย้ายไปยังซับเน็ต 192.168.2/24 บนเซิร์ฟเวอร์ ESXi
  • กำจัด NAT สองเท่าและรับเครือข่ายทั้งหมดของเราในเครือข่ายย่อยเดียว ความเข้าใจของฉันคือนี่คือสิ่งที่เราต้องทำภายใต้ IPv6 อยู่ดี แต่ฉันคิดว่าความยุ่งเหยิงนี้กำลังขวางทางอยู่
answer

1. ) ก่อนอื่นใดโดยพื้นฐานแล้วให้วางแผนที่อยู่ IP ของคุณให้ชัดเจน การเปลี่ยนหมายเลขใหม่เป็นเรื่องที่เจ็บปวด แต่เป็นขั้นตอนที่จำเป็นในการไปถึงโครงสร้างพื้นฐานที่ใช้การได้ แยกซุปเปอร์เน็ตขนาดใหญ่ที่สรุปได้ง่าย ๆ ไว้สำหรับเวิร์กสเตชัน เซิร์ฟเวอร์ ไซต์ระยะไกล (ด้วย IP ที่ไม่ซ้ำกันโดยธรรมชาติ) เครือข่ายการจัดการ ลูปแบ็ค ฯลฯ อย่างสะดวกสบาย มีพื้นที่ RFC1918 จำนวนมากและราคาเหมาะสม

2. ) เป็นการยากที่จะเข้าใจวิธีวาง L2 ในเครือข่ายของคุณตามไดอะแกรมด้านบน VLAN อาจไม่จำเป็นถ้าคุณมีอินเทอร์เฟซเพียงพอในเกตเวย์ต่างๆ ของคุณ รวมทั้งจำนวนสวิตช์ที่เพียงพอ เมื่อคุณเข้าใจ #1 แล้ว คุณควรเข้าหาคำถาม L2 แยกกันอีกครั้ง ที่กล่าวว่า VLAN ไม่ใช่ชุดเทคโนโลยีที่ซับซ้อนหรือแปลกใหม่เป็นพิเศษและไม่จำเป็นต้องซับซ้อนขนาดนั้น การฝึกขั้นพื้นฐานจำนวนหนึ่งอยู่ในลำดับ แต่อย่างน้อยความสามารถในการแยกสวิตช์มาตรฐานออกเป็นพอร์ตหลายกลุ่ม (เช่น โดยไม่ต้องเดินสายไฟ) สามารถประหยัดเงินได้มาก

3. ) โฮสต์ DMZ ควรวางบนเครือข่าย L2/L3 ของตนเอง ไม่ได้รวมเข้ากับเวิร์กสเตชัน ตามหลักการแล้วคุณควรมีเราเตอร์ชายแดนของคุณเชื่อมต่อกับอุปกรณ์ L3 (เราเตอร์อีกชุดหนึ่งหรือสวิตช์ L3?) ซึ่งจะเชื่อมต่อเครือข่ายที่มีอินเทอร์เฟซเซิร์ฟเวอร์ภายนอกของคุณ (โฮสต์ SMTP ฯลฯ ) โฮสต์เหล่านี้มีแนวโน้มที่จะเชื่อมต่อกลับไปยังเครือข่ายอื่นหรือ (เหมาะสมน้อยกว่า) กับเครือข่ายย่อยของเซิร์ฟเวอร์ทั่วไป หากคุณได้จัดวางเครือข่ายย่อยของคุณอย่างเหมาะสม เส้นทางคงที่ที่จำเป็นในการกำหนดเส้นทางการรับส่งข้อมูลขาเข้าควรจะง่ายมาก

3a.) พยายามแยกเครือข่าย VPN ออกจากบริการขาเข้าอื่นๆ สิ่งนี้จะทำให้สิ่งต่าง ๆ ง่ายขึ้นในด้านการตรวจสอบความปลอดภัย การแก้ไขปัญหา การบัญชี ฯลฯ

4.) ขาดการรวมการเชื่อมต่ออินเทอร์เน็ตของคุณและ/หรือกำหนดเส้นทางเครือข่ายย่อยเดียวผ่านผู้ให้บริการหลายราย (อ่าน: BGP) คุณจะต้องการกระโดดระดับกลางก่อนที่เราเตอร์ชายแดนของคุณจะสามารถเปลี่ยนเส้นทางการรับส่งข้อมูลขาเข้าและขาออกได้อย่างเหมาะสม (เช่น ฉันสงสัยว่าคุณกำลังทำอยู่ในขณะนี้) ดูเหมือนว่าจะปวดหัวมากกว่าของ VLAN แต่ฉันคิดว่ามันสัมพันธ์กันทั้งหมด