Корпоратив желіні IPv6-қа көшіру: жоспар және ықтимал қиындықтар

Неліктен компаниялар IPv6-қа көшеді және не өзгереді

IPv4-адрестерінің жетіспеушілігі — бұл енді теория емес. Компаниялар NAT, күрделі ішкі сымдар мен порт бағыттаулары арқылы шыдап келеді, бірақ бұл қызмет көрсетуді қиындатады: қолдау күрделенеді, сәтсіздік нүктелері артады, инциденттерді талдау ауырлай түседі, ал мердігерлер мен филиалдарға қолжетімділік орнату ұзарады.

IPv6-қа көшу әдетте «мода үшін» жасалмайды — ол өсу процесін жеңілдету мақсатында енгізіледі. IPv6 дерлік шексіз мекенжай кеңістігін және болжамды мекенжайлауды береді: әр құрылғыға NAT-сыз бірегей мекенжай тағайындауға болады. Бұл алаңдар, бұлттар мен дата‑центр арасындағы тікелей байланыс орнатуды, сондай‑ақ виртуализация, контейнерлер, IoT және қонақ желілер сияқты мекенжай көп қажет болатын қызметтерді оңайлатады.

IPv6 не шешпейтіні де маңызды: ол желіні автоматты түрде қауіпсіз етпейді және сегментацияны, сүзгіден өткізуді, мониторингті немесе рұқсат басқаруын жоққа шығармайды. Сондай-ақ ескі қосымшалар, VPN-клиенттер немесе есептік жүйелер кенеттен жақсы жұмыс істей береді деп ойлауға болмайды.

Бизнес тұрғысынан өзгерістер жанама түрде байқалады. Қолданушылар «IPv6 экранда» көрмейді, бірақ сыртқы сервистерге жетуде, бейнебайланыс пен қашықтан жұмыс істеуде аздаған проблемалар пайда болмай қалуы мүмкін. ИТ‑топ үшін мекенжайлау схемасы анықтала түседі және қолмен жасалатын көп ерекшеліктер азаяды, бірақ стартта екі протоколға арналған қауіпсіздік пен мекенжай есебі үшін жаңа жауапкершілік пайда болады.

Көбіне мақсаттар осындай: провайдер немесе дата‑центр талаптарына дайын болу, жаңа нысандарды мекенжай тапшылығысыз қосу, сервис жариялауды жеңілдету және күрделі NAT-тан тәуелділікті төмендету.

Бастамас бұрын келесі жайларды бағалап алыңыз: қай жерде dual-stack қажет, қандай қосымшалар мен құрылғылар критикалық, фаерволдар, балансировщиктер мен VPN‑дер дайын ба, мекенжай жоспары мен DNS үшін кім жауапты және IPv6 қосқаннан кейін қызмет сапасын қалай тексересіз.

Егер сервер инфрақұрылымын жаңартсаңыз (соның ішінде дата‑центрде), желілік параметрлерге, развертывание шаблондарына және қауіпсіздік ережелеріне IPv6 қолдауын бірден енгізу логичнее — кейін бөліп қайта жөндеудің қажеті болмайды.

Стратегияны анықтау: dual-stack немесе IPv6-only

Бастапқы стратегия жоба темпін белгілейді және күтпеген жағдайлардың тәуекелін төмендетеді. Көптеген компаниялар үшін көшу IPv4-тан толық бас тартудан емес, түсінікті аралық модельден басталады.

Үш режим бар: тек IPv4, dual-stack (IPv4 пен IPv6 қатар) және IPv6-only. Толық IPv6-only көбіне нақты шектелген жерлерде мүмкін: жаңа сегменттерде, ішкі қызметтерде, тест аймағында немесе кейде бұлтта. «Жанды» ортада әдетте кем дегенде кейбір элементтер IPv4-ты талап етеді: VPN-клиенттер, ескі қосымшалар, жеке жабдық немесе кей провайдерлер.

Қашан dual-stack негізді

Dual-stack көшу кезеңінде жиі ең жақсы компромисс болады: сіз IPv6-ты дайын жерге қосасыз, бірақ әлі де IPv4-ке тәуелді бөліктерді бұзбайсыз. Ең бастысы — қамтуды алдын ала айқындау, әйтпесе жоба таралып кетуі мүмкін.

Қамтуыңызды бекітіңіз: кеңселер мен филиалдар (провайдерден алынған тор, Wi‑Fi, қонақ желілер), ЦОД және сервер сегменттері (қызметтер, мониторинг, сақтық көшірмелер), VPN және қашықтан қолжетімділік, бұлттар және сыртқы SaaS, периметр және сервис жариялау.

Мысал: филиал провайдерден IPv6 алады, бірақ VPN арқылы орталық офиске қатынас және касса бағдарламасының бір бөлігі тек IPv4-та жұмыс істейді. Dual-stack Wi‑Fi және қолданушы подсеттерінде IPv6 қосуға мүмкіндік береді, ал критикалық жүйелерді IPv4-та қалдыруға болады.

Қарсы жүріс пен сәттілікті бекіту

Сәттілік критерийлері нақты болу керек: қандай сервистер міндетті түрде IPv6 арқылы жұмыс істеуі тиіс (DNS, веб-порталдар, пошта, корпоративтік қосымшалар, ОС жаңартулары, мониторинг), қай сегменттерде және қандай SLA-пен.

Откат жоспары dual-stack кезінде де қажет. Триггерлер мен іс‑әрекеттерді алдын ала айқындаңыз: егер авторизация қателері көбейсе, негізгі жүйелерге қолжетім бұзылса немесе байланыс сапасы төмендесе, IPv6-ты уақытша проблемалық сегментте өшіру (мысалы, Wi‑Fi SSID не белгілі бір площадка) және маршрутизация мен саясаттарды бастапқы күйге қайтару керек.

Дайындық аудиті: жабдық, ОС, қызметтер және провайдер

Бастамас бұрын қысқа, бірақ шынайы аудит жасаңыз. Мақсаты — қай жерде IPv6 қолжетімді және қай жерде тосынсыйлар болатынын анықтау: аппараттық жабдық, прошивка, конфигурация және сыртқы тәуелділіктер бойынша.

Инвентарь жинаңыз: маршрутизаторлар, L3-коммутаторлар, фаерволдар, балансировщиктер, прокси, Wi‑Fi контроллерлері. Әр құрылғы үшін тек «IPv6 қолдайды» дегенді емес, нақты детальдарды тексеріңіз: ACL, IPS, логтау, сүзгілеу, RA Guard және DHCPv6 Snooping, сондай‑ақ прошивканың нақты дайын болуы.

Одан кейін клиенттік ОС пен серверлерді тексеріңіз. Windows, Linux және macOS көбіне дайын, бірақ басқаруда қиындықтар пайда болуы мүмкін: GPO шаблондары, EDR агенттері, жергілікті брандмауэр саясаты және VPN-клиенттер. Тәуекел тобы — IP мекенжайды жол ретінде сақтайтын және «:» таңбасын түсінбейтін ескі қосымшалар. Wi‑Fi арқылы корпоративті қызметтерге қосылатын мобильді құрылғыларды да тексеріңіз.

Жиі тосынсый болып келетіндер — перифериялық және «ақылды» құрылғылар: принтерлер, IP-телефония, камералар, терминалдар, IoT. Оларда IPv6 «маркетингте» болуы мүмкін, бірақ нақты жұмыста — жоқ (мысалы, AAAA бойынша DNS жоқ немесе автоконфигурация істен шығады).

Мини-чеклист:

• Провайдердің IPv6 қолдауы, каналдар, SLA және шектеулер.
• BGP/статикалық маршрутизацияның дайын болуы және префикстерді беру форматы.
• Тәуелділіктер: DNS, NTP, PKI, AD, мониторинг, SIEM.
• Логтар мен көріну: IPv6 бойынша не жазылатынын анықтау.
• Прошивкаларды жаңарту жоспары және жұмыстар терезесі.

Практикалық тәсіл: егер сіз серверлерді жаңартсаңыз (жекеменшік бұлт немесе VDI үшін), аудитті сол сегменттен бастап және трафик жолын интернет пен негізгі қызметтерге дейін тексеріп шығыңыз, содан кейін ғана IPv6 қамтуын кеңейтіңіз.

IPv6 мекенжайлау жоспары: префикстер, подсетьтар және ережелер

Мекенжайлау жоспары проблемалардың жартысын шешеді. Оны түсінікті және барлық нысандарға бірдей етіп жасаңыз — dual-stack енгізу оңайырақ болады және бір жылдан кейін «тармақталған» желіні шешу азаяды.

Алғашқы таңдау — PI немесе PA префикс. PA (Provider Aggregatable) әдетте провайдерден беріледі: оңай және арзан, бірақ провайдерді ауыстырғанда мекенжайларды жаңарту қажет болуы мүмкін. PI (Provider Independent) ұзақ өмір сүреді және бірнеше каналдары бар компаниялар үшін ыңғайлы, бірақ оны алу мен қолдауы күрделірек.

Сосын бөлудің ережелері маңызды. /64 үнемдеу әдетте орынсыз: көптеген механизмдер (SLAAC, кейбір ОС функциялары мен жабдықтар) әр L2 сегментке /64 күтеді. «Корпоративтік блок» үшін ыңғайлы схема: ұйымға /48, нысанға /56, VLAN/подсеть үшін /64.

Мекенжайлар оқылатын және масштабталатын болуы үшін қай бөлімге қандай мән байланатынын алдын ала шешіңіз: площадка, желінің түрі, VLAN. Мысалы: офис VLAN, Wi‑Fi, қонақ желі, серверлік желілер және басқару үшін бөлек диапазондар.

Серверлер мен қызметтерге жеке /64 бөліп қою және резерв қалдыру пайдалы. Статикалық мекенжайларды арнайы диапазоннан берген дұрыс, атаулар мен иелер ережелерімен. Критикалық жүйелер (виртуализация, сақтау, стеллаждағы серверлер) үшін өсім мен миграцияға резерв қалдыру маңызды.

Жазбаша бекітуге тұратын ережелер:

• Әр VLAN үшін /64, ешқандай ерекшеліксіз.
• Қолданушылар, серверлер, басқару және DMZ үшін бөлек префикстер.
• «Площадка + функция + VLAN» біртұтас шаблоны.
• Статикалық мекенжайлар диапазоны және автоконфигурация диапазоны.
• Префикстер кестесі: иесі, енгізу күні, түсініктеме, өзгеріс тарихы.

Құжаттама формальдық емес — ол инцидент кезінде сағаттарды үнемдейді және мекенжай кеңістігін қақтығыссыз кеңейтуге көмектеседі.

DNS, DHCPv6, SLAAC және мекенжай есебі

DNS көбіне «бәрі қосылды, бірақ кейбір қолданушылар шағымданады» деген орынға айналады. AAAA жазбаларын қоссаңыз, клиенттер IPv6-ты таңдай бастайды, ал қосымша маршрут, фаервол немесе прокси бойынша IPv6 әлдеқайда нашар конфигурацияланған болса, қосымша ілініп қалуы мүмкін. Сондықтан AAAA-ларды кезең-кезеңімен қосу жақсы: алдымен тесттік қызметтер, кейін негізгі. Сол уақытта ip6.arpa кері зоналарын тексеріңіз — логтар мен мониторингте мекенжай анықтау жеңіл болсын.

Мекенжай тарату үшін екі тәсіл бар: SLAAC (роутер хабарламалары бойынша клиент мекенжай құрастырады) және DHCPv6 (мекенжайлар мен параметрлер сервер арқылы беріледі). Корпоративтік желілерде жиі екі тәсіл де қолданылады, бірақ әртүрлі сегменттерде.

Әдетте жеңілірек схема: қолданушы VLAN-дарында — мекенжай үшін SLAAC, ал DNS пен басқа параметрлер үшін DHCPv6. Серверлік сегменттерде — DHCPv6 немесе статикалық мекенжайлар. Қонақ желілерінде және Wi‑Fi-де — SLAAC, бірақ қатты қолжетімділік саясатымен.

Тұғырлы тәуекел — Router Advertisements (RA). Бір «қате» RA жеткілікті және кейбір клиенттер басқа шлюзқа ауысады. RA-ларды коммутатор порттарында және басқарылмаған құрылғылар пайда болуы мүмкін нүктелерде сүзгіден өткізу және бақылау қажет.

Мекенжай есебі мен префикстерді бөлек кестелерде шашыратып қалдырып қоймай, IPAM жүйесіне тіркеңіз: қай префикс қай нысанға берілген, қалай кесілген, қай жерде DHCPv6, қай жерге SLAAC қолданылатыны және сегмент иесі кім.

NTP, ішкі репозиторийлер, LDAP/AD, мониторинг сияқты тәуелділіктерді ұмытпаңыз — олар бәрін «бұза» алады. Практикалық мысал: DNS NTP үшін AAAA қайтарады, клиенттер IPv6-қа ауысады, ал IPv6 бойынша UDP/123 фаерволда ашық емес. Бір тәуліктен кейін сертификаттар мен аутентификация мәселелері басталады.

IPv6 қауіпсіздігі: ережелер, сүзгілеу және бақылау

Көшу кезіндегі басты қателік — IPv4 пен IPv6 параллель өмір сүріп жатқанда қауіпсіздік саясаттары тек IPv4 үшін қалуы. Нәтижесінде IPv6 арқылы трафик таныс шектеулерден айналып өтіп, сервистер кенеттен сырттан немесе сегменттер арасында қолжетімді болады.

Фаерволдан бастаңыз: IPv6 үшін бөлек ережелер мен тестілеу керек. «NAT автоматты жауып қоятын болады» деп сенбеңіз — көбіне IPv6-та NAT болмайды және мекенжайлар маршрутизируемые. Басты қағида — deny by default, кейін нақты бағыттарды ашу (DNS, веб, пошта, әкімшілік интерфейстер) және кімнің неге сұратқаны жазылсын.

Типтік сценарий: периметрде IPv4 үшін қатаң ережелер болса, ал IPv6-та «бәрін ашық» күйінде қалдырады, себебі «біз әлі тестілеудеміз». Бір аптадан кейін тестілік веб‑интерфейс, RDP немесе басқару панелі IPv6 арқылы ашық екені анықталады. Бұл әсіресе IPv6 әдепкі бойынша қосылған серверлер мен жұмыс станцияларында жиі кездеседі.

Қорғаныс құралдарының IPv6 трафигін шынымен көріп, сүзгілей алатынын тексеріңіз: IDS/IPS, WAF, прокси, DLP. "IPv6 қолдау бар" деген бір ғана чекбокс емес, саясаттар, сигнатуралар және исключениялардың екі стек үшін бірдей қолданылатыны маңызды. Егер жүйенің бір бөлігі (мысалы, прокси) IPv6-пен жұмыс жасамаса, қолданушылар айналып өтіп, бақылау жоғалып кетеді.

Логтар мен тергеулер үшін SIEM және журналдар IPv6-адрестерді дұрыс қабылдайтынына көз жеткізіңіз: өрістер кесілмейтініне, іздеу мен корреляция дұрыс істейтініне назар аударыңыз.

Жергілікті желіні маршрутизациядан қорғайтын шаралар: коммутаторларда RA Guard және DHCPv6 Guard қосыңыз, сенімді uplink порттарды анықтаңыз. Wi‑Fi контроллерлерінде ұқсас қорғанысты қосыңыз, әйтпесе «зұлым хотспот» переговоркада өз шлюзін тарат төртеді. VLAN/ACL арқылы сегментация IPv6 үшін де дәл сол қатаңдықпен сақталуы тиіс.

Қосымшалар мен сервистер: IPv6 қай жерде күтпеген жерден бұзылады

Көшу кезінде ең жағымсызсы — IPv6-тың «өздігінен» пайда болып, жоспарсыз қолданылуы. Көптеген ОС-тар оны әдепкі қосады, ал қосымшалар IPv6 бар болса сол стекті таңдайды. Содан сіз әлі IPv4-та жұмыс істеп жатырсыз деп ойлағанмен, кейбір клиенттер IPv6 арқылы өтіп, дайын емес сервистерге ұшырайды.

Жиі кездесетін себеп — IPv4 пен IPv6 үшін жолдар әртүрлі. Split DNS, прокси және қолжетімділік ережелері тек A жазбаларына арналған болуы мүмкін, ал AAAA жазбалары басқа резолверге немесе басқа жауапқа түседі. Қолданушы сайт ашқанда: IPv4 арқылы бәрі жақсы, IPv6 арқылы — таймаут немесе «403», және бұл кездейсоқ ақау сияқты көрінеді.

Қай жерлерде типтік ақаулар кездеседі

Ең жиі келесі бөлімдерде:

• L7‑балансировщиклар және reverse proxy: шынайы клиент IP‑ы жоғалады, заголовоктар (мысалы, X-Forwarded-For) өзгереді, ACL-дар бұзылады;
• VPN: туннель IPv6-ны өткізбейді немесе клиенттер маршрут/мұқтаж адрес алмайды, сондықтан қашықтағы қызметтер жоғалады;
• Пошта: SPF/DKIM/DMARC және антиспам IPv4-қа бапталған, IPv6‑адрес үшін rDNS жоқ;
• VoIP және баспа құрылғылары: IPv6 бар, бірақ DNS және қызметті табу үшін қиындықтар кездеседі;
• Мониторинг: тек IPv4 тексеріледі, сондықтан IPv6 деградациясы байқалмай жиналады.

Жылдам диагностика

«Жын‑айғақтарды» ұстамау үшін симптомдарды стек бойынша бөліңіз:

• Қызметтің IPv4 және IPv6 арқылы қолжетімділігін бөлек тексеріңіз (тек клиенттік подсеттерден).
• DNS жауаптарын A және AAAA бойынша және қай резолвердің жауап беріп тұрғанын тексеріңіз.
• Прокси/балансировщик журналдарын қараңыз: қосымша қандай клиент мекенжайын көріп, қандай заголовоктар келіп жатыр.
• VPN үшін бөлек тексеріңіз: клиентте IPv6-адрес бар ма, қажетті префикстерге маршрут бар ма, DNS жұмыс істей ме.

Практикада көбіне қосымшаның айналасындағы обвязканы (DNS, прокси, WAF, балансировщиктар, VPN, мониторинг) реттеу қажет болады. Интегратормен жұмыс істесеңіз, желі ғана емес, қосымша деңгейіндегі тесттерді де келісіңіз.

Енгізу жол картасы: кезең-кезеңімен жоспар

Көшуді бірден емес толқын‑толқын түрде жасау тиімді: осылайша күтпеген ақауларды тез тауып, бақылауды жоғалтпайсыз. Пилоттан бастаңыз — оңай шақырылатын жерде: бір офис, бір VLAN немесе шағын сервер сегменті.

Типтік тәртіп, көптеген компанияларда жұмыс істейтін:

• Пилот зонасы: IPv6-ты бір сегментте қосып, мекенжайлауды және маршрутизацияны баптап, метрикаларды жинаңыз.
• Ядро және периметр: маршрутизаторлар, фаерволдар мен VPN‑де dual-stack қосып, интернетке шығуды және алаңдар арасындағы байланысты тексеріңіз.
• Негізгі қызметтер: DNS (AAAA және reverse), NTP, AD/PKI дайын болсын, клиеттер IPv6-та ілінбесін.
• Жұмыс орындары мен Wi‑Fi, кейін филиалдар: әр желі түрін біреуіншіден кеңейтіңіз, өзгерістер терезесі және откат жоспары болсын.
• Сыртқы сервистер жариялау: ішкі бөлшек тұрақталғаннан және қауіпсіздік пен мониторинг дайын болғаннан кейін ғана ашыңыз.

Әр қадамнан кейін қысқа қабылдау қажет. IPv6 көбіне маршрутизацияда емес, DNS, саясаттар және ескі агенттерде «бұзылады».

Әрбір кезеңде тексерілетіндер:

• Клиент мекенжай, шлюз және DNS алады және ішкі ресурстарға аталым бойынша тең қол жеткізеді.
• Фаервол саясаты IPv6 үшін қосылған және IPv4-ке тең, «барлығын ашу» жоқ.
• Логтар, мониторинг және инвентаризация IPv6-адрестерді көреді және оларды «белгісіз» деп белгілеген жоқ.
• Негізгі қосымшалар (пошта, прокси, VPN, EDR) стекті қате таңдау салдарынан кешігулерге ұшырамайды.
• Құжатталған откат бар: сегменттен IPv6-ты қалай тез өшіруге болады.

Инфрақұрылымды жаңартқанда dual-stack талаптарын жеткізіп алуды қарастырыңыз — бұл ядроны жаңарту немесе жаңа сервер кластері іске қосу кезінде ыңғайлы.

Тестілеу және қабылдау: кеңеюге дейін не тексеру керек

Кеңею алдында пилотты шектеулі учаскеде өткізіңіз: кабина, филиал немесе бөлек ИТ сегменті. Мақсат — проблемаларды қолданушыларға әсер етпей табу және қабылдау ережелерін бекіту.

Алдымен базалық байланысты тексеріңіз, бірақ тек ping-пен шектелмей. Көп жағдайда мәселе мекенжай алу мен маршруттауда болып шығады.

Міндетті техникалық тексерістер тізімі

Нәтижелерді тіркеп отырыңыз (күткен, алынған, қай жерден және қашан тестіленді):

• Маршрутизация және мекенжайлау: интерфейстерде дұрыс префикстер, күтілген RA, маршрут кестелерінде дұрыс жазбалар, күтпеген «артық» маршруттардың жоқтығы.
• DNS: AAAA жазбалары қажетті жерде шығады, split-horizon жұмыс істейді, кері зоналар дайын, кэшталу қателерді жасырып тұрған жоқ.
• Қосымшалар: кіру (SSO/AD), ОС және ПО жаңартулары, файлдық ресурстар мен баспаға қолжетімділік, негізгі SaaS және олардың агенттері.
• Қауіпсіздік: фаервол ережелері IPv6 үшін «барлығын ашу» күйінде емес, сегментация шынайы түрде бөлінеді, сканерлеу артық ашық порттарды көрсетпеді.
• Бақылану: журналдар IPv6-ты кесіп жазбайды, алерттер нақты іске қосылады, NetFlow/sFlow IPv6-ты көрсетеді, SIEM көздерін дұрыс топтастырады.

Содан кейін қабылдауға өтіңіз: кеңеюге дейін қандай метрикалар «жасыл» болуы керек анықтаңыз. Мысалы — корпоративтік сервиске сәтті кірулер проценті, жаңартуларға шағымдар болмауы, DNS тұрақтылығы және тесттердің қайталанатын нәтижелері.

Пилот үшін практикалық сценарий: 20–50 қолданушыдан тұратын топ пен бірнеше сервер (файлдар және жаңартулар сервері). Егер тесттік жұмыс станциялары мен серверлер болса, оларды нақты жабдыққа жақын күйде жинап, драйвер немесе желілік карталардан шыққан тосынсыйларды болдырмаңыз.

Қолданушыларға коммуникация жіберіңіз: өзгеріс терезесі, мәселе белгілері (мысалы, «ішкі ресурстар ашылмайды, бірақ интернет жұмыс істейді») және қайда жүгіну керектігін айтыңыз — бұл шуды төмендетіп, нақты симптом жинауға көмектеседі.

Көбінесе болатын қателіктер мен тұзақтар

Ең жағымсыз ақаулар көбінесе мекенжай беру емес, қауіпсіздік пен басқарылымның «шет қалуынан» туындайды. IPv6 өздігінен қосылып, команда бұл туралы тек түрлі инциденттерден кейін ғана біледі.

Қайсысы жиі бұзылады

Бірінші қате — фаерволде IPv6-ты жіберіп алу. Мысалы, трафик IPv6 арқылы өтуде, бірақ ережелер мен журналдар тек IPv4 үшін жазылғандықтан бақылау сыртында қалады.

Екінші тұзақ — L2-де кездейсоқ RA пайда болуы. Бір қате конфигурацияланған машина немесе «ақылды» роутер жеткілікті, және құрылғылар басқа шлюз, DNS немесе маршрутқа ауысады. Симптомдар «кейде жұмыс істейді, кейде жоқ» сияқты көрінеді.

Үшінші — қолданушы VLAN-да /64-тан кіші подсеть жасауға тырысу. Бұл SLAAC пен кейбір ОС функцияларымен қайшылыққа алып келеді. Егер мекенжайларды үнемдеу керек болса, дизайнды қайта қараған жөн, /64-ты қысқарту емес.

Төртінші — DHCPv6 пен SLAAC-ты түсініксіз араластыру. Нәтижесінде мекенжай бар, бірақ есепке алу, DNS тіркеуі мен қосымшалардың күтілетін мекенжайы сәйкес келмей қалады.

Бесінші — ұмытылған тәуелділіктер: мониторинг, резервтік көшірме, EDR-агенттер, ослабытқыш сканерлер. Олар IPv6-ты үндемей қолдамай қалуы мүмкін немесе бөлек баптауды талап етеді.

Пилотты кеңейтпес бұрын ең аз мына заттарды тексеріңіз:

• Фаерволдегі негізгі сегменттер үшін бөлек IPv6 ережелері мен журналдар бар ма;
• L2 RA-дан қорғалған ба және кім шлюз бола алатынын анықтадыңыз ба;
• Әр жерде қолданушы подсетьтарында /64 сақталған ба;
• SLAAC/ DHCPv6 саясаты бекітілген бе және мекенжай есебі бар ма;
• Откат және өзгерістерді бақылау жоспары бар ма (кім, не, қашан қосқан).

Мысал: филиалда коммутаторларда IPv6 қосылған, бірақ периметр мен мониторингте өзгеріс ескерілмеген. Қолданушылар кейде сыртқы сервистерге IPv6 арқылы жылдамырақ қолжетеді, бірақ ішкі қауіпсіздік есептерінде «бос орын» пайда болады, өйткені IPv6 трафигі бұрынғы есептерге түспейді.

Жылдам чеклист, мысал сценарий және келесі қадамдар

Dual-stack қосар алдында қысқа тексеру жасаңыз, сол арқылы «жұмыс істейді, бірақ кейбір қолданушыларға қолжетім жоқ» жағдайынан сақтанасыз.

Dual-stack қосудан бұрынғы чеклист (30 минут)

• Периметр маршрутизаторында провайдерден IPv6 бар екеніне (префикс, маршрут по умолчанию, кері жол) көз жеткізіңіз.
• DNS тек реально қолжетімді сервистер үшін ғана AAAA береді.
• Негізгі VLAN-дарда RA/SLAAC немесе DHCPv6 тексеріңіз (және олардың бір-біріне қайшылық жасамауын), сондай-ақ мекенжайлар есебінде тіркелетінін бақылаңыз.
• Фаерволда IPv6 үшін логтауды қосып, жедел откатқа дайын болыңыз (алғаш не өшірілетінін анықтаңыз).
• 3–5 типтік сценарийді жүргізіңіз: пошта, файлдар, корпоратив портал, VPN, баспа.

IPv6 үшін минималды фаервол саясаты

IPv6-ты кейінге қалдырмаңыз: маршруттар және RA пайда болған кезде трафик дереу жүреді.

• Интернеттен қолданушы подсеттеріне кіретін трафикті нақты қажетті сервистерден басқа блоктаңыз.
• ICMPv6-ты негізгі деңгейде рұқсат етіңіз (әйтпесе MTU және көршілесу жұмысы бұзылады), бірақ қажетсіз типтерді шектеңіз.
• Пайдаланылмайтын транзиттік механизмдерді (Teredo/6to4 сияқты) бұғаттаңыз, егер қолданылмаса.
• Межсегменттік ережелерді сервис топтары бойынша жасаңыз, «any-any» емес.
• Коммутаторларда RA-spoofing-ке қарсы қорғанысты қосыңыз және DHCPv6 бақылауын қосыңыз.

Мекенжай есебі шаблоны көмектеседі:

Орташа компания мысалы: 1‑апта — жабдық, ОС және провайдер аудиті, сервис инвентаризациясы және DNS. 2‑апта — мекенжай жоспарлау, пилот 1–2 VLAN, негізгі қауіпсіздік ережелері, дежуршыларды оқыту. 3‑апта — филиал қосу, қосымшаларды тестілеу, тармақтарды түзету (VPN, мониторинг, принтерлер). 4‑апта — қалған сегменттерге кеңейту, қабылдау, регламенттер мен метрикалар.

Келесі қадамдар: жоба иесін (желілер), қауіпсіздік пен қосымшаларға жауаптыларды тағайындаңыз, тесттік контур мен өзгеріс терезелерін белгілеңіз, прошивкаларды жаңарту мен ескі құрылғыларды ауыстыруға уақыт бөліңіз. Аудит көрсеткендей қосымша серверлер (DNS/DHCP/мониторинг) немесе жұмыс станцияларын жаңарту қажет болса, оларды модернизация жоспарына енгізіңіз. Мұндай жобаларға жүйелік интегратор мен GSE.kz (gse.kz) сияқты жабдық жеткізушілер пилот пен тираждауда көмектесе алады.