peered VPC ലേക്ക് എത്താൻ AWS Client VPN അല്ലെങ്കിൽ bastion
രണ്ട് പാതകളും പ്രവർത്തിക്കുന്നു, പക്ഷേ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പൊട്ടുന്നു. endpoint റൂട്ടുകൾ, റിട്ടേൺ റൂട്ടിംഗ്, bastion സത്യസന്ധമായ അതിർത്തിയാകുന്ന മൂന്ന് സന്ദർഭങ്ങൾ എന്നിവ താരതമ്യം ചെയ്യുക.
ഒരു Client VPN endpoint അതിന്റെ ബന്ധപ്പെട്ട VPC യുമായി peered ആയ VPC ലേക്ക് എത്താം, അത് നിയമാനുസൃതമാക്കാൻ നിങ്ങൾക്ക് bastion ആവശ്യമില്ല. ചെയ്യാൻ യോഗ്യമായ തിരഞ്ഞെടുപ്പ് ട്രാഫിക് എവിടെ കൈ മാറുന്നു എന്നതാണ്: association സബ്നെറ്റിൽ ഇറങ്ങി peering കണക്ഷൻ കടക്കുന്ന endpoint റൂട്ട്, അല്ലെങ്കിൽ peered VPC യിൽ സെഷൻ അവസാനിപ്പിക്കുന്ന host. രണ്ട് പാതകളും പ്രവർത്തിക്കുന്നു, വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പരാജയപ്പെടുന്നു, അതിനാൽ തീരുമാനം ഉടമസ്ഥതയെയും ഓഡിറ്റിനെയും കുറിച്ചാണ്, AWS അനുവദിക്കുന്നതിനെ കുറിച്ചല്ല. അവയ്ക്കിടയിൽ ഞാൻ എങ്ങനെ തിരഞ്ഞെടുക്കുന്നു, routed പാത പ്രവർത്തിപ്പിക്കുന്ന നാല് എൻട്രികളും ഇതാ.
രണ്ട് പാത, ഒരു endpoint, വ്യത്യസ്ത ഉടമകൾ
routed പാതയിൽ ക്ലയന്റ് ട്രാഫിക് endpoint ലേക്ക് എത്തുന്നു, association സബ്നെറ്റിലെ Client VPN നെറ്റ്വർക്ക് ഇന്റർഫേസ് വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യപ്പെടുന്നു, A മുതൽ B വരെയുള്ള peering കണക്ഷനിലൂടെ ആ സബ്നെറ്റ് വിടുന്നു. VPC B ഒരു VPN സെഷനും അവസാനിപ്പിക്കുന്നില്ല; VPC A യിൽ നിന്നുള്ള സാധാരണ ട്രാഫിക് കാണുന്നു, അതുകൊണ്ട് അതിന്റെ റിട്ടേൺ റൂട്ട് ക്ലയന്റ് പൂളിലേക്കല്ല, VPC A യിലേക്ക് ചൂണ്ടുന്നു.
bastion പാതയിൽ ക്ലയന്റ് ആദ്യം host ലേക്ക് എത്തുന്നു. A യിലെ bastion അവസാന ഹോപ്പിനെ ഇപ്പോഴും peering കണക്ഷൻ കടക്കാൻ അനുവദിക്കുന്നു, അതിനാൽ peering ജോലി നിലനിൽക്കുന്നു, ഒരു സെഷൻ കൂടുന്നു. B യിലെ bastion നും ക്ലയന്റിൽ നിന്ന് പാത വേണം, ആ പാത അതേ endpoint റൂട്ട് ആണെങ്കിൽ routed ഡിസൈനിന് ഒരു ഹോപ്പ് കൂടുന്നു. bastion ജോലി കുറയ്ക്കുന്നത് അത് മുൻപേ ഉണ്ടെങ്കിൽ, മുൻപേ അംഗീകരിച്ചിട്ടുണ്ടെങ്കിൽ, അതിന് പിന്നിലെ വസ്തുവിന് നെറ്റ്വർക്ക് അതിർത്തിക്ക് പകരം സെഷൻ അതിർത്തി വേണമെങ്കിൽ മാത്രം.
നാല് എൻട്രികൾ routed പാത പ്രവർത്തിപ്പിക്കുന്നു
AWS ഈ സാഹചര്യം Client VPN how-it-works പേജിൽ രേഖപ്പെടുത്തുന്നു, പ്രായോഗികമായി രണ്ടോ മൂന്നോ ടീമുകളുടെ ഉടമസ്ഥതയിലുള്ള നാല് എൻട്രികളിൽ എത്തുന്നു. ശ്രേണികൾ ഉദാഹരണത്തിനാണ്; peered ശ്രേണി അദ്വിതീയമായിരിക്കണം, റിട്ടേൺ ശ്രേണി നിങ്ങളുടെ പ്ലാനുമായി യോജിക്കണം.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
റൂട്ടും അനുമതിയും വേറിട്ട നിയന്ത്രണങ്ങളാണ്. യോജിക്കുന്ന അംഗീകാര നിയമമില്ലാത്ത ശരിയായ endpoint റൂട്ട് ക്ലയന്റിന് ഒന്നും നൽകുന്നില്ല; endpoint റൂട്ട് ചെയ്യാൻ കഴിയാത്ത ലക്ഷ്യത്തിനുള്ള അംഗീകാര നിയമം അതിന് കറുത്ത കുഴി നൽകുന്നു. രണ്ടും ഒരേ ശ്രേണി പറയണം.
endpoint റൂട്ട് endpoint ന്റെ സ്വന്തം VPC യിലെ സബ്നെറ്റിലേക്ക് ചൂണ്ടുന്നു, ഒരിക്കലും peering കണക്ഷനിലേക്കല്ല. VPC റൂട്ട് ടേബിളുകൾ peering കണക്ഷനിലേക്ക് ചൂണ്ടുന്നു, ഒരിക്കലും instance ലേക്കോ ഇന്റർഫേസിലേക്കോ അല്ല. രണ്ടിനുമിടയിൽ മൂല്യം പകർത്തുന്നത് പരാതിയില്ലാതെ സംഭരിക്കപ്പെടുന്നു, ഒന്നും റൂട്ട് ചെയ്യുന്നില്ല.
association സബ്നെറ്റ് ക്ലയന്റിന്റെ ഉറവിടം വിവർത്തനം ചെയ്യുന്നതിനാൽ, B ക്ലയന്റ് പൂളിലേക്കല്ല, VPC A യിലേക്ക് തിരികെ റൂട്ട് ചെയ്യണം. ക്ലയന്റ് ശ്രേണി peering കണക്ഷനിലൂടെ അയയ്ക്കുന്നത് സമമിതിയായി തോന്നുന്നു, അവലോകനം കടക്കുന്നു, B ക്ലയന്റ് ഉറവിടമുള്ള പാക്കറ്റ് ഒരിക്കലും കാണാത്തതിനാൽ നിശബ്ദമായി പരാജയപ്പെടുന്നു.
സെക്യൂരിറ്റി ഗ്രൂപ്പുകളും അനുമതിയുടെ അവസാന മീറ്ററും
റൂട്ടിംഗ് പാക്കറ്റുകൾ B യിലേക്ക് എത്തിക്കുന്നു; തീരുമാനം B ഇപ്പോഴും എടുക്കുന്നു. ഒരേ പ്രദേശത്തുള്ള സജീവ peering കണക്ഷന്, B യിലെ സെക്യൂരിറ്റി ഗ്രൂപ്പിന് Client VPN association ന് പ്രയോഗിച്ച ഗ്രൂപ്പിനെ റഫർ ചെയ്യാം, ഇത് നിയമം ഇടുങ്ങിയതായി നിലനിർത്തുകയും വിലാസ മാറ്റങ്ങളെ അതിജീവിക്കുകയും ചെയ്യുന്നു. ഗ്രൂപ്പ് റഫറൻസ് സാധ്യമല്ലാത്തിടത്ത്, 0.0.0.0/0 ലേക്ക് വിശാലമാക്കുന്നതിന് പകരം association സബ്നെറ്റ് ശ്രേണി വ്യക്തമായി അനുവദിക്കുക, കാരണം അത് റൂട്ടിംഗ് പിശകിനെ വിശദീകരണമില്ലാത്ത ടൈംഔട്ട് ആക്കി മാറ്റുന്നു.
പിന്നീട് റൂട്ടിംഗ് ഒരിക്കലും തൊടാത്തത് പരിശോധിക്കുക: രണ്ട് സബ്നെറ്റുകളിലെയും നെറ്റ്വർക്ക് ACL, അപ്ലിക്കേഷന്റെ allow-list അല്ലെങ്കിൽ ടോക്കൺ പ്രേക്ഷകർ, DNS. peering സ്വകാര്യ ഹോസ്റ്റഡ് സോണുകൾ പകർത്തുന്നില്ല, അതിനാൽ ലാപ്ടോപ് പരിഹരിക്കാൻ കഴിയാത്ത വിലാസത്തിലേക്ക് പ്രവർത്തിക്കുന്ന റൂട്ട് വെച്ചേക്കാം, peering കണക്ഷൻ സർട്ടിഫിക്കറ്റിന് വിശ്വാസം ചേർക്കുന്നില്ല. endpoint B ക്ക് ഉത്തരം നൽകുന്ന resolver ലേക്ക് ചൂണ്ടി, സ്വകാര്യ നാമവും സർട്ടിഫിക്കറ്റും ഒത്തുപോകുന്നു എന്ന് ഉറപ്പാക്കുക.
bastion സത്യസന്ധമായ ഉത്തരമാകുന്നത്
ബോധപൂർവം bastion തിരഞ്ഞെടുക്കാൻ ഞാൻ മൂന്ന് ട്രിഗറുകൾ സൂക്ഷിക്കുന്നു. peered VPC നിങ്ങളുടെ ശ്രേണിക്ക് റിട്ടേൺ റൂട്ട് ചേർക്കാത്ത അല്ലെങ്കിൽ ഗ്രൂപ്പ് റഫറൻസ് സ്വീകരിക്കാത്ത ടീമിന്റേതാണ്. പ്രവേശനം ഓരോ സെഷനും അംഗീകരിക്കണം അല്ലെങ്കിൽ രേഖപ്പെടുത്തണം, അപ്ലിക്കേഷന് അത് സ്വയം വഹിക്കാൻ കഴിയില്ല. അല്ലെങ്കിൽ അവസാന ഹോപ്പ് B യുടെ ഉള്ളിൽ തന്നെ നിൽക്കണം, കാരണം സേവനം അവിടെ മാത്രമേ പരിഹരിക്കപ്പെടുന്നുള്ളൂ, അതിന്റെ TLS ഐഡന്റിറ്റി ആന്തരിക നാമത്തിൽ പിൻ ചെയ്തിരിക്കുന്നു.
ഇവയൊന്നും peering ട്രാൻസിറ്റീവ് അല്ല എന്ന വസ്തുതയെ ഒഴിവാക്കുന്നതല്ല. അട്രാൻസിറ്റീവിറ്റി B യിലെ വിഭവങ്ങൾക്ക് എന്ത് ചെയ്യാമെന്ന് പരിമിതപ്പെടുത്തുന്നു: A യുമായി peered ആയ മൂന്നാമത്തെ VPC ലേക്ക് A യെ ട്രാൻസിറ്റായി ഉപയോഗിക്കാൻ അവർക്ക് കഴിയില്ല. VPN ഉപയോക്താവിന് നേരിട്ട് peered VPC ലേക്ക് എത്താൻ കഴിയില്ല എന്ന് അത് ഒരിക്കലും അർത്ഥമാക്കിയിട്ടില്ല, ആ തെറ്റായ വായന ഒഴിവാക്കാൻ നിർമ്മിച്ച bastion കാരണമില്ലാതെ പാച്ച് ചെയ്യേണ്ട host ആണ്.
വിപരീത തെറ്റ് കാലക്രമേണ കൂടുതൽ ചെലവാകുന്നു: മുൻപേ ഉള്ള ഒരേയൊരു bastion ലൂടെ എല്ലാ ടീമിനെയും കടത്തിവിടുക, പിന്നീട് അതിന്റെ സെക്യൂരിറ്റി ഗ്രൂപ്പും റൂട്ട് ടേബിളും പാച്ച് വിൻഡോയും ഉത്പാദന ആശ്രിതത്വമാണെന്ന് കണ്ടെത്തുക. host ഏത് ട്രിഗറിന് സേവനം നൽകുന്നു എന്ന് എഴുതിവയ്ക്കുക, ട്രിഗർ പോകുമ്പോൾ അത് വിരമിക്കുക.
Transit Gateway ഉം പല association ഉം കണക്ക് മാറ്റുന്നു
endpoint സബ്നെറ്റിന് പകരം നേരിട്ട് Transit Gateway യിലേക്ക് ബന്ധിപ്പിച്ചിട്ടുണ്ടെങ്കിൽ മാതൃക മാറുന്നു: ക്ലയന്റുകൾ ഇനി association സബ്നെറ്റിലെ ഇന്റർഫേസ് വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യപ്പെടുന്നില്ല, gateway റൂട്ട് ടേബിളുകൾ ക്ലയന്റ് ശ്രേണിയും peered VPC ലേക്ക് നയിക്കുന്ന അറ്റാച്ച്മെന്റും വഹിക്കണം. സ്കെയിലിൽ ഇത് വൃത്തിയാണ്, പക്ഷേ ജോലി നാല് എൻട്രികളിൽ നിന്ന് gateway റൂട്ട് ടേബിളുകളിലേക്ക് നീങ്ങുന്നു.
പല association പരിശോധനകളെ ഗുണിക്കുന്നു. endpoint റൂട്ട് endpoint ന്റേതാണ്, എന്നാൽ ഓരോ association സബ്നെറ്റിനും യഥാർത്ഥ peering അടുത്ത ഹോപ്പുള്ള റൂട്ട് ടേബിൾ വേണം. ഒരു association വഴി സെഷൻ വിജയിച്ചേക്കാം, മറ്റൊന്നിന് റിട്ടേൺ പാത ഇല്ലായിരിക്കാം, അതിനാൽ ഓരോന്നും പരീക്ഷിക്കുക.
തകർച്ച വേഗം കണ്ടെത്തുന്ന പരിശോധനാ ക്രമം
ഇവ ക്രമത്തിൽ പ്രവർത്തിപ്പിക്കുക; ഓരോ ഘട്ടവും അടുത്തത് പരാജയപ്പെടുമ്പോഴും വിജയിച്ചേക്കാം, ക്ലയന്റ് ടൈംഔട്ട് ഏതാണ് പൊട്ടിയതെന്ന് ഏറെക്കുറെ പറയുന്നില്ല.
- ക്ലയന്റിൽ നിന്ന് അപ്ലിക്കേഷന്റെ പേര് പരിഹരിച്ച് വിലാസം peered ശ്രേണിക്കുള്ളിലാണെന്ന് പരിശോധിക്കുക.
- കണക്ട് ചെയ്യുക, പിന്നീട് സെഷൻ അവസാനിപ്പിച്ച association നുള്ള endpoint കണക്ഷൻ ലോഗ് വായിക്കുക.
- ആ association സബ്നെറ്റിൽ, റൂട്ട് ടേബിൾ peered ശ്രേണിയെ സജീവ peering കണക്ഷനിലേക്ക് ചൂണ്ടുന്നു എന്ന് ഉറപ്പാക്കുക.
- B യിലെ റിസോഴ്സ് സബ്നെറ്റിൽ, ഇന്റർഫേസ് ശ്രേണിയുടെ റിട്ടേൺ എൻട്രിയും യോജിക്കുന്ന ഗ്രൂപ്പ് നിയമങ്ങളും ഉറപ്പാക്കുക.
- അനുവദിച്ച ഒരു പ്രവർത്തനവും എത്തിച്ചേരാൻ പാടില്ലാത്ത ഒരു വിഭവവും പരീക്ഷിക്കുക; രണ്ടാമത്തേത് ഡീബഗ്ഗിംഗ് അവശിഷ്ടങ്ങൾ പിടിക്കുന്നു.
- split-tunnel റൂട്ട് മാറ്റത്തിന് ശേഷം വീണ്ടും കണക്ട് ചെയ്യുക, കാരണം പ്രവർത്തിക്കുന്ന ടണൽ പുതിയ റൂട്ട് സെറ്റ് എടുക്കില്ല.
ഓർമ്മിക്കാൻ യോഗ്യമായ രണ്ട് ലക്ഷണങ്ങളുണ്ട്. മറുപടിയില്ലാതെ B യിലേക്ക് എത്തുന്ന SYN മിക്കവാറും എപ്പോഴും നഷ്ടമായ റിട്ടേൺ റൂട്ടാണ്. പൂർത്തിയായി പിന്നീട് റീസെറ്റ് ചെയ്യുന്ന കണക്ഷൻ സാധാരണയായി ഗ്രൂപ്പ്, ACL അല്ലെങ്കിൽ അപ്ലിക്കേഷൻ ആണ്. രണ്ടും endpoint ലോഗിൽ കാരണമായി കാണുന്നില്ല, അതിനാൽ നാല് എൻട്രികളും ഓരോന്നിന്റെയും അടുത്ത് ഉടമയോടെ സൂക്ഷിക്കുക.
മൂന്ന് ട്രിഗറുകളിൽ ഒന്നും ബാധകമല്ലെങ്കിൽ routed പാത പൂർത്തിയാക്കി ആ നാല് എൻട്രികൾ രേഖപ്പെടുത്തുക. ഒന്ന് ബാധകമെങ്കിൽ, bastion ആ അതിർത്തിക്ക് മാത്രം നിലനിർത്തുക, മുൻപിൽ സെഷൻ ആവശ്യമില്ലാത്ത സേവനങ്ങൾക്ക് endpoint റൂട്ട് വിടുക.