используя 192.170.130 / 24 в качестве подсети в локальной сети
У нас есть клиент, у которого есть подсеть 192.170.130 / 24 в своей локальной сети, которая преобразуется через NAT на IP-адрес WAN от их провайдера. Это хорошая идея, или им следует использовать адреса RFC1918 в своей локальной сети?
Спасибо
Это плохая практика. Они должны использовать частный класс.
Причина в том, что это вызовет проблему, если у вашего клиента есть сервер, который отвечает на запрос WAN, поскольку сервер не будет маршрутизировать интернет-запрос, который, по его мнению, принадлежит его локальной сети.
В вашем случае ваш клиент заблокировал себя от возможного клиента из Техаса с этим диапазоном IP.
Это неортодоксально и необычно, но это не так. Я работал с несколькими клиентами, которые участвовали в этом сценарии.
Это хорошая идея? Это субъективный вопрос. У каждого будет свое мнение о том, «хорошая» это идея или нет. Обычно это считается плохой идеей.
Есть ли какая-то техническая причина для изменений? Может быть ... но, вероятно, нет. Чего бы вы хотели добиться? Какая будет конечная цель? Повышенная безопасность? RFC 1918 не о безопасности.
До RFC 1918 (да, было время до RFC 1918) каждый внутренне использовал «общедоступные» IP-адреса. См. Раздел 2 по ссылке ниже, чтобы узнать о мотивации и доводах RFC 1918:
Во-первых, я работаю в месте, которое использует большие публичные IP-адреса в своей частной сети. Тем не менее, они владеют ассортиментом. Единственная проблема, которую вы увидите помимо проблемы с брандмауэром, заключается в том, что если они когда-либо попытаются подключиться к внешнему имени DNS с диапазоном, который они используют для своего личного, у них возникнет проблема. Вы можете выполнить обратный просмотр IP-адресов с помощью nslookup на общедоступном DNS-сервере, чтобы определить, сопоставлено ли что-либо с каким-либо IP-адресом, а затем определить свое влияние. Возможно, вам понадобится сценарий поиска, потому что их много. Я видел, как люди, такие как большой университет, пытались сделать это раньше, и их частный диапазон IP перекрывался с фактическими сайтами, к которым люди пытались подключиться. Что еще хуже, диапазон охватывал их инфраструктуру AD.