IPv6 в Microsoft Azure

Висловлюємо подяку за підготовку статті Михайлу Тряхову (@PerseptronYar з компанії Akvelon (Ярославль) за допомогу в написанні цієї статті. Михайло працює в команді розробників Microsoft Azure CLI (Command Line Interface) зі спеціалізацією на Networking Services.
Всім привіт! Сьогодні настав час поговорити про довгоочікуване нововведення, яке, з димом і спешкою, підготували-таки до конференції Ignite. Ця подія пройшла 28 по 30 вересня в Атланті, і про нього вже распрекрасной написано, скажімо, тут. Тим не менш, вже відомо, що IPv6 став доступний в цілому ряді регіонів (location) Microsoft Azure. Подробиці під катом. <habracut/>
Сказати, що даний функціонал очікуємо — нічого не сказати. Варто, для початку, вбити в пошуковику "Azure IPv6". Анонсирую: ви знайдете лише пару-трійку посилань, в основному крутяться навколо Feature requests (наприклад, тут, тут) і обіцянок компанії. І ось, відбулося!

IPv4 і IPv6 — абсолютно різні і ніяким чином не залежать один від одного версії IP. Тобто мається на увазі, що неможливо конвертувати IPv4 адреса в IPv6 і т. п. Основним завданням, яку IPv6 починає вирішувати — забезпечення взаємодії виртаульных машин Azure та IPv6-клієнтів, інтегруючи це з різноманіттям доступних в NRP (Network Resource Provider) сервісів, таких, як Load balancer (балансувальник навантаження), NIC (Network Interface, інтерфейс мережі), public ip (публічні IP-адреси) і похідні.
Не можу не запропонувати, заради інтересу, спробувати в справі частина описуваних в пості команд на платформі Microsoft CLI. Як я вже писав у першій оглядовій статті в даному блозі — це розширення командного рядка, що дозволяє керувати інфраструктурою Azure на безлічі операційних систем (Windows, Mac, багато дистрибутиви Linux). Щоб встановити її, можна скористатися інструкцією на офіційному сайті. Зверніть увагу, що встановлена версія повинна бути випущена після 28 вересня 2016 року. Потрібний реліз доступний за адресою.
Порисуем. На малюнку зобразимо синім були досі можливості кастомізації балансувальника, зеленим — оновлення, які стали доступними.

Опишу основні плюшки, які нам це несе:
  • Радість у IOT-розробників і не тільки — підтримка "dual-stack" (IPv4+IPv6)
  • Azure DNS відтепер підтримує IPv4 набори записів типу A і IPv6 типу AAAA
  • Багато оновлені образи віртуальних машин з операційною системою Linux вже підтримують даний функціонал з коро. У деяких випадках, необхідно звернутися до DHCP
Існує і ряд обмежень. Наприклад, зробити дані модифікації з використання IPv6 ми вже не зможемо через графічний інтерфейс. Як я вже писав раніше, працювати з JSON і консолями доведеться більше і більше. Так і тут, варіантів залишається небагато:
Для початку, в обраній групі ресурсів (йдеться, як Ви зрозуміли, йде виключно про ARM), необхідно налаштувати мережу, підмережі та створити "порожній," load balancer. Засобами Azure CLI для цього достатньо виконати команди зі згаданого вище руководства. Я буду спиратися на наведений там (як і з PowerShell, template) приклад, сконцентрувавшись на важливі (з точки зору даної теми) моментах. Мета наступних абзаців — максимально детально розібрати процес розгортання зазначеної архітектури та описати наявні обмеження.
Оскільки всі три доступних нам способу забезпечити підтримку IPv6 не миттям, так катанням зводяться до того, що лише відправляють відповідної API-версії Azure SDK сформований JSON, то саме роботу з JSON-шаблонами я і вважаю найбільш вірним демонструвати, зосередившись на нововведення.
Налаштування Public IP
Отже, згідно з намальованою вище схемою, ми робимо PUT запити і отримуємо два public IP:
{
"name": "myIPv4Vip",
"id": "/subscriptions/{guid}/resourceGroups/rg1/Microsoft.Network/publicIpAddresses/ip1",
"location": "West US",
"tags": { "key": "value" } ,
"etag": "W/\"00000000-0000-0000-0000-000000000000\"",

"properties": { 
"provisioningState": "Updating|Deleting|Failed|Succeeded",
"ipAddress": "1.1.1.1",
"publicIpAddressVersion": IPv4,
"publicIPAllocationMethod": "Static | Dynamic",
"idleTimeoutInMinutes": 4,
"ipConfiguration": { "id": "/subscriptions/{guid}/../Microsoft.Network/loadbalancers/MyIpV4AndV6LB1/ipConfigurations/frontendIP1"},
"dnsSettings": 
{ 
"domainNameLabel": "mylabel",
"fqdn": "mylabel.westus.cloudapp.azure.com.",
"reverseFqdn": "коваленко.com."
}
}
}

Тут прошу звернути увагу на ряд моментів
  • Наведений location — один з небагатьох, які підтримуються на даний момент. Я правда дуже намагаюся відкрити джерело з актуальними даними з цього питання.
  • publicIpAddressVersion = IPv4 йде за замовчуванням
{
"name": "myIPv6Vip",
"id": "/subscriptions/{guid}/resourceGroups/rg1/Microsoft.Network/publicIpAddresses/myIPv6Vip",
"location": "West US",
"tags": { "key": "value" } ,
"etag": "W/\"00000000-0000-0000-0000-000000000000\"",

"properties": { 
"provisioningState": "Updating|Deleting|Failed|Succeeded",
"ipAddress":"2015::1234:5": ,
"publicIpAddressVersion": IPv6,
" publicIPAllocationMethod ": " Static|Dynamic",
"idleTimeoutInMinutes ": 4,
"ipConfiguration": { "id": "/subscriptions/{guid}/../Microsoft.Network/loadbalancers/MyIpV4AndV6LB1/ipConfigurations/frontendIP2"},
"dnsSettings": 
{ 
"domainNameLabel": "mylabel",
"fqdn": "mylabel.westus.cloudapp.azure.com.",
"reverseFqdn": 
},
}

Тут є ряд обмежень
  • dnsSettings.fqdn — доступне лише для читання властивість у форматі FQDN, тобто в нашому прикладі — contoso09152016.westus.cloudapp.azure.com.
  • DNS settings reverse FQDN не вказується, оскільки на даний момент (і в найближчій перспективі) Azure DNS не планує підтримувати зворотні запити для IPv6. Значення буде порожнім (null/not allowed).
  • IP-адреса буде доступний тільки для читання
  • Public IP Allocation Method: При вказівці Static буде створено зарезервований віртуальний IP-адреса (reserved VIP), тобто VIP залишається незмінним балансировщиках навантаження. Якщо ж параметр вказаний як Dynamic, то значення IP-адреси може змінитися при прив'язку цієї адреси до іншого балансировщику навантаження.
  • IPv6 можна тільки при створенні нових екземплярів Public IP. Змінювати вже існуючі з IPv4 на IPv6, на жаль, неможливо.
Налаштування Load Balancer
Наступним важливим кроком у розборі наведеної архітектури буде настройка балансувальника навантаження. Він буде очікувано великим — прошу в гості подивитися презентаційний варіант PUT і GET запитів.
Відновити їх повністю ви легко зможете, виконавши дії, згідно документації по будь-якій з платформ, наприклад моя рідна Azure CLI.
Звернемо увагу на наступні моменти.
Frontend IP Configuration-Public IP (VIP)
Якщо конфігурація Frontend IP посилається на публічний (public) IP-адреси з версією ipVersion = IPv6, будуть виконані наступні перевірки:
  1. Повинна існувати інша конфігурація Frontend IP, що реалізує версію IPv4.
  2. Subnet (підмережа з приватним frontend-адресою для балансувальника) не може бути зазначена, оскільки у разі IPv6 внутрішній балансувальник навантаження (internal load balancer, ILB) не підтримується. Отже, всі асоційовані дані (приватний IP-адресу, allocation method) будуть порожні (null/not allowed).
  3. Тільки один віртуальний IP-адреса (VIP) версії IPv6 може бути створено в рамках балансувальника навантаження.
Backend Address Pools (Backend)
Валідація полягатиме у перевірці налаштувань інтерфейсу мережі (NIC). Кожен примірник backend adress pool-a може посилатися на NIC лише з одним типом підтримуваних адрес — небудь IPv4 або IPv6.
Load Balancer Rule (FE <-> BE)
Якщо конфігурація Frontend IP посилається на публічний (public) IP-адреси з версією ipVersion = IPv6, мають місце наступні обмеження:
  1. Backend адреси посилаються на IPv6 конфігурацію NIC.
  2. Probe балансувальника навантаження не підтримується для версії IPv6
Inbound NAT pools не можуть містити конфігурацію, що посилається на IPv6 VIP.
Inbound NAT rules повинні задовольняти умові, що конфігурації Frontend IP і Backend IP повинні бути версії IPv6.
Outbound NAT Rules
  1. Може містити правила, засновані на версії IPv6, за умови, що на віртуальну IP-адресу цієї версії посилається конфігуратор frontend IP.
  2. У цьому випадку backend-конфігуратор також повинен ґрунтуватися на IPv6.
  3. В рамках балансувальника (load balancer) припустимо лише один віртуальний IP-адреса версії IPv6 .
Ну і, як говорилося вище, в існуючій конфігурації неможливо оновити версію IP-адрес (IPv4->IPv6).
Налаштування Network interface
Тут я також пропоную звернутися безпосередньо до прикладу конфігурації інтерфейсу мережі
{
"name": "mynic1", 
"id": "/subscriptions/{guid}/resourceGroups/myrg1/providers/Microsoft.Network/networkInterfaces/vm1mynic1",
"location": "West US",
"tags": { "key": "value" } ,
"etag": "W/\"00000000-0000-0000-0000-000000000000\"",

"properties": { 
"provisioningState": "Updating|Deleting|Failed|Succeeded",
"virtualMachine": {"id": "/subscriptions/{guid}/../Microsoft.Compute/virtualMachines/vm1"},
"macAddress": "BC-31-5B-E2-EE-B1"
"networkSecurityGroup":{"id":"/subscriptions/{guid}/../Microsoft.Network/networkSecurityGroups/myNSG1" },
"ipConfigurations": [
{
"name": "myIPv4IP1",

"properties": { 
" privateIpAddressVersion ": IPv4 
"subnet": {"id": "/subscriptions/{guid}/../Microsoft.Network/virtualNetworks/myvnet1/subnets/mysub1"},
"privateIPAddress": "10.0.0.8",
"privateIPAllocationMethod": "Static | Dynamic",
"publicIPAddress": {}
"loadBalancerBackendAddressPools": [ 
{"id": "/subscriptions/{guid}/../Microsoft.Network/loadBalancers/mylb1/backendAddressPools/IPv4BackendPool1"}
],
"loadBalancerInboundNatRules": [
]
}
}, 
{
"name": "myIpV6Ip1",
"id": "/subscriptions/{guid}/../Microsoft.Network/networkInterfaces/vm1mynic1/ipConfigurations/ myIpV6Ip1",
"etag": "W/\"00000000-0000-0000-0000-000000000000\"",
"properties": { 
"provisioningState": "Updating|Deleting|Failed|Succeeded",
" privateIpAddressVersion ": IPv6, 
"subnet":
"privateIPAddress ": 
"privateIPAllocationMethod": Dynamic",
"publicIPAddress": 
"loadBalancerBackendAddressPools": [ 
{"id": "/subscriptions/{guid}/../Microsoft.Network/loadBalancers/myIPv6lb1/backendAddressPools/IPv6BackendPool1"}
],
"loadBalancerInboundNatRules": []
}
}
],
"dnsSettings": 
{
"dnsServers": ["1.0.0.1","2.0.0.2"],
"appliedDnsServers": ["1.0.0.1","2.0.0.2", "3.0.0.3"]
},
"enableIPForwarding": false
}
}

Вибір версії IPv6 накладає наступні обмеження:
  1. NIC повинен бути новим, або не прив'язаним до вже існуючої віртуальній машині.
  2. Набір конфігурацій інтерфейсу мережі повинен мати хоча б один з версією ipVersion = IPv4.
  3. Вибраний NIC — єдиний у віртуальної машини з версією ipVersion = IPv6. Multi-NIC тут на даний момент відсутня.
  4. privateIPAllocationMethod=Dynamic — єдине допустиме значення.
  5. Закритий IP-адреса недоступний в IPv6.
  6. Неможливо оновити існуючу віртуальну машину на підтримку IPv6 замість IPv4.
Сподіваюся, наведені відомості допоможуть Вам успішно подолати всі складнощі, які можуть виникнути при початку роботи з IPv6 Azure.
Погляд у майбутнє
Якщо говорити про майбутнє — на даний момент, на жаль, я не можу сказати, коли будуть зроблені оновлення, які виправляють досить кусючі обмеження і коли ця стаття стане марною. Поки немає інформації ні від команди Microsoft DNS, ні від NRP (Network Resource Provider). Буде можливість більш лагідною міграції існуючих інфраструктур? Для мене ці питання також відкриті.
Якщо говорити про те, що я все ж знаю:
  • Всі так чи інакше рухається до повного паритету в підтримці IPv4, IPv6 і IPv4+IPv6.
  • мережі та Мережі почнуть підтримувати IPv6 — йде спекотна робота, і при першій можливості я цими радощами з Вами поділюся.
Дякую за увагу, звертайтеся по виниклих питань.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.