Як запобігти затримкам, пов’язаним із записами IPv6 AAAA?

Наші сервери Windows реєструють AAAAзаписи IPv6 на наших серверах Windows DNS. Однак у нас не ввімкнено маршрутизацію IPv6 у нашій мережі, тому це часто спричиняє поведінку застою.

Microsoft RDP - найгірший злочинець. Під час підключення до сервера, який має AAAAзапис у DNS, клієнт віддаленого робочого столу спершу спробує IPv6 і не повернеться до IPv4, поки не закінчиться час з'єднання. Користувачі живлення можуть обійти це, підключившись безпосередньо до IP-адреси. Вирішення IPv4 адреси ping -4 hostname.fooзавжди працює миттєво.

Що я можу зробити, щоб уникнути цієї затримки?

• Вимкнути IPv6 на клієнті?
  • Ні, Microsoft каже, що IPv6 є обов'язковою частиною операційної системи Windows.
  • Занадто багато клієнтів, щоб забезпечити це встановлено скрізь послідовно.
  • Пізніше виникне більше проблем, коли ми нарешті реалізуємо IPv6.
• Вимкнути IPv6 на сервері?
  • Ні, Microsoft каже, що IPv6 є обов'язковою частиною операційної системи Windows.
  • Потрібен незручний злом реєстру, щоб вимкнути весь стек IPv6.
  • Переконатися, що це правильно встановлено на всіх серверах, незручно.
  • Пізніше виникне більше проблем, коли ми нарешті реалізуємо IPv6.
• Маскувати записи IPv6 на DNS-рекурсорі facnig?
  • Ні, ми використовуємо NLNet Unbound, і це не підтримує .
• Запобігти реєстрації записів IPv6 AAAA на сервері Microsoft DNS?
  • Я не думаю, що це навіть можливо.

На даний момент я розглядаю можливість написання сценарію, який очищає всі записи AAAA з наших DNS-зон. Будь ласка, допоможіть мені знайти кращий шлях.

ОНОВЛЕННЯ: Розв’язання DNS не є проблемою. Як у своїй відповіді вказує @joeqwerty, записи DNS повертаються миттєво. І відразу, Aі AAAAзаписи доступні. Проблема полягає в тому, що деякі клієнти ( mstsc.exe) бажано спробують з’єднатися через IPv6 та пройдуть деякий час, щоб повернутися до IPv4.

Це здається проблемою маршрутизації. pingКоманда виробляє «Загальні несправності» повідомлення про помилку , так як адреса призначення немаршрутізіруемий.

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Я не можу отримати пакетне захоплення такої поведінки. Запуск цієї (невдалої) команди ping не створює жодних пакетів у Microsoft Network Monitor. Аналогічно, спроба з'єднання з mstsc.exeхостом із AAAAзаписом не створює трафіку, доки не зробиться резервне відновлення до IPv4.

ОНОВЛЕННЯ: Всі наші господарі використовують IPv4-адреси, що розгортаються загалом. Я думаю, що ця проблема може звестись до зламаної конфігурації 6to4. 6to4 поводиться по-різному на хостах із загальнодоступними IP-адресами та RFC1918 адресами.

ОНОВЛЕННЯ. У моїй мережі, безумовно, є щось рибне з 6to4. Коли я відключаю 6to4 на клієнті Windows, з’єднання вирішуються миттєво.

netsh int ipv6 6to4 set state disabled

Але як говорить @joeqwerty, це лише маскує проблему. Я все ще намагаюся з’ясувати, чому зв’язок IPv6 у нашій мережі зовсім не працює.

Це питання досить цікаве, і я повинен визнати, що я ніколи не бачив такої поведінки. Здійснюючи деякі обміри, щоб спробувати і зрозуміти це краще, я взяв фрагмент запиту nslookup для одного з моїх серверів RDS W2K8R2 з іншого сервера W2K8R2, і я також захопив фрагмент сеансу RDP на той же сервер RDS з того ж тестового сервера . Nslookup не показав затримки з поверненням запису IPv6, а nslookup показав запит мого тестового сервера для запису IPv4 перед запитом для запису IPv6. Дельта часу в захопі не показує помітної затримки (що я можу встановити) в будь-якому запиті.

EDIT

Тепер ви на щось.

Переконайтеся, що ви збираєте трафік для адаптера 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-клієнт Майкрософт - це один із прикладів клієнтської програми, яка витончено не вирішує проблеми маршрутизації 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, поки вони знову не налаштують свій маршрутизатор.