Назад | Перейти на главную страницу

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

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

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

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

Обновить:

@Jon Дополнительная информация

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

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

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

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

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

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