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

Миграция корпоративного IPv6 - конец proxypac? Начало точка-точка? + 10К пользователей

Начнем со схемы:

Мы видим "типичную" корпоративную сеть IPv4 с:

На всех компьютерах есть файл proxy.pac, в котором указано, какой прокси использовать или подключаться напрямую. Компьютеры имеют доступ только к локальному DNS (например, без разрешения имен для google.com).

Кстати ... Компания не соблюдает RFC1918 внутренне и использует публичные адреса! (историческая причина). Использование интернет-прокси явно позволяет избежать проблем.

Что, если мы перейдем на IPv6?

Шаг 1: доступ в Интернет по IPv6

Доступ в Интернет в IPv6 прост. Действительно, просто подключите прокси в Интернете IPv4 и IPv6. Во внутренней сети делать нечего:

Шаг 2: IPv6 И IPv4 во внутренней сети

А почему бы не использовать полную сеть IPv6 напрямую? Потому что всегда есть старые серверы, не поддерживающие IPv6 ..

Вариант 1: та же архитектура, что и в IPv4 с прокси pac

Это, наверное, самое простое решение. Но разве это лучшее?

Думаю переход на IPv6 - это возможность не заморачиваться с этим pac прокси!

Вариант 2: Новая архитектура с прозрачным прокси, без proxypac, рекурсивный DNS

О да!

В этой новой архитектуре у нас есть:

Вопросы

Спасибо! Не стесняйтесь редактировать мой пост, чтобы он стал лучше.

Прозрачные прокси-серверы не работают для трафика SSL, если вы не развернете альтернативный доверенный корень для каждого устройства, поэтому вы теряете многие преимущества безопасности и аудита и вводите новые.

Я бы выбрал вариант 2, но с использованием явного прокси-сервера, отключив все остальное. Если внутренние машины не используют ваш прокси, они не получают доступа в Интернет. У вас уже должны быть инструменты для автоматического распространения конфигурации прокси с помощью сценариев, групповых политик Windows, DHCP или DNS / proxy.pac.

Чем проще, тем лучше.

Еще одна вещь, которую следует учитывать, - это поэтапный подход, при котором новая сеть хостов только для IPv6 получает доступ к старой локальной сети через NAT64 / DNS64.

Похоже, что вы захотите какое-то время использовать двойной стек. Тот же подход можно использовать для устранения несоответствия RFC1918 путем проксирования / преобразования адресов 10.x.x.x v4 в старую LAN. Предполагается, что ваши общедоступные IP-адреса взломаны. Если вы получили распределение от IANA / ARIN / и т. Д., То это не проблема.

Я бы оставил ip4 / ipv6, некоторые устройства довольно тупые и в любом случае не могут быть обновлены. Если можно разделить по vlans.

Затем используйте явно http-прокси. Не используйте прозрачный прокси. Зачем? Вы можете легко обнаружить, что неправильно настроенное приложение или устройство пытается выйти в Интернет. Следует различать «нормальный» трафик и «странный» трафик. Информация об обязательном использовании http-прокси должна быть частью обучения сотрудников.

Вы можете настроить один http-прокси, который будет перенаправлять определенные домены на другой родительский прокси (для веб-сайтов ваших конкретных клиентов). Это решает проблему с файлом pac, вы определяете в клиентских приложениях только один http прокси.

Не включайте рекурсивный DNS в вашей локальной сети! DNS-туннелирование работает! Не включайте ping вне LAN (ICMP-туннелирование), клиенты не нужны! Включите рекурсивный DNS только для вашего http-прокси или приложений, которые действительно должны делать DNS-запросы.

Согласно анализу, только 20% сетевых администраторов знают, что покидает их сеть: D

Мне очень нравится идея предоставить клиентам доступ к http [s] через удаленный клиент (RDP, Citrix ...), но это кажется довольно дорогостоящим.

Это приятное чтение - http://undeadly.org/cgi?action=article&sid=20091025011137

Я бы уступил другим вопросом. Зачем действительно прокси? Из-за несовместимости с RFC1918? Это полностью оправдывает использование прокси, когда вы решаете не перестраивать свою архитектуру IPv4 для использования адресов 10.xxx (мой интернет-провайдер раньше давал нам адреса, отличные от RFC1918, но использовал NAT, теперь у нас есть 10.xxx и, конечно, NAT) . Или вы используете прокси для кэширования / безопасности / фильтрации / аудита?

Если ответ на первый вопрос верен, то я бы выбрал очень простой вариант 1: поместите очень простой маршрутизатор IPv6 на границу, обновите свой DHCP (ы), чтобы транслировать префикс IPv6, и направьте трафик IPv6 через маршрутизатор. . Поскольку ты уже необходимо обновить ваши промежуточные маршрутизаторы (те, которые стоят между клиентскими хостами и граничным маршрутизатором), это не добавляет дополнительных затрат на оборудование.

Это дает преимущество в том, что IPv4 остается активным и доступным для машин, не поддерживающих его, и они будут вести себя так же, как и раньше.

Чтобы ответить на ваши вопросы: 1) ваш архитектурный выбор (на рисунке) показывает отсутствие поддержки IPv6 для клиентских машин, что является настоящей тратой 2) «раскрытие» IP-адресов является обычным явлением в IPv6, поскольку нет NAT. Вам просто нужно немного больше внимания уделять брандмауэру, а адреса конфиденциальности (как указано в другом ответе) защищают конфиденциальность клиентских машин от серверов вне домена.