Cloud VPN-ന്റെ BGP വിലാസങ്ങൾ NIC-യിൽ അല്ല, ടണലിനുള്ളിലാണ്

VPN-നുള്ള Cloud Router പേജ് തുറക്കുമ്പോൾ 169.254.0.0/16-ൽ വിലാസമുള്ള ഒരു BGP സെഷൻ നിങ്ങളെ നോക്കുന്നു. സ്വാഭാവിക പ്രതികരണം ആ വിലാസം VM-ൽ എവിടെയോ വെച്ച് സെഷൻ ഉയരാൻ കാത്തിരിക്കുക എന്നതാണ്. ആ പ്രതികരണം ഒരു പ്രത്യേക തരത്തിൽ തെറ്റാണ്: ജോഡി IPsec ടണൽ സൃഷ്ടിക്കുന്ന ലോജിക്കൽ ലിങ്കിനുള്ളതാണ്, യന്ത്രത്തിന്റെ സാധാരണ നെറ്റ്വർക്ക് ഇന്റർഫേസിനുള്ളതല്ല. NIC-യിൽ നിങ്ങൾ ചേർക്കുന്നതൊന്നും ടണലിനെ BGP വഹിക്കാൻ നിർബന്ധിക്കുന്നില്ല.

ജോഡി ഹോസ്റ്റിൽ ചേർക്കുന്നതിനുപകരം സ്റ്റാക്കിലൂടെ താഴേക്ക് പിന്തുടരുക.

കൺസോൾ ജോഡി കാണിക്കുന്നിടത്തുനിന്ന് തുടങ്ങുക

സെഷൻ പേജിൽ Cloud Router-ന്റെ BGP വിലാസവും പിയർ വിലാസവും പട്ടികപ്പെടുത്തുന്നു, IPv4 HA VPN-ന് രണ്ടും link-local ആണ്. അവയുടെ അടുത്ത് ടണലുകൾ അവസാനിപ്പിക്കുന്ന പുറം ഗേറ്റ്വേ വിലാസങ്ങളുണ്ട്. ഇവ വ്യത്യസ്ത വസ്തുക്കളാണ്: link-local ജോഡി ഉള്ളിൽ ജീവിക്കുന്നു, ഗേറ്റ്വേ വിലാസങ്ങൾ പുറത്ത് ജീവിക്കുന്നു, മറ്റെന്തെങ്കിലും പ്രവർത്തിക്കുന്നതിന് മുമ്പ് അവ റൂട്ട് ചെയ്യാവുന്നതായിരിക്കണം.

കോൺഫിഗറേഷൻ ഫയൽ തുറക്കുന്നതിന് മുമ്പ് മൂന്നും എഴുതിവെക്കുക, കാരണം അവ കൂട്ടിക്കലർത്തുന്നതാണ് മുഴുവൻ പരാജയരീതി.

അത് വഹിക്കുന്ന ടണലിലേക്ക് താഴേക്ക് ഇറങ്ങുക

രണ്ട് ഗേറ്റ്വേകൾക്കിടയിൽ IPsec സുരക്ഷാ അസോസിയേഷൻ ഉണ്ടായാൽ മാത്രമേ link-local ജോഡിക്ക് അർഥമുള്ളൂ. Google വശത്ത് HA VPN ടണലുകൾ അത് രണ്ട് ഇന്റർഫേസുകളിൽ സൃഷ്ടിക്കുന്നു; നിങ്ങളുടെ വശത്ത് പിയർ ചർച്ച ചെയ്തതാണ് അത്. ആദ്യം swanctl --list-sas ഉപയോഗിച്ച് ഡാറ്റ അസോസിയേഷൻ പരിശോധിച്ച് ഏത് ടണൽ ഏത് ഇന്റർഫേസിൽ ഉയർന്നിരിക്കുന്നു എന്ന് എഴുതുക, കാരണം ചത്ത ടണലിന് മുകളിൽ ആരോഗ്യകരമായ BGP സെഷൻ അസാധ്യമാണ്, പ്രതീക്ഷയുള്ള കോൺഫിഗറേഷനുള്ള ചത്ത ടണൽ സാധാരണമാണ്.

BGP പാക്കറ്റ് ആന്തരിക IP ട്രാഫിക്കാണ്. പുറം നെറ്റ്വർക്ക് അത് ഒരിക്കലും കാണുന്നില്ല, അതിനാൽ ഒരു സ്വിച്ചിനും ഒരേ VLAN-ൽ രണ്ട് വിലാസങ്ങളും ആവശ്യമില്ല.

ഇപ്പോൾ Linux പിയർ പൊരുത്തപ്പെടാൻ കോൺഫിഗർ ചെയ്യുക

പിന്തുണയുള്ള ടണൽ ഡിസൈൻ തിരഞ്ഞെടുത്ത് അകത്തെ വിലാസങ്ങൾ അത് തീരുമാനിക്കട്ടെ. റൂട്ട് അധിഷ്ഠിത ഇന്റർഫേസിൽ, റൂട്ടിംഗ് എൻട്രിയും ചർച്ച ചെയ്ത ട്രാഫിക് സെലക്ടറുകളും യോജിക്കണം, കാരണം ഇന്റർഫേസ് നാമം മാത്രം ഒന്നിനും അനുമതി നൽകുന്നില്ല. BIRD-നെ അകത്തെ പ്രാദേശിക വിലാസത്തിലേക്കും Cloud Router-ന്റെ അകത്തെ വിലാസത്തിലേക്കും തിരിച്ചുവിടുക, സെഷൻ പേജിൽ നിന്ന് AS നമ്പറുകൾ സജ്ജീകരിക്കുക, സംരക്ഷിത പാതയ്ക്കുള്ളിൽ TCP 179 അനുവദിക്കുക. വിദൂര പുറം വിലാസത്തിലേക്കുള്ള റൂട്ട് ഭൗതിക അപ്‌ലിങ്കിൽ നിലനിർത്തുക, ടണൽ സ്വന്തം ഗതാഗതം പിടിച്ചെടുക്കാതിരിക്കാൻ.

സ്വയം റൂട്ട് ചെയ്യുന്ന ടണൽ ഒരു ഹാൻഡ്ഷേക്കോടുകൂടിയ ലൂപ്പാണ്, ഒരു മണിക്കൂർ ഫയർവാൾ പ്രശ്നം പോലെ തോന്നും.

ഓരോ ഘട്ടവും ക്രമത്തിൽ പരിശോധിക്കുക, എല്ലാം ഒരുമിച്ചല്ല

ഘട്ടങ്ങൾ കടന്നുപോകുക: സുരക്ഷാ അസോസിയേഷൻ ഉയർന്നു, ടണൽ വിലാസത്തിൽ നിന്ന് അകത്തെ പിയർ എത്താവുന്നതാണ്, BGP സെഷൻ സ്ഥാപിതമായി, പ്രിഫിക്സുകൾ സ്വീകരിച്ചു, പിന്നീട് വർക്ക്ലോഡ് പ്രിഫിക്സ് യഥാർഥത്തിൽ ഉപയോഗിച്ചു. birdc show protocols മൂന്നാമത്തെ ചോദ്യത്തിന് മാത്രം ഉത്തരം നൽകുന്നു, അതുകൊണ്ടാണ് ആളുകൾ നേരത്തെ വിജയം പ്രഖ്യാപിക്കുന്നത്.

സ്ഥാപിതമായ അയൽക്കാരൻ ഇരുവശവും ആവശ്യമായ പ്രിഫിക്സുകൾ പ്രഖ്യാപിച്ചു എന്നോ ആ റൂട്ടുകൾ മുൻഗണനയായി ഇൻസ്റ്റാൾ ചെയ്തു എന്നോ ഉറപ്പ് നൽകുന്നില്ല.

സെഷൻ സ്ഥാപിതമായിട്ടും ട്രാഫിക് ഇപ്പോഴും തെറ്റായ വഴിയിലൂടെ പോകുന്നുവെങ്കിൽ, പ്രഖ്യാപിത പ്രിഫിക്സുകളെ റൂട്ടിംഗ് ടേബിൾ അവയോട് എന്ത് ചെയ്യുന്നു എന്നതുമായി താരതമ്യം ചെയ്യുക. മറ്റൊരിടത്ത് കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടോ മറ്റൊരു വഴിക്കുള്ള മുൻഗണനയോ നിങ്ങൾക്ക് പ്രവർത്തിക്കുന്ന BGP സെഷനും ഉപയോഗപ്രദമല്ലാത്ത ഫോർവേഡിംഗും നൽകുന്നു.

ഇത് Router Appliance-ൽ പ്രയോഗിക്കുന്നതിന് മുമ്പ് നിർത്തുക

Network Connectivity Center Router Appliance മറ്റൊരു അറ്റാച്ച്മെന്റ് മാതൃകയാണ്. അതിന്റെ Cloud Router പിയർമാർ HA VPN-ന്റെ link-local ജോഡിക്കുപകരം VPC, സബ്നെറ്റ് ക്രമീകരണത്തിൽ നിന്നുള്ള ആന്തരിക വിലാസങ്ങൾ ഉപയോഗിക്കുന്നു. യഥാർഥ ലക്ഷ്യം റൂട്ടിംഗ് VM-മായി BGP ആണെങ്കിൽ, link-local സെഷൻ പകർത്തുന്നതിനുപകരം ആ ഉൽപ്പന്നത്തിന്റെ ഇന്റർഫേസ് ആവശ്യകതകൾ പാലിക്കുക.

link-local പരിധി ഇപ്പോഴും പറയുന്നത് അർഥമാക്കുന്നു. ലോജിക്കൽ ടണൽ ഈ അയൽ‌ബന്ധം നൽകുന്നു, VPC-യിലുടനീളം ഏകപക്ഷീയമായ link-local ലക്ഷ്യസ്ഥാനങ്ങൾ റൂട്ട് ചെയ്യാൻ അത് അനുമതി നൽകുന്നില്ല.