Вкратце мой вопрос: «Что лучше? Назначать частные IP-адреса общедоступным серверам и выполнять NAT, или назначать им общедоступные IP-адреса без необходимости NAT»?
NAT может быть полезен для пользователей, позволяя многим пользователям получать доступ к Интернету, используя небольшой пул общедоступных IP-адресов (может быть только один IP). Это также называется PATing.
Я обсуждаю NAT для IP-адресов общедоступных серверов, таких как: DNS, веб-серверы, серверы электронной почты и т. Д. Преобразование общедоступных серверов должно выполняться с использованием статического NAT. Итак, кто-то может подумать об устранении процесса NAT и назначении общедоступных IP-адресов на серверах. Вот сравнение двух сценариев.
С NATing:
+ Общедоступные IP-адреса управляются и используются на шлюзе по назначению.
+ Публичные IP-адреса сохраняются и могут использоваться максимально эффективно.
- Небольшие накладные расходы будут добавлены на маршрутизатор / межсетевой экран шлюза.
- Частные IP-адреса могут быть открыты извне (например, в заголовках электронных писем или при неправильной настройке).
- Нам нужно создать два представления для DNS-серверов (частное для внутренних пользователей и общедоступное для внешних пользователей).
Без NAT:
- Назначение более одного IP-адреса серверу должно выполняться на самом сервере. Приложение / служба должны знать, что использовать все IP-адреса для исходящего трафика.
- Публичные IP-адреса назначаются серверам напрямую. Таким образом, некоторые IP-адреса могут быть потрачены впустую (не использоваться), например, в случае кластера и VIP.
+ Маршрутизация / пересылка будет немного быстрее, так как мы не используем NAT (меньше накладных расходов).
+ Все коммуникации будут осуществляться с использованием публичных IP-адресов.
+ Одного просмотра DNS будет достаточно, так как мы используем одни и те же IP-адреса для внутреннего и внешнего.
Любые другие идеи / предложения ??
Хорошо, об этом спросили пару дней назад, и уже есть принятый ответ.
Будьте проще, сэр. Вообще говоря, один общедоступный Интернет-сервер должен иметь один общедоступный IP-адрес.
С NAT: общедоступные IP-адреса сохраняются и могут использоваться с максимальной эффективностью.
ИМХО немного подлый. Хорошо, это правда, но IP v4 - нет который дефицитных, и, кроме того, вы не обязаны устранять "нехватку адресов" в Интернете.
Без NAT: Назначение более одного IP-адреса для сервера должно выполняться на самом сервере. Приложение / служба должны знать, что использовать все IP-адреса для исходящего трафика.
Зачем назначать несколько IP-адресов? Если у вас несколько служб, используйте DNS CNAMES и диапазоны IP-портов, чтобы разделить их. Если вам нужно сохранить IP-адреса при создании плавающих IP-адресов (VIP), вы часто можете использовать частные IP-адреса для машинно-зависимых IP-адресов и просто использовать общедоступные IP-адреса для фактических виртуальных IP-адресов, на которых вы публикуете Интернет-приложения.
На мой взгляд, это в основном сводится к:
С NAT вы получаете некоторую безопасность через скрытность. Это мало что значит.
Без NAT вы следуете замыслам дизайна Интернета. Общие инструменты устранения неполадок, такие как Ping и т. Д., Работают должным образом. Системные администраторы на других сайтах и вышестоящие интернет-провайдеры могут лучше работать вместе с вами для решения проблем.
Я предпочитаю один общедоступный IP-адрес на сервер, если только нет каких-либо локальных ограничений, которые заставляют меня поступать иначе.
Я решительно поддерживаю подход NAT. Как вы говорите, более эффективно сохраняет общедоступный IP-адрес, и, кроме того, вы не предоставляете какие-либо службы внешнему миру, пока не будете намеренно готовы сделать это - вы можете назначить общедоступный адрес, связанный с вашим процессом, для утверждения набора правил брандмауэра для данный сервер.
По крайней мере, с используемым нами маршрутизатором Cisco накладные расходы на NAT незначительны по сравнению с накладными расходами на использование модуля межсетевого экрана. вообще, и поскольку мы уже используем это, проблема с производительностью не имеет большого значения. Он также имеет дополнительное правило автоматической перезаписи, так что доступ к внешним адресам из внутренних сетей перезаписывается на внутренний адрес «магическим способом», что позволяет избежать необходимости разделения DNS. (Мы используем поддомен .int для внутреннего 10.x адреса).
@mattdm: Использование NAT без брандмауэра не очень разумно (также известное как «безопасность» через неизвестность).
При использовании NAT вам не нужно внутреннее представление для DNS, если вы используете отражение NAT (или шпильку NAT).
Что касается вашего вопроса, я бы сказал, что это вопрос предпочтений.
Есть ли у вас планы по сохранению IP-адресов?
У вас есть несколько компьютеров, которые предоставляют одни и те же услуги, которые должны быть доступны извне с использованием стандартных портов?
Насколько важен ваш маршрутизатор в качестве шлюза?
Я предполагаю, что ответы на эти вопросы помогут вам определить, по какому пути идти. Просто помните, что в любом случае это не имеет большого значения и не помешает вам использовать другую стратегию позже.
У меня были проблемы со сценарием «Без натяжек».
Ваши внутренние клиенты могут в конечном итоге попытаться подключиться к внутренним серверам с их общедоступными IP-адресами. Это может привести к тому, что трафик будет перенаправлен из внутренней сети на маршрутизатор, а затем обратно в сеть - или может полностью выйти из строя в зависимости от того, как настроена ваша маршрутизация.
Вы должны быть осторожны, чтобы внутренние клиенты всегда получали внутренний IP, иначе вы потеряете преимущество «маршрутизация / пересылка будет немного быстрее».
РЕДАКТИРОВАТЬ Возможно, я плохо объяснил вышесказанное. Внутренняя сеть имеет частные IP-адреса. При решении сделать некоторые серверы общедоступными, им были назначены как частные, так и общедоступные IP-адреса, а маршрутизатор / брандмауэр был настроен на пропуск трафика для этих общедоступных IP-адресов.
Проблемы возникли с внутренними клиентами на частных IP-адресах, пытающимися получить доступ к внутренним серверам через общедоступные IP-адреса. Это было несколько лет назад, и я думаю, что DNS и / или маршрутизация были неправильно настроены - поэтому для этой сети внутренние клиенты начинали обращаться к одному серверу по внутреннему IP-адресу.
Когда первый сервер пытался перенаправить пользователя на другой сервер, возникла некоторая путаница с внутренними / внешними именами и IP-адресами. Часто сервер указывал внутреннему клиенту на общедоступный IP-адрес, и клиент предполагал, что он исходил через маршрутизатор. Маршрутизация от частного IP-адреса к общедоступному IP-адресу не была настроена должным образом, и это оказалось неудобным.
В качестве альтернативы сервер будет указывать клиенту на другой сервер по его внутреннему имени / IP, и внутренний клиент будет работать нормально, но внешние клиенты - нет.
Это возможно чтобы эта настройка работала должным образом, но необходимо тщательно продумать, как расположить внутреннюю сеть.
IIRC проблемы были решены путем обеспечения того, чтобы у общедоступных серверов были частные IP-адреса, а не отдельной внутренней подсети для внутренних клиентов, и обеспечения правильной настройки маршрутизации на шлюзе клиентов по умолчанию.
Я не говорю, что не делайте этого, я просто добавляю то, что следует учитывать.