Почему плохая идея использовать несколько уровней NAT или нет?

Компьютерная сеть организации имеет NAT с диапазоном IP-адресов 192.168 / 16. Существует отдел с сервером, который имеет IP-адрес 192.168.xy, и этот сервер обрабатывает узлы этого отдела с другим NAT с диапазоном IP-адресов 172.16 / 16.

Таким образом, есть 2 уровня NAT. Почему у них нет подсети вместо этого. Это позволит легко маршрутизации.

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

Обновить:

@Jon Еще немного информации

В беседе с другом мы поняли, что создание подсетей вызовет следующую проблему. ARP-запросы компьютера затопят всю сеть организации. Если маршрутизатор не пересылает эти запросы, то компьютеры в одном отделе не смогут подключаться к компьютерам в других отделах, что в любом случае невозможно, если они находятся за другими NAT. С помощью анализатора пакетов мы увидели большое количество запросов ARP, так как на большинстве компьютеров в отделе включен общий доступ к файлам в Windows.

Как решить эту проблему?

Также, если два компьютера находятся за разными NAT, у них нет возможности соединиться друг с другом.

Единственная реальная проблема с выполнением многоуровневой NAT - это путаница в топологии сети. Если вы используете несколько уровней NAT, то вы выбрасываете симметричную маршрутизацию между всеми хостами в организации и также сталкиваетесь с возможностью перекрытия частных адресных пространств в вашей сети. Представьте, что вы использовали диапазон адресов на уровне n + 1 NAT, который использовался на уровне n NAT. Эти сети никогда не смогут маршрутизировать друг друга, но узлы на уровне n + 1 могут иметь тот же адрес, что и уровень n, что приводит к путанице в идентификации сервера.

Если бы я планировал топологию большой сети, я бы использовал только адреса 10. * или 172.16-24. * Для хостов в любой из наших подсетей. Затем, если какой-то отдел или частное лицо хотели бы удвоить NAT, они могли бы (используя сеть 192.168. *), Понимая, что они несут ответственность за сеть за своим узлом NAT. Я также был бы более склонен создавать больше подсетей, чем позволять любой из этих сетей с двойным NAT становиться слишком большими.

Проблемы с многоуровневым 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 дополнительную работу по переводу (по сравнению с простой пересылкой пакетов согласно базовой таблице маршрутизации ) может замедлить передачу через них вниз. Для доступа в Интернет это вряд ли будет проблемой (ваше сетевое соединение будет узким местом), но поскольку вы выполняете NAT между локальными сетевыми сегментами, это может стать весьма заметным.

Потеря производительности / скорость действительно зависит от качества используемого маршрутизатора.

Что касается хорошей / плохой идеи, я против, когда можно просто использовать маршрутизацию, однако, это действительно зависит от среды и того, чего вы пытаетесь достичь.

Если на машинах когда-либо нужно запускать только несколько вещей, которые совместно используются стандартными портами, вы можете перейти к устройству, предоставляющему маршрутизатор / 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 и, следовательно, не соответствует отображению «один к одному», вам необходимо настроить переадресацию портов, чтобы это работало - это было бы плохо.

Как уже говорилось в ad naseum, NAT - это вообще плохо, поскольку он нарушает сетевую функциональность, мы используем только потому, что должны. Ролл на IPv6.

* Конечно, вещательные экспедиторы / реле / ​​помощники существуют