GCP HA VPN: BGP സെഷൻ Waiting for peer-ൽ നിൽക്കുന്നു, വിലാസ ജോടിയുടെ കൈമാറ്റം
Cloud VPN BGP സെഷൻ Waiting for peer-ൽ നിൽക്കുന്നുണ്ടെങ്കിൽ സാധാരണയായി ടണലിന്റെയും പിയറിന്റെയും വിലാസങ്ങൾ കൈമാറിയിട്ടുണ്ടാകും. എന്തെങ്കിലും വീണ്ടും നിർമ്മിക്കുന്നതിന് മുമ്പ് ജോടി പരിശോധിക്കുക.
Cloud VPN ടണലിൽ ഒരിക്കലും Established-ൽ എത്താത്ത BGP സെഷൻ സാധാരണയായി റൂട്ടിംഗ് പ്രശ്നമല്ല. ഇത് വയറിംഗ് പ്രശ്നമാണ്: പരസ്പരം പ്രതിബിംബിക്കേണ്ട രണ്ട് വിലാസങ്ങൾ തെറ്റായ ക്രമത്തിൽ നൽകിയിട്ടുണ്ട്, അല്ലെങ്കിൽ ആദ്യ ടണലിന്റെ ജോടി രണ്ടാമത്തേതിൽ വീണ്ടും ഉപയോഗിച്ചു. ടണൽ തന്നെ പൂർണ്ണമായി ആരോഗ്യമുള്ളതായിരിക്കാം, സെഷൻ Waiting for peer-ൽ നിൽക്കുമ്പോൾ, കാരണം IPsec-ഉം BGP-യും ഒരേ രണ്ട് അന്ത്യബിന്ദുക്കൾക്കിടയിലെ വേറിട്ട ചർച്ചകളാണ്. എന്തെങ്കിലും വീണ്ടും നിർമ്മിക്കുന്നതിന് മുമ്പ് ഇവയിൽ ഏതാണ് തകർന്നതെന്ന് തീരുമാനിക്കുക.
ഒരു ചോദ്യം മിക്കവാറും കേസുകൾ തീർപ്പാക്കുന്നു: പിയർ ഉപകരണം Cloud Router-ന്റെ വിലാസം കാണുന്നുണ്ടോ?
ടണൽ അവസ്ഥയും സെഷൻ അവസ്ഥയും വേറിട്ട പരിശോധനകളാണ്
ആദ്യം IKE-യും ESP-യും വരുന്നു. ടണൽ സ്ഥാപിതമല്ലെങ്കിൽ അതിനുള്ളിലെ ഒന്നും പ്രധാനമല്ല, BGP വിലാസത്തെക്കുറിച്ചുള്ള ചർച്ച നേരത്തേയാണ്. ടണലിന്റെ അവസ്ഥയും വിശദമായ അവസ്ഥയും വായിക്കുക, തുടർന്ന് അതേ ടണലിനുള്ള റൂട്ടറിന്റെ BGP പിയർ അവസ്ഥ വായിക്കുക.
ടണൽ പ്രവർത്തിക്കുമ്പോൾ അതിന്റെ BGP പിയർ നിലച്ചിരിക്കുന്നുവെങ്കിൽ, തകരാർ സെഷനിലേക്ക് ചുരുങ്ങുന്നു: പിയർ വിലാസം, ASN, അല്ലെങ്കിൽ ആന്തരിക വിലാസത്തിൽ എത്തുന്ന TCP 179. ടണൽ പ്രവർത്തിക്കുന്നു, സെഷൻ പ്രവർത്തിക്കുന്നു, കൂടാതെ ഇപ്പോഴും VPC-യിൽ റൂട്ടുകളില്ല ഇത് മൂന്നാമത്തെ കേസാണ്. വിലാസങ്ങൾ മാറ്റുന്നത് അവിടെ സഹായിക്കില്ല, കാരണം സെഷൻ ഇതിനകം പ്രവർത്തിക്കുന്നു, പ്രിഫിക്സ് പ്രഖ്യാപിക്കപ്പെടുന്നില്ല അല്ലെങ്കിൽ മുൻഗണന നൽകുന്നില്ല എന്ന് മാത്രം. ഈ മൂന്ന് കേസുകൾ വേർതിരിച്ചു നിർത്തുന്നതാണ് ജോലിയുടെ വലിയ ഭാഗം.
ഓരോ ടണലിനും ഇരു അറ്റങ്ങളും നിറച്ച സ്വന്തം /30 വേണം
ഓരോ HA VPN ടണലിനും 169.254.0.0/16-ൽ നിന്ന് ഒരു link-local /30 ലഭിക്കുന്നു, ഒരു വിലാസം Cloud Router ഇന്റർഫേസിലും മറ്റൊന്ന് നിങ്ങളുടെ പിയറിലും. പിയർ ഫീൽഡ് ദൂരെയുള്ള അറ്റം പേരിടണം, ഒരിക്കലും റൂട്ടറിന്റെ സ്വന്തം വിലാസമല്ല.
രണ്ട് ടണലുകൾ എന്നാൽ Cloud Router-ൽ രണ്ട് ഇന്റർഫേസുകൾ, ഓരോന്നിനും വേറെ /30. ടണൽ 0-ന്റെ ജോടി ടണൽ 1-ൽ വീണ്ടും ഉപയോഗിക്കുന്നത് സംഗ്രഹ പട്ടികയിൽ വൃത്തിയായി തോന്നുകയും OPEN പാക്കറ്റിൽ ചാകുകയും ചെയ്യുന്ന തെറ്റാണ്.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
ജോടി കൺസോൾ സംഗ്രഹത്തിൽ നിന്നല്ല, റൂട്ടർ റിസോഴ്സിൽ നിന്ന് വായിക്കുക. സംഗ്രഹം പിയർ വിലാസം തെറ്റായി വായിക്കാൻ എളുപ്പമുള്ള കോളത്തിൽ പട്ടികപ്പെടുത്തുന്നു, ഇന്റർഫേസിന്റെ ipRange-ഉം പിയറിന്റെ peerIpAddress-ഉം ഒരേ /30-ന്റെ എതിർ അറ്റങ്ങൾ വിവരിക്കണം.
കൈമാറ്റം സാധാരണയായി പുനർനിർമ്മാണ വേളയിൽ സംഭവിക്കുന്നു
ടണൽ പുനർനിർമ്മിക്കുമ്പോഴാണ് ജോടികൾ കുരുങ്ങുന്നത്. പഴയ ടണലിന്റെ പിയർ വിലാസം പുതിയ ടണലിന്റെ ഇന്റർഫേസ് ഫീൽഡിലേക്ക് പകർത്തുന്നു, അല്ലെങ്കിൽ പുതിയ സെഷൻ മുൻ സെഷന്റെ പിയറിലേക്ക് തിരിക്കുന്നു. ഏത് വിധമായാലും Cloud Router OPEN പാക്കറ്റുകൾ ഇപ്പോൾ താൻ തന്നെയായ വിലാസത്തിലേക്കോ പിന്നിൽ ടണൽ ഇല്ലാത്ത വിലാസത്തിലേക്കോ അയയ്ക്കുന്നു.
കൺസോൾ തുറക്കുന്നതിന് മുമ്പ് ജോടികൾ എഴുതി വയ്ക്കുക: ടണൽ പേര്, ഇന്റർഫേസ്, റൂട്ടർ വിലാസം, പിയർ വിലാസം, പിയർ ASN. തുടർന്ന് രണ്ട് ടണലുകളും ഒരേസമയം സൃഷ്ടിക്കുക, രണ്ടാമത്തേത് ആദ്യത്തേതിന്റെ ബാക്കി കൊണ്ട് നിറയാതിരിക്കാൻ.
സെഷൻ കാത്തിരിക്കാനുള്ള മറ്റ് മൂന്ന് കാരണങ്ങൾ
ആദ്യത്തേത് പിയർ ASN ആണ്: ഇരു വശവും മറുവശത്തിന്റെ ASN ഉപയോഗിച്ച് ക്രമീകരിക്കണം, പൊരുത്തക്കേട് പിയറിലെത്തുമെങ്കിലും ഒരിക്കലും സ്ഥാപിതമാകില്ല. രണ്ടാമത്തേത് പിയറിന്റെ സ്വന്തം ഫയർവാൾ ആണ്, അത് ടണൽ ഇന്റർഫേസിൽ TCP 179 അനുവദിക്കണം; IKE അല്ലെങ്കിൽ ESP നിയമം അത് ഉൾക്കൊള്ളുന്നില്ല. മൂന്നാമത്തേത് തന്റെ അയൽക്കാരനായി ക്രമീകരിച്ച വിലാസത്തിൽ നിന്ന് വ്യത്യസ്തമായ ഉറവിട വിലാസത്തിൽ നിന്ന് മറുപടി നൽകുന്ന പിയർ ആണ്.
പിയറിന്റെ സ്വന്തം ലോഗ് ആണ് വേർതിരിച്ചറിയൽ. അതിന്റെ BGP സംഗ്രഹത്തിൽ ആ വിലാസത്തിന് അയൽക്കാരൻ ഇല്ലെങ്കിൽ പാക്കറ്റുകൾ എത്തുന്നില്ല, ജോടിയോ പാതയോ തെറ്റാണ്. അയൽക്കാരൻ Active അല്ലെങ്കിൽ Connect-ൽ നിൽക്കുന്നുവെങ്കിൽ പാക്കറ്റുകൾ എത്തുന്നു, സെഷൻ പരാമീറ്ററുകൾ പൊരുത്തപ്പെടുന്നില്ല.
പാക്കറ്റുകൾ സഞ്ചരിക്കുന്ന ക്രമത്തിൽ പരിശോധിക്കുക
പുറത്തേക്ക് പ്രവർത്തിക്കുക: ടണൽ അവസ്ഥ, തുടർന്ന് റൂട്ടറിന്റെ BGP പിയർ അവസ്ഥ, തുടർന്ന് പിയറിന്റെ BGP സംഗ്രഹം, തുടർന്ന് റൂട്ടുകൾ. ആദ്യ രണ്ടും ആരോഗ്യമുള്ളതാണെങ്കിൽ Cloud VPN വശം തിരുത്തുന്നത് നിർത്തി പിയർ ഉപകരണത്തിൽ പ്രവർത്തിക്കുക. റൂട്ടർ പിയറിനെ നിലച്ചതായി റിപ്പോർട്ട് ചെയ്യുകയും നിങ്ങളുടെ ഉപകരണത്തിൽ അയൽക്കാരൻ ഇല്ലാതിരിക്കുകയും ചെയ്താൽ, ജോടി തെറ്റാണ് അല്ലെങ്കിൽ BGP പോർട്ട് ഫിൽട്ടർ ചെയ്യപ്പെടുന്നു. പിയറിന്റെ ടണൽ ഇന്റർഫേസിൽ പാക്കറ്റ് ക്യാപ്ചർ ചെയ്യുന്നത് ഒറ്റനോട്ടത്തിൽ അത് തീർപ്പാക്കുന്നു, കാരണം OPEN പാക്കറ്റുകൾ അവിടെ എത്തുകയോ ഒരിക്കലും എത്താതിരിക്കുകയോ ചെയ്യുന്നു.
gcloud compute routers get-status ROUTER --region=REGION പിയർ അവസ്ഥ അത് ഉപയോഗിക്കുന്ന വിലാസത്തിന് സമീപം അച്ചടിക്കുന്നു, താരതമ്യം ചെയ്യേണ്ട ജോടി അതു തന്നെയാണ്.
സെഷൻ സ്ഥാപിതമായാൽ, പഠിച്ച പ്രിഫിക്സ് VPC റൂട്ട് പട്ടികയിൽ പ്രത്യക്ഷപ്പെടുന്നുവെന്നും ഇരു വശത്തും ഓരോ ഹോസ്റ്റ് മറുപടി നൽകുന്നുവെന്നും ഉറപ്പാക്കുക. തുടർന്ന് അന്തിമ ജോടികൾ ടണൽ പേരുകൾക്ക് സമീപം രേഖപ്പെടുത്തുക, അടുത്ത പുനർനിർമ്മാണം കൺസോൾ സംഗ്രഹത്തിൽ നിന്നല്ല, പരിശോധിച്ച പട്ടികയിൽ നിന്ന് ആരംഭിക്കാൻ.