પ્લાન સ્વચ્છ રીતે લાગુ થાય છે, ટનલ ઉપર આવે છે, અને કન્સોલ તેને નીતિ-આધારિત કહે છે. ટ્રાફિક હજી પણ પસાર થતો નથી, અને Terraform સંસાધનમાં રૂટ-આધારિત ટૉગલ શોધવાનું ક્યાંય પહોંચતું નથી, કારણ કે એવું કોઈ ક્ષેત્ર નથી. Classic VPN-માં રૂટ-આધારિત વર્તન એ મોડ નથી જે તમે પસંદ કરો। તે ત્યારે મળે છે જ્યારે સ્થાનિક ટ્રાફિક સિલેક્ટર 0.0.0.0/0 હોય, દૂરસ્થ સિલેક્ટર તમે ખરેખર ઇચ્છો તે નેટવર્કની યાદી આપે, અને રૂટ ટનલ તરફ નિર્દેશ કરે. ત્રણ વસ્તુઓ, અને લેબલ તેની પાછળ આવે છે.

ભ્રમ: ટનલ મોડ ક્ષેત્ર

કન્સોલનું લેબલ દર્શાવે છે કે API સિલેક્ટરમાં શું જુએ છે. સંસાધનમાં કંઈ કહેતું નથી કે રૂટ-આધારિત છે, તેથી સાચું મૂલ્ય સેટ કરવા જેવું કંઈ નથી.

તે ક્ષેત્ર શોધવામાં સમસ્યાનો પહેલો કલાક જાય છે, જ્યારે સિલેક્ટરની કિંમતો વાંચવામાં છેલ્લી પાંચ મિનિટ જાય છે.

અહીં રૂટ-આધારિત એટલે શું

Google Classic VPNની રૂટ-આધારિત ટનલને નીતિ-આધારિત ટનલ તરીકે દસ્તાવેજ કરે છે જેમનું સ્થાનિક સિલેક્ટર 0.0.0.0/0 હોય છે. ફક્ત દૂરસ્થ શ્રેણીઓના નામ આપવામાં આવે છે, અને સ્થાનિક બાજુને કોઈપણ સરનામા તરીકે ગણવામાં આવે છે. તેથી જ તમારા રૂપરેખાંકનમાં નિશાની મોડ નહીં, મૂલ્ય છે. બંને સિલેક્ટર સ્પષ્ટ રીતે લખો અને પ્લાન આઉટપુટમાં વાંચો:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

તે સ્નિપેટમાં પીઅર પ્રીફિક્સ ઉદાહરણરૂપ છે; આકાર એ મહત્વનો ભાગ છે.

રૂટ એ અલગ ઑબ્જેક્ટ છે

ટનલ ઑબ્જેક્ટ રૂટ ઇન્સ્ટોલ કરતું નથી. પેકેટ ટનલની નીતિ સાથે મેળ ખાઈ શકે છે અને તેમ છતાં જવાનું સ્થળ ન હોઈ શકે, કારણ કે VPC રૂટિંગ ટેબલ આગલું હોપ નક્કી કરે છે. રૂટને ગંતવ્ય શ્રેણી, નેટવર્ક, આગલા હોપ તરીકે ટનલ અને કોઈપણ વિશાળ વિરુદ્ધ જીતતી પ્રાથમિકતા જોઈએ. તે ભૂલી જવાથી એવી ટનલ મળે છે જે સ્થાપિત હોવાનું જણાવે છે અને એક ચકાસણી જે ક્યારેય VPC છોડતી નથી.

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

ટનલની જ મોડ્યુલમાં રૂટ બનાવો, જેથી સમીક્ષામાં બંને અલગ ન પડે.

પીઅર પર સિલેક્ટર પ્રતિબિંબિત કરો

દૂરસ્થ ઉપકરણ અરીસા-છબી સાથે ગોઠવવું પડે: તેની સ્થાનિક શ્રેણી તમારું દૂરસ્થ સિલેક્ટર છે, અને તેની દૂરસ્થ શ્રેણીએ તે GCP સબનેટને આવરી લેવા જોઈએ જે તમે વાપરવાની અપેક્ષા રાખો છો. કોઈપણ બાજુ સાંકડી થાય તો ફેઝ 1 સફળ થવા છતાં ફેઝ 2 નિષ્ફળ જાય છે. કન્સોલમાં સાચું લાગતું અને કોઈ ટ્રાફિક ન વહેતું રૂપરેખાંકન એનું આ સૌથી સામાન્ય સ્વરૂપ છે.

ફેરફારની સમીક્ષા દરમિયાન બંને બાજુના સિલેક્ટર સાથે સાથે છાપો.

સ્થિર સરનામાને બે એપ્લાયમાં વિભાજિત કરો

અનામત સરનામું અને તેનો સંદર્ભ લેતી ટનલ એક જ એપ્લાયમાં બનાવવી એ અસ્થિરતાનો જાણીતો સ્રોત છે, કારણ કે ફોરવર્ડિંગ નિયમ તેનો ઉપયોગ કરે તે પહેલાં સરનામું અસ્તિત્વમાં હોવું જોઈએ. પહેલા ફક્ત સરનામાનું સંસાધન લાગુ કરો, પછી ગેટવે, ફોરવર્ડિંગ નિયમો અને ટનલ ઉમેરો અને ફરી લાગુ કરો. Terraform બીજા રનમાં સ્થિતિમાંથી હાલનું સરનામું વાંચે છે અને તેનો ફરી ઉપયોગ કરે છે. તે ચૂકી જવાથી ટનલને દરેક એપ્લાયમાં નવું જાહેર સરનામું મળી શકે છે, જે દરેક વખતે પીઅર રૂપરેખાંકન તોડે છે.

હવે બે એપ્લાય દરેક રિલીઝમાં પીઅર ફેરફાર કરતાં સસ્તા છે.

લેબલ નહીં, વાટાઘાટ ચકાસો

લાગુ કર્યા પછી ત્રણ અલગ તથ્યો ચકાસો: ટનલ સ્થાપિત હોવાનું જણાવે છે, રૂટ ઇચ્છિત આગલા હોપ સાથે અસ્તિત્વમાં છે, અને પીઅર ફેઝ 1 અને ફેઝ 2 બંને ચાલુ હોવાનું જણાવે છે.

ટનલ ચાલુ હોવા છતાં ફેઝ 2 નીચે હોવાનો અર્થ બંને બાજુ સિલેક્ટર પર સંમત નથી:

  • એક બાજુ એવું સબનેટ સૂચિબદ્ધ કરે છે જે બીજી બાજુ કરતી નથી.
  • એક બાજુ એવો એગ્રીગેટ વાપરે છે જે બીજી બાજુએ સાંકડો કર્યો છે.
  • રૂટ અસ્તિત્વમાં છે પણ બીજી ટનલ તરફ નિર્દેશ કરે છે.

Classic VPN એ HA VPN કરતાં નીચા SLA સાથેની એક ટનલ છે, અને HA VPN બે ઇન્ટરફેસ, બે ટનલ અને જુદા સંસાધન પ્રકારો સાથે BGP વાપરે છે. ક્લાસિક ઉદાહરણને HA રૂપરેખાંકનમાં નકલ કરીને સિલેક્ટર ક્ષેત્રો એ જ રીતે વર્તશે તેવી અપેક્ષા રાખવી એ અલગ ભૂલ છે જે ટાળવા યોગ્ય છે. ટનલના ક્ષેત્રો પોતે google_compute_vpn_tunnel સંદર્ભમાં।

સંબંધિત લેખો