Ինչու ձեր GCP VM-ը չի կարող պատասխանել OpenVPN-ի IPv6 ավազանին

Ձեր IPv6 VPN հաճախորդը հասնում է աշխատանքային բեռին, աշխատանքային բեռը պատասխանում է թունելի ներսում, և պատասխանը երբեք չի հասնում։ Առաջին բնազդը մեղադրել ֆայրվոլին կամ թունելին, և սովորաբար ոչ մեկը մեղավոր չէ։ OpenVPN-ի տրամադրած հասցեն ներքին ցանց է, որը գոյություն ունի միայն թունելի ներսում՝ Google Cloud-ը պատկերացում չունի, որ fd42:90::/64-ը պետք է լինի մեկ կոնկրետ VM-ի հետևում, մինչև դուք չասեք դա։

Երկու առանձին համակարգեր պետք է սովորեն այս փաստը, և դրանցից միայն մեկն է OpenVPN։ VPC-ին երթուղի է պետք, նախքան այն կկարողանա ինչ-որ բան հետ ուղարկել, և VM-ին պետք է թույլատրվի փոխանցել այն, ինչ գալիս է։ Սխալվեք կեսերից որևէ մեկում, և ախտանիշը նույնն է թվում։

Ավազանը ներքին ցանց է, ոչ ենթացանց

OpenVPN-ը կարող է IPv6 հասցեներ տրամադրել ձեր ընտրած միջակայքից, և այդ միջակայքը գեղարվեստական է, որի շուրջ համաձայնում են թունելի երկու ծայրերը։ Այն Google Cloud ենթացանց չէ, չի հայտնվում VPC-ի ենթացանցերի ցանկում, և VM-ի ցանցային ինտերֆեյսը չի ստանում այդ հասցեները։ Այդ պատճառով հաճախորդին պատասխանող աշխատանքային բեռը փաթեթ է ուղարկում հասցեի, որը ցանցը համարում է չուղղորդվող։

Ավազանը պահեք ցանկացած միջակայքից դուրս, որն արդեն օգտագործում է VPC-ը։ Պահեք այն նաև ձեր մյուս թունելների հետևում գտնվող միջակայքերից դուրս։ Համընկնումը մաքուր երթուղավորման խափանումը դարձնում է ընդհատվող, որը երևում է միայն ծանրաբեռնվածության տակ։

fd42:90::/64-ի նման եզակի տեղական հասցեավորումը ողջամիտ ընտրություն է այս ներքին ցանցի համար։ Նախածանցը նաև հիշեցնում է, որ դիզայնը ի սկզբանե մասնավոր է։ ULA ավազանում ոչինչ այն օրինական աղբյուր չի դարձնում հանրային ինտերնետում։

Տվեք VPC-ին նպատակակետ և հաջորդ թռիչք

Պատասխանին պետք է VPC երթուղի, որի նպատակակետը ավազանն է, իսկ հաջորդ թռիչքը՝ VPN VM-ը։ Ստատիկ երթուղիների ընթացիկ փաստաթղթերը ներառում են IPv6 նպատակակետ միջակայքերը և թվարկում, թե հաջորդ թռիչքի որ տեսակներն են ընդունելի, ուստի հին IPv4 օրինակը պատճենելու փոխարեն ստուգեք ձեր տոպոլոգիայի համար աջակցվող ձևը։

Հաջորդ թռիչքի հասցեն պետք է լինի այն, որը իրականում հատկացված է ինստանսի ամպային ինտերֆեյսին։ VM-ի ներքին թունելի հասցեն այդ հասցեն չէ։ Այն ամեն դեպքում օգտագործելը ստեղծում է երթուղի, որը մաքուր տեղադրվում է և երբեք չի համընկնում փաթեթի հետ։ Կարդացեք ինտերֆեյսների ցանկը նախքան երթուղին գրելը։

Երթուղու առաջնահերթությունը նույնքան կարևոր է, որքան գրառումը։ Ենթացանցի երթուղիներն ավելի կոնկրետ են, քան ձեր ավելացրած հատուկ երթուղիները, ուստի գոյություն ունեցող ենթացանցի միջակայքից կտրված ավազանը կպարտվի ենթացանցի երթուղուն, անկախ նրանից, թե ինչպես է գրված հատուկ երթուղին։ Ընտրեք առանձին ավազան, ապա հաստատեք, որ երթուղին ցույց է տալիս ինստանսը որպես հաջորդ թռիչք և ճիշտ նպատակակետ նախածանց:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Փոխանցումը պետք է միացվի երկու անգամ

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

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

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

Այնուհետև ֆայրվոլի կանոնները պետք է թույլատրեն ներքին աղբյուրի միջակայքը երկու ուղղություններով։ Google Cloud-ը գնահատում է ապապարկավորված փաթեթը, ուստի միայն VPC ենթացանցը ծածկող կանոնը գցում է ավազանի երթևեկությունը այն բանից հետո, երբ թունելն արդեն հաջողվել է։ Ավելացրեք ավազանը որպես աղբյուրի միջակայք մուտքային կանոնում և ստուգեք, որ ոչ մի հատուկ ելքային քաղաքականություն չի արգելափակում պատասխանը։ Ենթադրվող թույլատրող կանոնը ծածկում է լռելյայն դեպքը, ձեռքով գրված ելքային կանոնը՝ ոչ։

Ասացեք OpenVPN-ին, թե ով ինչ ունի

OpenVPN-ը փոխանցում է հաճախորդին, երբ գիտի, որ այդ հաճախորդը տիրապետում է նպատակակետին։ Ավազանից եկող հաճախորդի հասցեները կառավարում է սերվերի հրահանգը, որը սահմանում է ավազանը, բայց հաճախորդի հետևում գտնվող ենթացանցը այլ դասավորություն է և պահանջում է բացահայտ սեփականության գրառում այդ հաճախորդի համար։

Երկուսը շփոթելը ստեղծում է թունել, որտեղ սերվերին ուղարկվող ping-երը աշխատում են, իսկ դրա հետևում ոչինչ։ Որոշեք, թե որ դեպքն եք կառուցում, ապա գրեք համապատասխան գրառումը՝ երկրորդ push տող ավելացնելու և հույս ունենալու փոխարեն։

Ինտերնետ ելքը պահեք այս դիզայնից դուրս

Մասնավոր հասանելիությունը և ինտերնետ հասանելիությունը առանձին պլաններ են։ ULA ավազանը կարող է հասնել VPC աշխատանքային բեռերին թունելով, երբ երթուղավորումը և փոխանցումը համաձայն են, և նույն ավազանը VPC-ով հանրային ինտերնետ տանող ուղի չունի, քանի որ ամպային դարպասը կամայական թունելի աղբյուր չի ընդունի որպես իրենը։

Եթե հաճախորդներին նաև ինտերնետ ելք է պետք, պլանավորեք դրա համար աջակցվող հասցեավորման և երթուղավորման դիզայն, պահեք այն անկախ մասնավոր ավազանից և փորձարկեք երկու ուղիներն առանձին։ Մեկ աշխատող ուղին ոչինչ չի ասում մյուսի մասին, և երկուսը խառնող դիզայնը ձախողվում է այնպես, որ կոտրված թունել է թվում։