Kwa nini VM yako ya GCP haiwezi kujibu pool ya IPv6 ya OpenVPN
Anwani ndani ya OpenVPN si subnet ya Google Cloud. Ongeza njia ya VPC kuelekea pool, washa uenezaji na utenganishe matokeo ya intaneti.
Mteja wako wa IPv6 VPN anafikia mzigo wa kazi, mzigo wa kazi unajibu ndani ya handaki, na jibu halifiki kamwe. Hisia ya kwanza ni kulaumu firewall au handaki, na kwa kawaida hakuna hata mmoja aliye na hatia. Anwani inayotolewa na OpenVPN ni mtandao wa ndani ambao unapatikana ndani ya handaki pekee; Google Cloud haijui kwamba fd42:90::/64 inapaswa kuwa nyuma ya VM fulani hadi utakapoiambia.
Mifumo miwili tofauti inapaswa kujifunza ukweli huo, na mmoja tu kati yao ni OpenVPN. VPC inahitaji njia kabla ya kuweza kurudisha kitu chochote, na VM inapaswa kuruhusiwa kusambaza kile kinachofika. Kosea upande wowote na dalili itaonekana sawa.
Pool ni mtandao wa ndani, si subnet
OpenVPN inaweza kutoa anwani za IPv6 kutoka safu unayochagua, na safu hiyo ni hadithi ambayo ncha mbili za handaki zinakubaliana. Si subnet ya Google Cloud, haionekani katika orodha ya subnet za VPC, na kiolesura cha mtandao cha VM hakipati anwani hizo. Kwa hiyo mzigo wa kazi unaojibu mteja hutuma pakiti kwenye anwani ambayo mtandao unaiona kuwa isiyoweza kupitishwa.
Weka pool nje ya kila safu ambayo VPC tayari inatumia. Weka pia nje ya safu zilizo nyuma ya handaki zako nyingine. Mwingiliano hubadilisha kushindwa kwa njia safi kuwa kwa vipindi kunakoonekana tu chini ya mzigo.
Anwani za kipekee za ndani kama fd42:90::/64 ni chaguo la busara kwa mtandao huu wa ndani. Kiambishi awali pia hukumbusha kwamba muundo ni wa faragha kwa asili. Hakuna kitu kwenye pool ya ULA kinachoifanya kuwa chanzo halali kwenye intaneti ya umma.
Ipe VPC lengwa na hatua inayofuata
Jibu linahitaji njia ya VPC ambayo lengwa lake ni pool na hatua inayofuata ni VM ya VPN. Nyaraka za sasa za njia tuli zinashughulikia safu za lengwa za IPv6 na zinaorodhesha aina gani za hatua inayofuata zinazostahiki, kwa hiyo thibitisha umbo linalotumika kwa topolojia yako badala ya kunakili mfano wa zamani wa IPv4.
Anwani ya hatua inayofuata inapaswa kuwa ile ambayo imetengwa kwa kweli kwa kiolesura cha wingu cha instance. Anwani ya ndani ya handaki ya VM si anwani hiyo. Kuitumia hata hivyo hutoa njia inayowekwa safi na kamwe hailingani na pakiti. Soma orodha ya violesura kabla ya kuandika njia.
Kipaumbele cha njia ni muhimu kama kumbukumbu yenyewe. Njia za subnet ni mahususi zaidi kuliko njia maalum unazoongeza, kwa hiyo pool iliyokatwa kutoka safu iliyopo ya subnet itashindwa na njia ya subnet, bila kujali jinsi njia maalum imeandikwa. Chagua pool tofauti, kisha thibitisha kwamba njia inaonyesha instance kama hatua inayofuata na kiambishi awali sahihi cha lengwa:
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-bUenezaji unapaswa kuwashwa mara mbili
Njia huwasilisha pakiti kwa instance. Haifanyi instance kuwa tayari kusambaza kitu ambacho hakijaelekezwa kwake, na ruhusa hiyo inapatikana katika tabaka mbili.
Upande wa wingu unahitaji uwezo wa uenezaji wa instance kuwashwa; hii ni mpangilio unaoruhusu VM kupokea trafiki kwa anwani ambazo haimiliki na kuipitisha. Upande wa mgeni unahitaji uenezaji wake wa IPv6, kwa sababu kernel hufanya uamuzi tofauti baada ya pakiti kuwasili. Zote mbili lazima ziwe zimwashwa kabla jibu moja kuvuka handaki.
sysctl -w net.ipv6.conf.all.forwarding=1Kisha kanuni za firewall zinapaswa kuruhusu safu ya chanzo cha ndani katika pande zote mbili. Google Cloud hutathmini pakiti iliyofunguliwa, kwa hiyo kanuni inayoshughulikia subnet ya VPC pekee huacha trafiki ya pool baada ya handaki kufanikiwa tayari. Ongeza pool kama safu ya chanzo kwenye kanuni ya kuingia, na hakikisha hakuna sera maalum ya kutoka inayozuia jibu. Kanuni ya ruhusa isiyoandikwa hushughulikia hali ya kawaida, kanuni ya kutoka iliyoandikwa kwa mkono haifanyi hivyo.
Iambie OpenVPN nani anamiliki nini
OpenVPN husambaza kwa mteja inapojua kwamba mteja huyo anamiliki lengwa. Anwani za wateja kutoka pool hushughulikiwa na agizo la seva linalofafanua pool, lakini subnet iliyo nyuma ya mteja ni mpangilio tofauti na inahitaji kumbukumbu bayana ya umiliki kwa mteja huyo.
Kuchanganya mbili hutoa handaki ambapo ping kwa seva hufanya kazi na hakuna kitu nyuma yake. Amua ni kesi gani unajenga, kisha andika kumbukumbu inayolingana badala ya kuongeza mstari wa pili wa push na kutumaini.
Weka matokeo ya intaneti nje ya muundo huu
Ufikiaji wa faragha na ufikiaji wa intaneti ni mipango tofauti. Pool ya ULA inaweza kufikia mizigo ya kazi ya VPC kupitia handaki mara tu njia na uenezaji zinapokubaliana, na pool hiyo hiyo haina njia ya kufikia intaneti ya umma kupitia VPC, kwa sababu lango la wingu halitakubali chanzo holela cha handaki kama chake.
Ikiwa wateja pia wanahitaji matokeo ya intaneti, panga muundo wa anwani na njia unaotumika kwa hilo, weka huru kutoka pool ya faragha, na jaribu njia mbili kwa tofauti. Njia moja inayofanya kazi haisemi chochote kuhusu nyingine, na muundo unaochanganya zote mbili hushindwa kwa namna inayoonekana kama handaki lililovunjika.