હાલના GCE VPN ગેટવે પર IP ફોરવર્ડિંગ સક્ષમ કરો
canIpForward એ અપડેટ કરી શકાય તેવી મિલકત છે, VM ફરીથી બનાવવાનું કારણ નથી. રિસોર્સ એક્સપોર્ટ કરો, એક લાઇન બદલો, માન્ય કરો, પછી refresh સાથે લાગુ કરો.
VM IP ફોરવર્ડિંગ વિના બનાવવામાં આવી હતી, તે પહેલેથી જ VPN સોફ્ટવેર ચલાવે છે, અને સહજ વૃત્તિ એ છે કે ફ્લેગ સેટ કરીને ટેમ્પલેટમાંથી તેને ફરીથી બનાવવું. તે પુનર્નિર્માણ બિનજરૂરી છે. Compute Engine canIpForwardને અપડેટ કરી શકાય તેવી મિલકત તરીકે આપે છે, અને દસ્તાવેજીકૃત અપડેટ માર્ગ તેને રીસ્ટાર્ટને બદલે refresh સાથે લાગુ કરે છે. ફ્લેગ ખરેખર જે નિયંત્રિત કરે છે તે સાંકડું છે: તેના વિના પ્લેટફોર્મ એ પેકેટો કાઢી નાખે છે જે ઇન્સ્ટન્સ પર પહોંચે છે પરંતુ ઇન્સ્ટન્સના પોતાના સરનામા પર સંબોધિત નથી. બીજા મશીનોનું ટ્રાફિક ફોરવર્ડ કરતો ગેટવે બરાબર એ જ કરે છે, તેથી ફ્લેગ ચાલુ હોવો જોઈએ. તે પછીનું બધું ગેસ્ટ કન્ફિગરેશન અને રૂટિંગ છે, જેને ફ્લેગ સ્પર્શતું નથી.
ફ્લેગ શું મંજૂરી આપે છે, અને શું નહીં
ફોરવર્ડિંગ બંધ હોય ત્યારે પ્લેટફોર્મ ઇન્સ્ટન્સને અંતિમ બિંદુ તરીકે ગણે છે. જે પેકેટોનું ગંતવ્ય ઇન્સ્ટન્સનું પોતાનું સરનામું છે તે પહોંચાડવામાં આવે છે; જે પેકેટો ઇન્સ્ટન્સે બીજા વતી આગળ મોકલવાના છે તે નહીં.
ફોરવર્ડિંગ ચાલુ હોય ત્યારે ઇન્સ્ટન્સ VPC રૂટ માટે આગળનું હોપ તરીકે કાર્ય કરી શકે છે, અને તે જ VPN ઉપકરણને જરૂરી ભૂમિકા છે. ફ્લેગ ફાયરવોલ, ગેસ્ટ રૂટિંગ, ટનલ કન્ફિગરેશન કે રિટર્ન પાથ વિશે કંઈ કહેતું નથી, અને તૂટેલા ગેટવે પર true મૂલ્ય હજી પણ તૂટેલો ગેટવે છે.
વર્તમાન મિલકત વાંચો
કંઈપણ બદલતા પહેલા સેટિંગની તપાસ કરો, ઇચ્છિત ઇન્સ્ટન્સ, પ્રોજેક્ટ અને ઝોન સામે માત્ર-વાંચન describe વાપરીને:
gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'
false મૂલ્ય ત્યારે જ મહત્વનું છે જ્યારે આ VM આગળનું હોપ હોવાનું હોય. જો એમ હોય, તો બાકીનો માર્ગ હજી પણ અલગથી તપાસવો પડશે, કારણ કે મિલકત લાંબી સાંકળમાં એક લાઇન છે.
હાલનું ઇન્સ્ટન્સ અપડેટ કરો
Google ની ઇન્સ્ટન્સ-મિલકત અપડેટ પ્રક્રિયા વર્તમાન રિસોર્સ એક્સપોર્ટ કરે છે, મિલકત બદલે છે અને પરિણામ સબમિટ કરે છે. તે બનાવટ સમયના --can-ip-forward ફ્લેગ કરતાં અલગ વર્કફ્લો છે, અને ચાલતી VM પર કામ કરે છે તે આ જ છે.
પહેલા વ્યાખ્યાને સ્થાનિક ફાઇલમાં એક્સપોર્ટ કરો, અને સરખામણી માટે અબદલ કોપી રાખો:
gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml
તે એક્સપોર્ટ કરેલી ફાઇલમાં મિલકત સેટ કરો અને બીજું કંઈ બદલશો નહીં:
canIpForward: true
આખો રિસોર્સ, તેની ફિંગરપ્રિન્ટ સહિત, રાખો. ફાઇલને એક-લાઇન YAML દસ્તાવેજથી બદલવી, અથવા અસંબંધિત મશીન-પ્રકાર, ડિસ્ક કે ઇન્ટરફેસ ફેરફારોને એક જ સબમિશનમાં જોડવા, એ જ રીતે મિલકત-ફેરફાર વિક્ષેપ બને છે.
કોઈપણ અસરકારક ફેરફારની મંજૂરી પહેલા અપડેટ મિકેનિઝમને ફાઇલ માન્ય કરવા અને તે શું જરૂરી ગણશે તે જણાવવા કહો:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT
તે માન્યતા રન ફોરવર્ડિંગ સક્ષમ કરતું નથી. પ્રતિભાવમાં અમાન્ય મિલકતો અને જે ક્રિયા જરૂરી કહેવાય છે તે વાંચો. આ અલગ ફેરફાર માટે દસ્તાવેજીકૃત ક્રિયા REFRESH છે. જો પરિણામ રીસ્ટાર્ટ માગે, તો ફાઇલમાં તમે બદલવા માંગતા હતા તે મિલકત કરતાં વધુ છે, તેથી રીસ્ટાર્ટ આપવાને બદલે તેની તપાસ કરો.
સમીક્ષિત ફાઇલને refresh મર્યાદા સાથે લાગુ કરો:
gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH
ઓપરેશન પૂર્ણ થયું છે તે તપાસો અને describe કમાન્ડ ફરી ચલાવો. જો ફિંગરપ્રિન્ટ હવે મેળ ખાતું નથી, તો તમે સંપાદન કરતી વખતે બીજા કોઈએ ઇન્સ્ટન્સ બદલ્યું છે, તેથી તમારી જૂની ફાઇલ ફોર્સ કરવાને બદલે નવી કોપી એક્સપોર્ટ કરો અને ફેરફારની ફરી સમીક્ષા કરો.
ગેસ્ટે હજી પણ પેકેટ રૂટ કરવું પડશે
ક્લાઉડ પરવાનગી ઉપકરણને રાઉટર બનાવતી નથી. ખાતરી કરો કે VPC રૂટ ગંતવ્ય પ્રીફિક્સ માટે આ VMને આગળના હોપ તરીકે પસંદ કરે છે, અને ગેસ્ટ પોતાની ફોરવર્ડિંગ નીતિ સક્ષમ રાખીને ટનલ અને યોગ્ય ઇન્ટરફેસ વચ્ચે રૂટ કરે છે.
ફાયરવોલ નીતિએ આંતરિક પ્રવાહ અને બાહ્ય શ્રોતા બંનેને મંજૂરી આપવી પડશે. ફક્ત VPN પોર્ટ ખોલવો એન્ક્રિપ્ટેડ ટ્રાન્સપોર્ટનું વર્ણન કરે છે અને તેની અંદરના એપ્લિકેશન વિનિમય વિશે કંઈ કહેતું નથી.
અંતે, ગંતવ્યને ક્લાયન્ટ પૂલ સુધી રિટર્ન પાથની જરૂર છે, અથવા ડિઝાઇને જાણી જોઈને સ્રોતનું ભાષાંતર કરવું પડશે. જો ગંતવ્ય ભાષાંતરિત ટ્રાફિક જુએ, તો ભાષાંતરિત સ્રોત તપાસો; જો ડિઝાઇન પૂલ જાળવી રાખે, તો રિટર્ન રૂટ અને એક્સેસ નિયમોમાં તે પૂલ તપાસો. કઈ ડિઝાઇન જોઈએ તે નક્કી કરતા પહેલા NAT ઉમેરવું ખૂટતો રૂટ છુપાવે છે અને ગંતવ્ય જે નીતિ જુએ તે બદલે છે.
Linux ગેટવે પર, કર્નલ ફોરવર્ડિંગ ગેસ્ટ કન્ફિગરેશનનો ભાગ છે. pfSense ઉપકરણનું પોતાનું સમકક્ષ છે, અને તેમાં Linux sysctl કમાન્ડ કોપી કરવી એ મેળ ખાતું પગલું નથી.
જે ક્લાયન્ટને એક્સેસ જોઈએ તેની બાજુથી ચકાસો
ગેટવે પરથી નહીં, પણ VPN ક્લાયન્ટથી એક લક્ષ્ય સેવા સુધી પરીક્ષણ કરો. ગેટવે પર શરૂ થયેલું કનેક્શન અલગ સ્રોત વાપરે છે અને તમે હમણાં સક્ષમ કરેલા ફોરવર્ડિંગ નિયમોનો ક્યારેય ઉપયોગ કરતું નથી.
ઉપકરણનું સંચાલન જે પણ કરે તેમાં મિલકત નોંધો. હાથે સુધારેલી VM ત્યાં સુધી કામ કરે છે જ્યાં સુધી તેનું આગળનું રિપ્લેસમેન્ટ મૂળ સેટિંગ શાંતિથી ફરી ન લાવે, અને તે નિષ્ફળતા VPN સોફ્ટવેરમાં રીગ્રેશન જેવી દેખાશે.
કામનો ક્રમ: મિલકત વાંચો, એક્સપોર્ટ કરો અને એક લાઇન સંપાદિત કરો, NO_EFFECT સાથે માન્ય કરો, REFRESH સાથે લાગુ કરો, ગેસ્ટ ફોરવર્ડ કરે છે તેની ખાતરી કરો, પછી ક્લાયન્ટથી પરીક્ષણ કરો.