Ավելացնել մասնավոր IPv6 OpenVPN լաբորատորիային՝ մեկ ստուգման կետ միաժամանակ

Դուք արդեն ունեք հաճախորդ, որը միանում է IPv4-ով և հասնում սերվերի հետևում գտնվող մասնավոր IPv4 աշխատանքային բեռին։ Նպատակն է նույն թունելով հասնել մասնավոր IPv6 աշխատանքային բեռի՝ չդիպչելով արտաքին տրանսպորտին։ Այդ հերթականությունը կարևոր է. արտաքին ուղին մնում է IPv4, և փոխվում են միայն ներքին հասցեների պլանը, հաճախորդի երթուղին և սերվերից դեպի LAN վերադարձի ուղին։ Հինգ ստուգման կետ, յուրաքանչյուրը՝ առաջ շարժվելուց առաջ նայելու համար կոնկրետ բանով։

Ստուգման կետ առաջին՝ կապը, որն արդեն աշխատում է

Միացրեք հաճախորդին և հաստատեք IPv4 ուղին նախքան որևէ բան ավելացնելը։ Աշխատող թունելը ձեզ տալիս է հիմնագիծ, որը բաժանում է նոր IPv6 սխալը հին կապակցման խնդրից։ Այն նաև ասում է, թե որ սերվերի օրինակն եք իրականում խմբագրում։

Նշեք լողավազանը, տոպոլոգիան և հրված երթուղիները, որոնց արդեն հենվում եք։ IPv6 աշխատանքը ընդլայնում է այդ կարգավորումը, այլ ոչ թե փոխարինում։

Ստուգման կետ երկրորդ՝ ընտրեք ներքին նախածանցերը

Կայքի համար ընտրեք ULA /48 և դրանից կտրեք երկու /64՝ մեկը թունելի հաճախորդների համար, մեկը՝ IPv6 աշխատանքային բեռը պարունակող LAN հատվածի համար։ Գեներացրեք 40-բիթանոց գլոբալ ID-ն՝ օրինակ նախածանց պատճենելու փոխարեն, և ստուգեք երկու ենթացանցերն էլ կայքի արդեն երթուղվող յուրաքանչյուր ցանցի դեմ՝

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Երկու անկախ /64-երը թույլ չեն տալիս հաճախորդների լողավազանը կտրել LAN հատվածից, ինչը կարևոր է ավելի ուշ, երբ գրեք վերադարձի երթուղին։ Վերևի արժեքները մեկ մշակված օրինակ են, ոչ թե կրկնօգտագործման նախածանց։

Ստուգման կետ երրորդ՝ ավելացրեք օգնականը և երթուղու հրումը

Կարդացեք սերվերի ընթացիկ կարգավորումը նախքան որևէ բան ավելացնելը։ Գոյություն ունեցող հրահանգի երկրորդ պատճենը չի միաձուլվում առաջինի հետ, և ստացված սխալը նշում է հրահանգը, ոչ IPv6-ը։ Առկա IPv4 օգնականի դեպքում երկու տող ընդլայնում են այն։ Յուրաքանչյուրը պատասխանում է տարբեր հարցի՝

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Առաջինը հարմար օգնական է, որը կարգավորում է ինտերֆեյսը և հաճախորդների լողավազանը։ Երկրորդը նշում է LAN նպատակակետը, ուր հաճախորդը պետք է հասնի։ Հաճախորդին IPv6 հասցե տալը չի ասում, թե ինչ ցանցեր կան սերվերի հետևում, ուստի երկու տողերն էլ անհրաժեշտ են։

Օգնականը չի գոյակցում ստատիկ IPv6 լողավազանի կամ nopool-ի հետ։ Եթե տեղակայումը դիտավորությամբ հասցեներ է հատկացնում ստատիկորեն, պահպանեք այդ քաղաքականությունը և բացահայտ նախագծեք IPv6 համարժեքը՝ օրինակին հարմարվելու համար քաղաքականությունը ջնջելու փոխարեն։

Ստուգման կետ չորրորդ՝ փոխանցումը և պատասխանի երթուղին

Միացրեք IPv6 փոխանցումը սերվերի վրա համակարգի սեփական կարգավորման տիրոջ միջոցով, ոչ թե մեկանգամյա գործարկման գրառմամբ, որը կմոռանաք։ Գործարկման ձևը օգտակար է արագ թեստի համար։ Մշտական կարգավորումը տեղ ունի drop-in ֆայլում, որը կարդում է դիստրիբուտիվի ցանցի տերը՝

sysctl -w net.ipv6.conf.all.forwarding=1

Փոխանցումը փոխում է հոսթի IPv6 վարքը փաթեթների երթուղավորումից ավելի։ Հոսթը, որը որպես հաճախորդ ընդունում էր երթուղիչի հայտարարություններ, դադարում է դա անել նույն կերպ, հենց որ փոխանցում է։ Ուստի մեքենան, որի IPv6 վերին կապը կախված է RA-ներից, այդ կապի համար բացահայտ պլան է պահանջում։

Այնուհետև LAN-ին տվեք թունելի լողավազան վերադարձող երթուղի։ Աշխատանքային բեռի IPv6 դարպասը LAN երթուղիչն է, ոչ VPN սերվերը, ուստի երթուղին այդ երթուղիչի վրա է և ուղղված է սերվերի LAN հասցեին՝

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Պահպանեք կապի համար անհրաժեշտ ICMPv6 տեսակները, ներառյալ ուղու MTU հետադարձ կապը։ IPv4 հրահանգը չի նշանակում IPv6 հրահանգ, և IPv6-ի համատարած արգելափակումը կոտրում է հարևանների հայտնաբերումը այնպես, որ նման է երթուղավորման խափանման։

Ստուգման կետ հինգերորդ՝ կարդացեք հաճախորդին, ապա փորձարկեք

Կրկին միացրեք հաճախորդին և կարդացեք այն հասցեները, որոնք նա իրականում ստացել է՝ սերվերի օգնական հասցեից դրանք եզրակացնելու փոխարեն։ Ինտերֆեյսի ցանկը ցույց է տալիս երկու ընտանիքները նույն սարքում՝

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Թունելն ընտրող երթուղին ապացուցում է, որ հաճախորդը գիտի, թե ուր ուղարկել փաթեթը։ Այն չի ապացուցում, որ սերվերը փոխանցում է այն, որ LAN երթուղիչն ունի վերադարձի երթուղին, կամ որ հավելվածին թույլատրված է պատասխանել։

Փորձարկեք հենց հավելվածը յուրաքանչյուր ընտանիքով հերթով, ապա կրկնեք վերամիացումից և հոսթի վերագործարկումից հետո։ Երթուղին կամ sysctl-ը, որը տևում է միայն մինչև վերագործարկումը, թեստ է, ոչ նախագիծ։

Հրապարակեք AAAA գրառումը միայն այն ժամանակ, երբ IPv6 ուղին պատասխանում է ծայրից ծայր։ IPv4-ով հարցված DNS-ը դեռ կարող է վերադարձնել IPv6 հասցե, ուստի լուծելի անունը ապացույց չէ, որ ինչ-որ բան լսում է։ RFC 4193 ULA ուղեցույցը ընդգրկում է գլոբալ ID-ի գեներացումը, որը այս նախածանցերը դարձնում է ձերը, այլ ոչ պատճեն։