Чому погано використовувати декілька шарів NAT чи це?

Комп'ютерна мережа організації має NAT з діапазоном IP-адрес 192.168 / 16. Є відділ із сервером, який має IP-адресу 192.168.xy, і цей сервер обробляє хостів цього відділу з іншим NAT з діапазоном IP-адрес 172.16 / 16.

Таким чином, існує 2 шари NAT. Чому натомість вони не мають підмережі. Це дозволило б легко прокладати маршрутизацію.

Я думаю, що кілька шарів NAT можуть спричинити втрати продуктивності. Не могли б ви допомогти мені порівняти дві стратегії дизайну.

Оновлення:

@Jon Ще трохи інформації

В дискусії з другом ми зрозуміли, що підмережа спричинить наступну проблему. ARP-запити комп'ютера затоплять всю мережу організації. Якщо маршрутизатор не пересилає ці запити, ПК в одному відділі не зможе підключитися до ПК в інших відділах, що все одно неможливо зробити, якщо вони стоять за різними NAT. За допомогою sniffer пакетів ми побачили, що існує велика кількість запитів ARP, оскільки для більшості комп'ютерів у відділі встановлено спільний доступ до файлів у Windows.

Як вирішити цю проблему?

Крім того, якщо два комп’ютери відстають від різних NAT, то немає ніякого способу їх з'єднання один з одним.

Єдина реальна проблема, пов'язана з тим, що робити багатошаровий NATING, полягає в тому, що це робить топологію вашої мережі заплутаною. Якщо ви використовуєте кілька шарів NAT, ви викидаєте симетричну маршрутизацію між усіма хостами в організації, і ви також стикаєтесь з можливістю перекриття приватних адресних просторів у вашій мережі. Уявіть, якби ви використовували діапазон адрес у вашому шарі NAT n + 1, який використовувався в n шарі NAT. Ці мережі ніколи не зможуть прокладати маршрут один до одного, але хости в шарі n + 1 можуть мати ту саму адресу, що і n-рівень, що робить ідентифікацію сервера заплутаною.

Якби я викладав топологію великої мережі, я би використовував лише 10. * або 172.16-24. * Адреси для хостів у будь-якій з наших підмереж. Тоді, якщо якийсь відділ або особа захотів подвоїти NAT, вони могли (використовуючи мережу 192.168. *), Розуміючи, що вони відповідально ставляться до мережі, що стоїть за своїм хостом NAT. Я також був би схильний створювати більше підмереж, ніж дозволити будь-якій з цих подвійних мереж NAT'd отримати занадто велику кількість.

Проблеми з багаторівневим NAT по суті такі ж, як і для одношарового NAT, але складні. Як от:

1. Затримка через додаткову роботу, яка виконується протягом життя пакетів (хоча це вряд ли буде суттєвим у більшості випадків)

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

3. Переадресація порту вхідного з'єднання, якщо вам потрібні вхідні з'єднання, більш легка для налаштування та обслуговування.

4. Обмежена кількість портів. NAT працює, перекладаючи адреси джерела до себе на різних портах, наприклад:

   • Машина 1 спілкується із зовнішнім веб-сервером за допомогою порту 1024, оскільки його джерело переводиться на адресу NAT-коду на, скажімо, порт 10000.
   • той же апарат робить два запити до того чи іншого веб-сервера одночасно (не незвично), використовуючи вихідний порт 1025 (два одночасних з'єднання повинні мати різні порти джерела). Поле NAT перекладає це на "мене на вихідний порт 10001"
   • інша машина переговори робить три з'єднання із зовнішніми серверами. Добре, NAT-поле перекладає їх на "мені на порти 10002, 10003 та 10004"
   • оскільки пакети повертаються у формі зовнішніх машин, коробка NAT знає, що цей матеріал, призначений для себе на порту 10000, дійсно повинен перейти на машину 1 на порт 1024 і так далі для інших активних з'єднань.

   Це все добре і безпроблемно, поки у вас не буде багато вихідних з'єднань - тобто велика мережа або менша мережа з машинами, які здійснюють безліч з'єднань (додатки P2P, як ті, що реалізують протокол bittorrent, можуть створити багато одночасних з'єднань). У протоколі IP є лише 65536 портів, за винятком 1024, які зарезервовані. Хоча 60 000 може звучати як багато, його можна швидко споживати, тоді в коробці NAT потрібно вирішити, які старі відображення можна видалити, які, як правило, не так просто, як "скинути найстаріші". Це може призвести до незвичайних помилок (випадкові з’єднання відпадають через важкі для діагностики причини) або машина просто не зможе встановити нові з'єднання на деякий час.

5. завантаження на коробки NAT. Якщо ви використовуєте невеликі ящики з низькою потужністю (наприклад, позапологові підтримуючі маршрутизатори NAT, а не повний ПК з кремезним процесором), щоб зробити ваш NAT додатковою роботою з перекладу (порівняно з простою переадресацією пакетів відповідно до базової таблиці маршрутизації ) може уповільнити передачі через них вниз. Для доступу до Інтернету це, швидше за все, не буде проблемою (ваше "мережеве з'єднання буде вузьким місцем"), але, оскільки ви здійснюєте NATING між сегментами локальної мережі, це може стати помітним.

Втрата / швидкість роботи дійсно знижується до якості маршрутизатора, який ви використовуєте.

Щодо гарної / поганої ідеї, я проти цього, коли можна просто використовувати маршрутизацію, однак, це дійсно залежить від навколишнього середовища та того, що ви намагаєтеся досягти.

Якщо машинам потрібно лише запускати кілька речей, які спільно використовуються через стандартні порти, ви можете зайти до пристрою маршрутизатора / nat і надавати правило, щоб дозволити бажане (1). Однак якщо ви збираєтеся робити багато пристрою для виконання завдань на пристрої, буде набагато простіше провести правильний маршрут, коли кожна машина має свій унікальний IP (2).

(1) Наприклад, один до багатьох - На одній машині є веб-сервер, і ви хочете поділитися ним з іншими - ви встановите правило в маршрутизаторі на порт 80 машини, а потім будь-яку машину із зовнішньої мережі (або всередині якщо увімкнено nat-loopback), можна просто перейти на http: //router.ip і отримати доступ.

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

Що стосується вашого сценарію - Якщо один відділ використовує 192.168.xx, а інший 192.168.yx, я переглянув би пристрої, і якщо немає перекриттів, можливо, можливо буде змінити підмережу з / 24 на / 16 (або навпаки), то замініть маршрутизатори комутаторами / або подібними і не втрачайте послуг.

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

@iamrohitbanga - у відповідь на ваші запитання (до коментарів).

Порівняння важко - маршрутизація добре працює в приватних мережах, де кожна машина має можливість доступу до кожної машини. Nat працює добре, але він використовується в основному для мереж, які не потребують маршрутизації, оскільки зазвичай доводиться вручну встановлювати вхідні правила / маршрути.

Наприклад, якщо у вас є підключення до Інтернету та вимкнено NAT, то вручну налаштовуйте маршрути або мостовий режим - ваша машина буде безпосередньо в Інтернеті - всі порти доступні, і будь-яка машина може робити все, що їй хочеться.

Якщо у вас є маршрутизатор, з іншого боку, з NAT, він займе зовнішній IP і надасть "Nat-ed?" (не впевнений у термінології ...) Інтернет - всі внутрішні машини мають IP-адресу, недоступного з Інтернету, але ви можете встановити правила вручну - наприклад, порт 80 на одну машину ... Це дуже добре працює для вихідних з'єднань (брандмауер правила, що дозволяють), але може бути кошмаром для встановлення правил, що надходять, якщо ви розміщуєте багато служб ... і якщо ви робите щось, що вимагає динамічних портів (ftp, Windows AD тощо), це може бути кошмаром.

Сподіваюсь, це допоможе, якщо ви хочете дізнатися що-небудь ще, сміливо запитайте.

Основна проблема з NAT (загалом і з декількома шарами конкретно) полягає в тому, що це може бути надзвичайно важко вирішити.

Найбільша проблема NAT - це коли застаріле мережеве програмне забезпечення, яке робить переклад, яке завдає шкоди багатьом програмам (FTP, VoIP тощо). Сучасні брандмауери / шлюзи мають переклади (виправлення в термінах Cisco), що робить це набагато простіше.

Я не розумію, чому ваша компанія використовує NAT між приватними підмережами. Чому б не просто прокласти його?

Просто оновіть свою мережу та клієнтів до IPV6, тоді більше не потрібно використовувати NAT.

Щоб відповісти на нову другу частину вашого питання ...

Маршрутизатори розбивають домени широкомовного зв'язку - маршрутизатори не пересилають пакети Arp, вони залишаються в підмережі *. Ваш обмін файлами Windows (серйозно?) Netbios, що транслює трафік, не залишить підмережу.

З підмережами:

Якщо вам потрібно отримати доступ до спільної мережі Windows за межами підмережі, ви можете отримати доступ до неї або безпосередньо, використовуючи її IP-адресу, або якщо у вас встановлено DNS або WINS-сервер за іменем хоста.

З NAT:

Якщо ваш NAT має тип PAT і, отже, не відображає один на один, вам потрібно буде налаштувати переадресацію портів, щоб це працювало - це було б погано.

Як вже було обговорено в рекламному середовищі, NAT в цілому погана річ, оскільки він порушує функціональність мережі, ми використовуємо лише тому, що нам потрібно. Прокат на IPv6.

* Звичайно, експедитори / ретранслятори / помічники в ефірі існують