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