Galluogi anfon IP ymlaen ar borth GCE VPN sy'n bodoli eisoes
Mae canIpForward yn briodwedd y gellir ei diweddaru, nid yn rheswm i ailadeiladu'r VM. Allforiwch yr adnodd, newidiwch un llinell, dilyswch, yna cymhwyswch gyda refresh.
Crëwyd y VM heb anfon IP ymlaen, mae eisoes yn rhedeg y meddalwedd VPN, a'r reddf yw ei ailadeiladu o'r templed gyda'r faner wedi'i gosod. Mae'r ailadeiladu hwnnw'n ddiangen. Mae Compute Engine yn datgelu canIpForward fel priodwedd y gellir ei diweddaru, ac mae'r llwybr diweddaru dogfennol yn ei chymhwyso gyda refresh yn lle ailgychwyn. Yr hyn y mae'r faner yn ei reoli mewn gwirionedd sy'n gul: hebddo, mae'r platfform yn gollwng pecynnau sy'n cyrraedd y rhiant ond nad ydynt wedi'u cyfeirio at gyfeiriad y rhiant ei hun. Mae porth sy'n anfon traffig peiriannau eraill ymlaen yn gwneud yn union hynny, felly rhaid i'r faner fod ymlaen. Popeth wedyn yw ffurfweddiad y gwesteiwr a chyfarwyddo, nad yw'r faner yn cyffwrdd â nhw.
Beth mae'r faner yn ei ganiatáu, a beth nad yw
Gydag anfon ymlaen wedi'i analluogi, mae'r platfform yn trin y rhiant fel pen draw. Mae pecynnau y mae eu cyrchfan yn gyfeiriad y rhiant ei hun yn cael eu danfon; nid yw pecynnau y dylai'r rhiant eu trosglwyddo ar ran rhywun arall yn cael eu danfon.
Gydag anfon ymlaen wedi'i alluogi, gall y rhiant weithredu fel naid nesaf ar gyfer llwybr VPC, a dyna'r rôl y mae angen ei chael ar gyfer teclyn VPN. Nid yw'r faner yn dweud dim am waliau tân, cyfarwyddo'r gwesteiwr, ffurfweddiad y twnnel na llwybrau dychwelyd, ac mae gwerth true ar borth sydd wedi torri yn dal i fod yn borth sydd wedi torri.
Darllenwch y briodwedd bresennol
Archwiliwch y gosodiad cyn newid unrhyw beth, gan ddefnyddio describe darllen-yn-unig yn erbyn y rhiant, y prosiect a'r parth a fwriedir:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
Mae gwerth false yn bwysig yn unig os yw'r VM hwn i fod yn naid nesaf. Os ydyw, rhaid dal i wirio gweddill y llwybr ar wahân, oherwydd un llinell mewn cadwyn hirach yw'r briodwedd.
Diweddarwch y rhiant sy'n bodoli
Mae gweithdrefn diweddaru priodweddau rhiant Google yn allforio'r adnodd presennol, yn addasu'r briodwedd ac yn cyflwyno'r canlyniad. Mae hwnnw'n llif gwaith gwahanol i'r faner --can-ip-forward ar adeg creu, a hwn yw'r un sy'n gweithio ar VM sy'n rhedeg.
Allforiwch y diffiniad i ffeil leol yn gyntaf, a chadwch gopi heb ei newid ar gyfer cymharu:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
Yn y ffeil allforiedig honno, gosodwch y briodwedd a pheidiwch â newid dim arall:
canIpForward: true
Cadwch yr adnodd cyfan, gan gynnwys ei ôl-bys. Disodli'r ffeil â dogfen YAML un llinell, neu grwpio golygiadau di-gysylltiad i fath peiriant, disg neu ryngwyneb yn yr un cyflwyniad, yw'r ffordd y mae newid priodwedd yn dod yn doriad gwasanaeth.
Gofynnwch i'r mecanwaith diweddaru ddilysu'r ffeil ac adrodd beth y byddai ei angen, cyn caniatáu unrhyw newid gwirioneddol:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
Nid yw'r rhediad dilysu hwnnw yn galluogi anfon ymlaen. Darllenwch yr ymateb am briodweddau annilys ac am y weithred y dywed fod ei hangen. Ar gyfer y newid ynysig hwn, y weithred ddogfennol yw REFRESH. Os yw'r canlyniad yn gofyn am ailgychwyn, mae'r ffeil yn cynnwys mwy na'r briodwedd y gwnaethoch fwriadu ei newid, felly archwiliwch hi yn lle caniatáu'r ailgychwyn.
Cymhwyswch y ffeil a adolygwyd gyda'r terfyn refresh:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH
Gwiriwch fod y llawdriniaeth wedi'i chwblhau a rhedwch y gorchymyn describe eto. Os nad yw'r ôl-bys yn cyfateb mwyach, mae rhywun arall wedi newid y rhiant tra oeddech yn golygu, felly allforiwch gopi ffres ac adolygwch y newid eto yn lle gorfodi'ch ffeil hen ffasiwn drwodd.
Rhaid i'r gwesteiwr gyfarwyddo'r pecyn o hyd
Nid yw caniatâd cwmwl yn gwneud y teclyn yn llwybrydd. Cadarnhewch fod llwybr VPC yn dewis y VM hwn fel y naid nesaf ar gyfer y rhagddodiad cyrchfan, a bod y gwesteiwr yn cyfarwyddo rhwng y twnnel a'r rhyngwyneb cywir gyda'i bolisi anfon ymlaen ei hun wedi'i alluogi.
Rhaid i bolisi'r wal dân ganiatáu'r llif mewnol yn ogystal â'r gwrandäwr allanol. Mae agor porth VPN yn unig yn disgrifio'r cludiant amgryptiedig ac yn dweud dim am y cyfnewid rhaglen y tu mewn iddo.
Yn olaf, mae angen llwybr dychwelyd i'r pwll cleientiaid ar y cyrchfan, neu mae'n rhaid i'r cynllun gyfieithu ffynonellau'n fwriadol. Os yw'r cyrchfan yn gweld traffig cyfieithiedig, gwiriwch y ffynhonnell gyfieithiedig; os yw'r cynllun yn cadw'r pwll, gwiriwch y pwll hwnnw yn y llwybr dychwelyd a'r rheolau mynediad. Mae ychwanegu NAT cyn penderfynu pa gynllun yr ydych ei eisiau yn cuddio llwybr coll ac yn newid y polisi y mae'r cyrchfan yn ei weld.
Ar borth Linux, mae anfon ymlaen yn y cnewyllyn yn rhan o ffurfweddiad y gwesteiwr. Mae gan declyn pfSense ei gyfatebydd ei hun, ac nid yw copïo gorchymyn sysctl Linux iddo yw'r cam cyfatebol.
Gwirwch o'r cleient sydd angen mynediad
Profwch o gleient VPN i un gwasanaeth targed, nid o'r porth ei hun. Mae cysylltiad a gychwynnir ar y porth yn defnyddio ffynhonnell wahanol ac yn byth yn arfer y rheolau anfon ymlaen yr ydych newydd eu galluogi.
Cofnodwch y briodwedd yn yr hyn bynnag sy'n rheoli'r teclyn. Mae VM a gywirwyd â llaw yn gweithio hyd at ei ddisodliad nesaf, sy'n ailosod y gosodiad gwreiddiol yn dawel, a bydd y methiant hwnnw'n edrych fel dirywiad yn y meddalwedd VPN.
Trefn y gwaith: darllenwch y briodwedd, allforiwch a golygwch un llinell, dilyswch gyda NO_EFFECT, cymhwyswch gyda REFRESH, cadarnhewch fod y gwesteiwr yn anfon ymlaen, yna profwch o gleient.