Как предотвратить задержки, связанные с записями IPv6 AAAA?

Это довольно интересный вопрос, и я должен признать, что никогда не видел такого поведения. Поработав немного, чтобы попытаться лучше понять это, я взял фрагмент запроса nslookup для одного из моих серверов RDS W2K8R2 с другого сервера W2K8R2, а также захватил фрагмент сеанса RDP на тот же сервер RDS с того же тестового сервера. . Nslookup не показал задержки при возврате записи IPv6, а nslookup показал, что мой тестовый сервер запрашивает запись IPv4 перед запросом записи IPv6. Дельта времени в захвате не показывает заметной задержки (которую я могу установить) ни в одном запросе.

РЕДАКТИРОВАТЬ

Теперь вы кое-что знаете.

Убедитесь, что вы захватываете трафик для адаптера Microsoft 6To4, иначе вы не увидите IPv6:

Вот результат nslookup для моего сервера RDS. Обратите внимание на адреса IPv6:

Вот фрагмент моего захвата:

И наконец, вот отрывок из netstat, показывающий соединение:

Итак, ясно, как вы подтвердили, проблема не в разрешении DNS. Проблема в том, что соединение RDP предпочитает IPv6 вместо IPv4 (что является значением по умолчанию для Windows - Windows предпочитает IPv6 вместо IPv4), и поскольку IPv6 не работает должным образом, это вызывает задержку (как вы заявили) при откате с IPv6 на IPv4. Вы можете исправить это, настроив клиентов так, чтобы они предпочитали IPv4 IPv6, но я думаю, что это просто маскирует проблему. Лучшим решением было бы выяснить, почему IPv6 не работает, и исправить это. Я недостаточно знаю об IPv6, чтобы помочь, но я предполагаю, что записи IPv6, возвращаемые DNS, являются «локальными» адресами, действительными только в той подсети, где существуют хосты RDS, и поскольку клиенты находятся в другой подсети, они могут ' t достичь этих адресов IPv6.

Технология перехода IPv6 под названием 6to4 является печально известный для создания таких проблем. Здесь действуют несколько факторов. По отдельности они безвредны, но в совокупности конечные пользователи могут испытывать задержки подключения.

Список благоприятных факторов и соображений по их смягчению представлен ниже.

Windows включает 6to4 по умолчанию

Если на ваших хостах установлена ​​последняя версия Windows (Vista или более поздняя), Windows по возможности включает туннелирование 6to4, когда доступен общедоступный адрес IPv4. Что особенно важно, это касается как серверов, так и клиентов.

Чтобы узнать, использует ли система 6to4, запустите ipconfig и найдите IPv6-адрес, который начинается с префикса 6to4 2002:. Это выглядело бы примерно так.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• Если ваши конечные точки подключены к Active Directory, вы можете использовать групповую политику для отключения протоколов перехода, таких как 6to4 и Teredo. Это хорошо задокументировано в KB929852. (Применить это либо к вашим клиентам, либо к серверам будет достаточно, но если вы делаете этот шаг, вероятно, имеет смысл отключить его везде, на обоих клиентах. и серверов.)
• Если вы управляете только несколькими хостами, вы можете отключить 6to4 в каждом конкретном случае. Это намного лучше, чем полное отключение IPv6. netsh int ipv6 6to4 set state disabled
• Используйте другую клиентскую операционную систему. Например, в Mac OS X по умолчанию не включен 6to4.

Используются общедоступные маршрутизируемые адреса IPv4

6to4 работает только на хостах с общедоступными адресами IPv4, поэтому эта проблема никогда не затрагивает хосты за брандмауэром NAT.

• Вы можете переместить клиентов и / или серверы за брандмауэр NAT и начать использовать адресацию RFC1918. Но в некоторых случаях действительно предпочтительны общедоступные маршрутизируемые адреса. Изменение адресации всей сети также может быть нереальным выбором.

6to4 некорректно работает в сети

Устранение неполадок 6to4 в режиме Anycast крайне сложно. Это настолько неприятно, что в IETF поступил официальный запрос 6to4 следует реклассифицировать как историческое. По мнению автора, 6to4 устарел.

Вкратце, 6to4 работает путем инкапсуляции пакетов IPv6 в пакеты IPv4 с использованием протокола под названием 6in4 (протокол IP = 41). Пакеты IPv4 адресованы на произвольный адрес. 192.88.99.1 в надежде, что он достигнет работающего реле 6to4 где-нибудь в Интернете. Если вам повезет, это может быть даже географически поблизости.

На практике некоторые реле 6to4 настроены неправильно, а многие сети даже не позволяют трафику 6in4 проходить через межсетевой экран. Обычно это происходит, когда межсетевой экран разрешает весь исходящий трафик, но явно не разрешает пакетам IP-протокола 41 возвращаться через межсетевой экран. (TODO обратите внимание на соответствующий RFC для устранения неполадок.) Этот сбой («входящая черная дыра») и многие другие описаны в RFC 6343.

• Настройте брандмауэр на громкое отклонение протокола IP 41 (со сбросом TCP) при отправке с внутренних узлов вашей сети. Это должно привести к «быстрому отказу» поведения, которое имеет больше смысла, чем недетерминированные задержки соединения. Это было продемонстрировано для работы в ограниченных тестовых средах.
• Попросите своего интернет-провайдера или поставщика услуг транзита с первым переходом настроить работающее реле 6to4. Если все будет сделано правильно, конечные пользователи получат наилучшие впечатления. Любой конечный пользователь с общедоступным маршрутизируемым IPv4-адресом сможет участвовать в Интернете IPv6.

Динамическая регистрация DNS

В типичной среде Active Directory каждому компьютеру разрешается регистрировать свои собственные адреса на DNS-сервере. Когда хост является многосетевым, он зарегистрирует все свои адреса даже из туннеля 6to4.

Большинство интернет-сервисов не используют динамический DNS, поэтому эта проблема обычно ограничивается корпоративными сайтами, где все клиенты и серверы являются «внутренними» в одной сети.

• Вы можете отключить динамическое обновление DNS. Тогда, если вы не поместите записи ресурсов AAAA в файл зоны, они никогда не будут обслуживаться. Однако динамический DNS часто желателен для внутренних DNS-серверов. (Если вы это сделаете, не забудьте также удалить все записи AAAA, которые могут уже присутствовать.)
• Настройте DNS-сервер так, чтобы он не отвечал на записи ресурсов AAAA. Но не делайте этого, потому что это действительно доставит вам проблемы, когда вы захотите начать внедрять IPv6. (Кто-нибудь знает о бесплатном брандмауэре DNS с открытым исходным кодом?)

Клиентское приложение не выходит из строя корректно

Клиент RDP от Microsoft является одним из примеров клиентского приложения, которое не решает проблемы маршрутизации IPv6. Большинство веб-браузеров лучше справляются с пограничными случаями IPv6, подобными этому, поэтому они не проявляют такого поведения.

• Попробуйте использовать другой клиент. Может тебе повезет.

Я понимаю, что в этой ситуации это не очень помогает, но для разработчиков, которые сталкиваются с подобной дилеммой, есть метод реализации, известный как "Счастливые глазные яблоки" (RFC 6555), который определяет метод одновременного подключения к ipv4 и ipv6 и выбора того, что подключается первым.

Вот мое решение. По умолчанию Windows дает маршрутам IPv6 более высокий приоритет, чем маршрутам IPv4. Если вы измените политику префикса IPv6, вы можете изменить это поведение, чтобы использовать IPv4 вместо IPv6.

Чтобы убедиться, что все системы в моей сети настроены одинаково, я помещаю следующие команды в сценарий .bat, запускаемый во время установки программного обеспечения после сборки или восстановления машины.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

Чтобы объяснить, что это делает:

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

Второй блок команд удаляет все существующие политики префиксов маршрутизации IPv6.

Затем третий блок воссоздает политики префиксов IPv6, но использует другой набор приоритетов. Таким образом, префиксу, соответствующему IPv4, отдается предпочтение перед IPv6, и тогда машина захочет использовать IPv4, если приложение не укажет использование IPv6.

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

Я считаю, что использование в операционных системах IPv6 вместо IPv4 на самом деле препятствует их принятию. В переходный период будут моменты, когда хост думает, что у него есть возможность подключения по IPv6, но на самом деле у него нет полностью функционального соединения, что приводит к сбоям в работе программного обеспечения и большим задержкам. Многие люди, которых я знаю, полностью отключили IPv6 на своем маршрутизаторе в качестве обходного пути для интернет-провайдеров, развертывающих IPv6 неработоспособным образом до установления полного подключения, и эти люди просто забудут снова включить его, оставив их без IPv6, пока они снова не перенастроят свой маршрутизатор.