Washa upitishaji wa IP kwenye lango la GCE VPN lililopo

VM iliundwa bila upitishaji wa IP, tayari inaendesha programu ya VPN, na silika ni kuijenga upya kutoka kwenye kiolezo kikiwa na bendera imewekwa. Ujenzi huo upya hauhitajiki. Compute Engine inaonyesha canIpForward kama sifa inayoweza kusasishwa, na njia ya usasishaji iliyoandikwa inaitumia kwa refresh badala ya kuwasha upya. Kinachodhibitiwa na bendera kwa hakika ni chembamba: bila yake, jukwaa hutupa pakiti zinazofika kwenye instansi lakini hazijaelekezwa kwa anwani ya instansi yenyewe. Lango linalopitisha trafiki ya mashine nyingine hufanya hivyo hasa, kwa hiyo bendera lazima iwe imewashwa. Kila kitu baada ya hapo ni usanidi wa mgeni na uelekezaji, ambao bendera haigusi.

Bendera inaruhusu nini, na haikuruhusu nini

Upitishaji ukiwa umezimwa, jukwaa huchukulia instansi kama kituo cha mwisho. Pakiti ambazo lengo lake ni anwani ya instansi yenyewe huwasilishwa; pakiti ambazo instansi inapaswa kuzipitisha kwa niaba ya mtu mwingine hazwasilishwi.

Upitishaji ukiwa umewashwa, instansi inaweza kufanya kazi kama hop inayofuata kwa njia ya VPC, na hiyo ni jukumu ambalo kifaa cha VPN linahitaji. Bendera haisemi chochote kuhusu ngome, uelekezaji wa mgeni, usanidi wa handaki au njia za kurudi, na thamani ya true kwenye lango lililovunjika bado ni lango lililovunjika.

Soma sifa ya sasa

Kagua mpangilio kabla ya kubadilisha chochote, ukitumia describe ya kusoma-tu kwa instansi, mradi na eneo linalokusudiwa:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Thamani ya false ina umuhimu tu ikiwa VM hii inapaswa kuwa hop inayofuata. Ikiwa ndivyo, sehemu iliyobaki ya njia bado inapaswa kukaguliwa kwa peke yake, kwa sababu sifa ni mstari mmoja katika mnyororo mrefu.

Sasisha instansi iliyopo

Utaratibu wa Google wa kusasisha sifa za instansi huuhamisha rasilimali ya sasa, hubadilisha sifa na huwasilisha matokeo. Huu ni mtiririko wa kazi tofauti na bendera ya --can-ip-forward wakati wa kuunda, na ndio unaofanya kazi kwenye VM inayoendesha.

Kwanza hamisha ufafanuzi kwenda faili ya ndani, na uweke nakala isiyobadilika kwa kulinganisha:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Katika faili hiyo iliyohamishwa, weka sifa na usibadilishe kitu kingine:

canIpForward: true

Hifadhi rasilimali yote, ikiwa ni pamoja na alama ya vidole vyake. Kubadilisha faili kwa hati ya YAML ya mstari mmoja, au kuunganisha mabadiliko yasiyohusiana ya aina ya mashine, diski au kiolesura katika uwasilishaji mmoja, ndiyo njia ambayo mabadiliko ya sifa huwa usumbufu.

Omba utaratibu wa usasishaji uthibitishe faili na kuripoti kile ambacho kingehitajika, kabla ya mabadiliko yoyote halisi kuruhusiwa:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Uendeshaji huo wa uthibitishaji hauwashi upitishaji. Soma jibu kuhusu sifa zisizo halali na kuhusu hatua inayosemwa inahitajika. Kwa mabadiliko haya yaliyotengwa, hatua iliyoandikwa ni REFRESH. Ikiwa matokeo yanaomba kuwasha upya, faili ina zaidi ya sifa uliyokusudia kubadilisha, kwa hiyo ikague badala ya kutoa kibali cha kuwasha upya.

Tumia faili iliyokaguliwa kwa kikomo cha refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Kagua kwamba operesheni ilikamilika na uendeshe amri ya describe tena. Ikiwa alama ya vidole hailingani tena, mtu mwingine alibadilisha instansi wakati unahariri, kwa hiyo hamisha nakala mpya na ukague mabadiliko tena badala ya kulazimisha faili yako ya zamani.

Mgeni bado anapaswa kuelekeza pakiti

Ruhusa ya wingu haifanyi kifaa kuwa kielekezi. Thibitisha kwamba njia ya VPC inachagua VM hii kama hop inayofuata kwa kiambishi cha lengo, na kwamba mgeni anaelekeza kati ya handaki na kiolesura sahihi huku sera yake ya upitishaji ikiwa imewashwa.

Sera ya ngome lazima iruhusu mtiririko wa ndani na vilevile msikilizaji wa nje. Kufungua lango la VPN pekee kunaeleza usafirishaji uliosimbwa na haisemi chochote kuhusu ubadilishanaji wa programu ndani yake.

Mwisho, lengo linahitaji njia ya kurudi kwenye dimbwi la wateja, au muundo lazima utafsiri vyanzo kwa makusudi. Ikiwa lengo linaona trafiki iliyotafsiriwa, kagua chanzo kilichotafsiriwa; ikiwa muundo unahifadhi dimbwi, kagua dimbwi hilo katika njia ya kurudi na kanuni za ufikiaji. Kuongeza NAT kabla ya kuamua ni muundo gani unataka kunaficha njia inayokosekana na kubadilisha sera ambayo lengo linaona.

Kwenye lango la Linux, upitishaji wa kernel ni sehemu ya usanidi wa mgeni. Kifaa cha pfSense kina kifani chake, na kunakili amri ya sysctl ya Linux ndani yake si hatua inayolingana.

Thibitisha kutoka kwa mteja anayehitaji ufikiaji

Jaribu kutoka kwa mteja wa VPN kwenda huduma moja lengwa, si kutoka kwa lango lenyewe. Muunganisho ulioanzishwa kwenye lango hutumia chanzo tofauti na haufanyi kamwe kanuni za upitishaji ulizowasha hivi punde.

Rekodi sifa katika chochote kinachosimamia kifaa. VM iliyorekebishwa kwa mkono hufanya kazi hadi uingizwaji wake unaofuata urudishe kwa utulivu mpangilio wa awali, na kushindwa huko kutaonekana kama kudorora kwa programu ya VPN.

Mpangilio wa kazi: soma sifa, hamisha na uhariri mstari mmoja, thibitisha kwa NO_EFFECT, tumia kwa REFRESH, thibitisha kwamba mgeni anapitisha, kisha jaribu kutoka kwa mteja.