Метод реструктуризації мережі для мережі Double-NAT

Через низку поганих дизайнерських рішень для мережі (в основному), прийнятих багато років тому, щоб заощадити кілька доларів тут і там, у мене є мережа, яка, безумовно, не оптимізована. Я шукаю пропозиції щодо покращення цієї менш приємної ситуації.

Ми неприбутковий з відділом інформаційних технологій на базі Linux та обмеженим бюджетом. (Примітка. Жодне із запущених нами обладнання Windows не робить нічого, що спілкується в Інтернеті, а також у нас немає адміністраторів Windows.)

Ключові моменти:

• У нас є головний офіс і близько 12 віддалених сайтів, які по суті подвоюють NAT свої підмережі за допомогою фізично розділених комутаторів. (Немає VLANing і обмежена можливість робити це за допомогою перемикачів струму)
• Ці локації мають підмережу "DMZ", яка є NAT'd на однаково присвоєній підмережі 10.0.0 / 24 на кожному сайті. Ці підмережі не можуть спілкуватися з DMZ в будь-якому іншому місці, тому що ми не направляємо їх куди завгодно, окрім між сервером та сусіднім "брандмауером".
• Деякі з цих місць мають декілька підключень ISP (T1, Cable та / або DSL), які ми вручну маршрутизуємо за допомогою IP Tools у Linux. Ці брандмауери працюють у мережі (10.0.0 / 24) і є переважно брандмауерами класу «промер» (Linksys, Netgear тощо) або DSL-модемами.
• Підключення цих брандмауерів (за допомогою простих некерованих комутаторів) - це один або декілька серверів, які повинні бути доступними для публіки.
• До підмережі 10.0.0 / 24 головного офісу підключені сервери для електронної пошти, телекомунікаційний VPN, сервер VPN віддаленого офісу, основний маршрутизатор до внутрішньої підмережі 192.168 / 24. Це повинен бути доступ із конкретних підключень ISP на основі типу трафіку та джерела з'єднання.
• Всі наші маршрутизації виконуються вручну або за допомогою операторів OpenVPN
• Між офісний трафік проходить через сервіс OpenVPN на головному сервері «Маршрутизатор», в якому задіяний власний NAT'ing.
• Віддалені сайти мають лише один сервер, встановлений на кожному сайті, і не можуть дозволити собі декілька серверів через бюджетні обмеження. Ці сервери - це всі LTSP-сервери, кілька 5-20 терміналів.
• Підмережі 192.168.2 / 24 та 192.168.3 / 24 в основному є, але НЕ повністю на комутаторах Cisco 2960, які можуть працювати з VLAN. Залишок - це комутатори DLink DGS-1248, які я не впевнений, що я досить довіряю для використання з VLAN. Існує також деяка внутрішня проблема, що стосується VLAN, оскільки лише старший персонал мережі розуміє, як це працює.

Весь звичайний інтернет-трафік проходить через сервер маршрутизаторів CentOS 5, який перетворює НАТ підмережі 192.168 / 24 на підмережі 10.0.0.0/24 відповідно до ручно налаштованих правил маршрутизації, які ми використовуємо для вказівки вихідного трафіку на належне підключення до Інтернету на основі Висловлювання маршруту "-host".

Я хочу спростити це і готовий All Of The Things для віртуалізації ESXi, включаючи ці публічні послуги. Чи є рішення, яке не потребує або недороге, що позбудеться Double-NAT і поверне трохи розуму цьому безладу, щоб моя майбутня заміна не пригнала мене?

Основна схема основного офісу:

Це мої цілі:

• Загальнодоступні сервери з інтерфейсами в цій середній мережі 10.0.0 / 24 для переміщення в підмережу 192.168.2 / 24 на серверах ESXi.
• Позбудьтесь подвійного NAT і отримайте всю нашу мережу в одній єдиній підмережі. Я розумію, що це все-таки нам потрібно робити під IPv6, але я думаю, що цей безлад стоїть на шляху.

1.) Перш за все, виправте план IP-адресації. Болісно перенумерувати, але це необхідний крок для досягнення працездатної інфраструктури. Виділіть зручно великі, легко підсумовані супернети для робочих станцій, серверів, віддалених сайтів (природно з унікальними IP-адресами), мереж управління, зворотних зворотних зв'язків тощо. В RFC1918 є багато простору, і ціна потрібна.

2.) Важко зрозуміти, як розташувати L2 у вашій мережі, грунтуючись на наведеній вище схемі. VLAN може не знадобитися, якщо у вас є достатня кількість інтерфейсів у різних шлюзах, а також достатня кількість комутаторів. Після того, як ви зрозумієте номер 1, можливо, має сенс ще раз попросити питання L2. Зважаючи на це, VLAN не є особливо складним чи новим набором технологій, і це не повинно бути таким складним. Певна кількість базового навчання є в порядку, але як мінімум можливість розділити стандартний перемикач на кілька груп портів (тобто без транкінгу) може заощадити чималі гроші.

3.) Хости DMZ, ймовірно, повинні бути розміщені у власних мережах L2 / L3, а не об'єднані з робочими станціями. Ідеально, щоб ваші прикордонні маршрутизатори були підключені до пристрою L3 (інший набір маршрутизаторів? Комутатор L3?), Який, у свою чергу, з'єднав би мережу, що містить ваші зовнішні серверні інтерфейси (SMTP-хост тощо). Ці хости, ймовірно, підключаться назад до окремої мережі або (менш оптимально) до загальної серверної підмережі. Якщо ви розмістили свої підмережі належним чином, то статичні маршрути, необхідні для спрямування вхідного трафіку, повинні бути дуже простими.

3а.) Спробуйте тримати окремі мережі VPN від інших вхідних служб. Це полегшить моніторинг безпеки, усунення несправностей, облік тощо.

4.) Окрім консолідації ваших підключень до Інтернету та / або маршрутизації однієї підмережі через декілька операторів зв'язку (читайте: BGP), вам знадобиться проміжний скачок перед вашими прикордонними маршрутизаторами, щоб мати змогу належним чином перенаправляти вхідний та обмежений трафік (як Я підозрюю, що ти зараз займаєшся). Це здається більшим головним болем, ніж VLAN, але я вважаю, що це все відносно.