Я читал Справочник системного администратора Debian, и я наткнулся на этот отрывок в секции шлюза:
... Обратите внимание, что NAT актуален только для IPv4 и его ограниченного адресного пространства; в IPv6 широкая доступность адресов значительно снижает полезность NAT, позволяя напрямую маршрутизировать все «внутренние» адреса в Интернете (это не означает, что внутренние машины доступны, поскольку промежуточные межсетевые экраны могут фильтровать трафик).
Это заставило меня задуматься ... С IPv6 все еще существует частный диапазон. Видеть: RFC4193. Действительно ли компании собираются настроить все свои внутренние машины с публичными адресами? Так должен ли работать IPv6?
Так должен ли работать IPv6?
Короче да. Одна из основных причин столь резкого увеличения адресного пространства с помощью IPv6 - это избавиться от таких технологий, как NAT, и упростить сетевую маршрутизацию.
Но не путайте понятия публичного адреса и общедоступного хоста. По-прежнему будут «внутренние» серверы, недоступные в Интернете, даже если у них есть публичный адрес. Они будут защищены брандмауэрами, как и IPv4. Но также будет намного проще решить, что сегодняшний сервер, предназначенный только для внутреннего использования, завтра должен открыть конкретную услугу для Интернета.
Неужели компании действительно собираются настроить все свои внутренние машины с публичными адресами?
На мой взгляд, умные будут. Но, как вы, наверное, заметили, это займет довольно много времени.
Мы используем общедоступные IPv6-адреса в сети нашей компании для всех устройств.
Мы используем брандмауэр с отслеживанием состояния на нашем шлюзе, который:
Никакой публичный трафик (кроме ICMP и установленных соединений) не должен попадать в нашу сеть.
Пока у нас не было проблем с этой настройкой, и она отлично работает.
Если нет необходимости во внешнем подключении, можно использовать частные сети. Это причина определения частного адресного пространства также в IPv6.
NAT - это хитрость, которая была изобретена для задержки исчерпания адресного пространства IPv4. NAT вызывает проблемы с приложениями, и чтобы заставить приложения работать с NAT, необходимы дополнительные взломы, которые противоречат исходному дизайну IP.
Итак, предпочтительный способ - работать так, как ответил Ярик, - использовать надлежащий межсетевой экран с отслеживанием состояния на границе сети.
Как уже говорилось, именно так был разработан IP, и он действительно работает хорошо. NAT иногда вызывает неприятные проблемы. Некоторые охарактеризовали "сокрытие" внутреннего IP-адреса NAT как преимущество, но это также может быть недостатком.
Я работал в месте с / 16, и мы использовали общедоступные маршрутизируемые адреса IPv4 на каждом устройстве (включая принтеры, мобильные телефоны и электронные часы). Он работал отлично и, кроме того, значительно упростил отслеживание некорректных пользователей и устройств. Это также ограничивало влияние этих пользователей, так что если кому-то удалось начать распространять вредоносное ПО или его поймали на торрент-загрузке, это с меньшей вероятностью повлияло (скажем) на способность ваших почтовых серверов беспрепятственно общаться из-за того, что он был в черном списке.
Сторонники IPv6 рассматривали NAT как временный взлом, чтобы облегчить исчерпание адресов IPv4, и, следовательно, NAT не потребуется с IPv6.
Однако у NAT есть несколько преимуществ, помимо остановки исчерпания адресов.
Таким образом, я ожидаю, что по крайней мере некоторые компании выберут вариант развертывания v6 с NAT так же, как они это делают для IPv4. Другие могут встать на сторону сторонников IPv6 и пойти на брандмауэры, но без преобразования адресов.
Я настоятельно рекомендую вам (и всем, кто рассматривает возможность внедрения NAT с IPv6) пересмотреть свое решение после прочтения RFC 4864 для получения совета о том, что делать вместо NAT.
Я прочитал его, но не думаю, что он полностью отображает NAT.
«Решение» IPv6 для этого является тройным: запускать несколько адресов параллельно, автоматизировать назначение динамических адресов от провайдера (ов) внутренним сетям и использовать ULA для предоставления долгосрочных локальных адресов.
Параллельное выполнение адресов с разным сроком жизни создает риск того, что непостоянные адреса случайно попадут в долговременную конфигурацию. При параллельном запуске нескольких интернет-адресов возникает проблема, связанная с тем, что клиентские операционные системы не имеют возможности знать, с какого интернет-шлюза будут отправляться их пакеты.
Делегирование префикса было надежно реализовано для одноуровневых сценариев, когда один маршрутизатор CPE запрашивает префикс у поставщика услуг Интернета и назначает его одному или нескольким локальным интерфейсам, но в настоящее время не представляется хорошей реализацией для многоуровневого делегирования внутри сети. сайт клиента.
Сторонники IPv6, похоже, не дают ответа на этот вопрос. Кажется, они просто предполагают, что несчастных случаев не будет.
Расширения конфиденциальности в некоторой степени помогают в этом, но они не скрывают подсеть и являются функцией на стороне клиента, поэтому клиентская ОС, а не сетевой администратор, выбирает, использовать они или нет.
Есть предложение назначить / 128 отдельным машинам, а затем создать записи IGP для их маршрутизации, но я не знаю, чтобы кто-нибудь действительно реализовал это на практике.