അപ്‌സ്ട്രീം VPN-ന് പിന്നിലെ ഡൗൺസ്ട്രീം ക്ലയന്റുകൾ: റൂട്ടോ NAT-ഓ?

ഒരു ഗേറ്റ്‌വേ നിങ്ങളുടെ സ്വന്തം ഉപകരണങ്ങൾക്കായി WireGuard-ഉം മറ്റൊരാളുടെ നെറ്റ്‌വർക്കിലേക്ക് OpenVPN ക്ലയന്റും പ്രവർത്തിപ്പിക്കുന്നു. രണ്ട് ആന്തരിക ഇന്റർഫേസുകൾ തമ്മിലുള്ള ഫോർവേഡിംഗ് പ്രവർത്തിക്കുന്നു, ഡൗൺസ്‌ട്രീം സബ്‌നെറ്റ് ഇപ്പോൾ അപ്‌സ്‌ട്രീം സേവനത്തിന്റെ ഭാഗമാണെന്ന് അനുമാനിക്കാൻ എളുപ്പമാണ്. അങ്ങനെയല്ല. ക്ലയന്റ് വലിച്ചെടുക്കുന്ന റൂട്ട് അഭ്യർത്ഥനകൾ എവിടെ അയയ്ക്കണമെന്ന് ഗേറ്റ്‌വേയോട് പറയുന്നു; ഒരിക്കലും കേട്ടിട്ടില്ലാത്ത ഉപകരണങ്ങളിലേക്ക് ദൂര നെറ്റ്‌വർക്ക് ട്രാഫിക് എങ്ങനെ തിരികെ അയയ്ക്കുന്നു എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല. ഒരു നിയമം ചേർക്കുന്നതിന് മുൻപ് അപ്‌സ്‌ട്രീം യഥാർത്ഥത്തിൽ പിന്തുണയ്ക്കുന്ന ഒരു റിട്ടേൺ മാതൃക തിരഞ്ഞെടുക്കുക.

റൂട്ടിംഗ് തൊടുന്നതിന് മുൻപ് റിട്ടേൺ മാതൃക തീരുമാനിക്കുക

ഈ വിശദീകരണത്തിൽ ഡൗൺസ്‌ട്രീം ക്ലയന്റുകൾ 10.90.0.0/24 ഉപയോഗിക്കുന്നു, ഗേറ്റ്‌വേയ്ക്ക് നൽകിയ അപ്‌സ്‌ട്രീം ടണൽ വിലാസം 10.80.0.6 ആണ്, അനുവദിച്ച ദൂര വിഭവം 172.20.0.30 ആണ്. ഈ രൂപത്തിന് രണ്ട് മാതൃകകൾ യോജിക്കുന്നു: ഡൗൺസ്‌ട്രീം ഉറവിടം നിലനിർത്തി ദൂരവശത്തെ അത് റൂട്ട് ചെയ്യിക്കുക, അല്ലെങ്കിൽ ഉറവിടം ഗേറ്റ്‌വേയുടെ സ്വന്തം ടണൽ വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യുക. ഈ തീരുമാനത്തിന് ശേഷമുള്ളതെല്ലാം യാന്ത്രികമാണ്, തീരുമാനത്തിന് തന്നെ സേവനത്തിന്റെ ഉടമയെ വേണം. മുകളിലെ ഒരു വരി ദൂരവശവുമായുള്ള റൂട്ടിംഗ് കരാറാണ്; മറ്റൊന്ന് നിങ്ങൾക്ക് ഒറ്റയ്ക്ക് ചെയ്യാവുന്ന പ്രാദേശിക നയമാറ്റമാണ്. ഇവ രണ്ടും കൂട്ടിക്കലർത്തുന്നതാണ് പത്ത് മിനിറ്റ് നീളുന്ന മാറ്റത്തെ ചർച്ചയാക്കി മാറ്റുന്നത്.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

ഒരു വരി തിരഞ്ഞെടുത്ത് അതിൽ ഉറച്ചുനിൽക്കുക. വരികൾ ഘട്ടങ്ങളല്ല, ബദലുകളാണ്, അവ കൂട്ടിക്കലർത്തിയാൽ അവലോകനത്തിൽ ആർക്കും വിശദീകരിക്കാനാകാത്ത രൂപകൽപ്പന വരും.

റൂട്ട് ചെയ്ത ഉറവിട സംരക്ഷണം

ദൂരവശം ഡൗൺസ്‌ട്രീം വിലാസത്തിൽ നിന്ന് അഭ്യർത്ഥന സ്വീകരിക്കുന്നു, അതിനാൽ ആ സബ്‌നെറ്റിന് പിന്തുണയുള്ള റൂട്ടും പിയർ ഉടമസ്ഥതയും, അത് സ്വീകരിക്കാനുള്ള അധികാരവും വേണം. ഇവ ദൂര ക്രമീകരണങ്ങളാണ്, പ്രാദേശിക Linux റൂട്ടുകളൊന്നും അവ സൃഷ്ടിക്കുന്നില്ല. പ്രിഫിക്സും അത് വഹിക്കുന്ന ടണൽ പിയറും സഹിതം അവ വ്യക്തമായി രേഖാമൂലം ആവശ്യപ്പെടുക, സേവനം സൈറ്റ്-ടു-സൈറ്റ് ക്രമീകരണങ്ങൾ പിന്തുണയ്ക്കുന്നുണ്ടോ എന്നതിനെ ആശ്രയിച്ചിരിക്കും ഉത്തരം എന്ന് പ്രതീക്ഷിക്കുക.

ഉത്തരം അതെയെങ്കിൽ പ്രാദേശിക കോൺഫിഗറേഷൻ ചെറുതാണ്: ഫോർവേഡിംഗ് സജീവം, ഡൗൺസ്‌ട്രീം ശ്രേണി ഉൾക്കൊള്ളുന്ന WireGuard പിയറിന്റെ allowed-ips, ഇരുവശങ്ങളിലേക്കും കടക്കാൻ അനുവദിക്കുന്ന ഫയർവാൾ നയം.

ബോധപൂർവമായ ഉറവിട വിവർത്തനം

സേവനം ട്രാഫിക് ബന്ധിപ്പിച്ച ക്ലയന്റ് വിലാസത്തിലേക്ക് മാത്രം തിരികെ അയയ്ക്കുന്നുവെങ്കിൽ, പുറത്തേക്ക് പോകുമ്പോൾ ഉറവിടം ആ വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യുക, ഉത്തരങ്ങൾക്കായി അത് തിരിച്ചിടുന്ന conntrack അവസ്ഥ സൂക്ഷിക്കുക. നിയമം ഉദ്ദേശിച്ച ഡൗൺസ്‌ട്രീം ഉറവിടങ്ങളിലേക്കും ഉദ്ദേശിച്ച ദൂര ലക്ഷ്യങ്ങളിലേക്കും അപ്‌സ്‌ട്രീം ഇന്റർഫേസിലേക്കും പരിമിതപ്പെടുത്തുക. ഓരോ ഇന്റർഫേസിൽ നിന്നും പുറത്തുപോകുന്ന എല്ലാം വിവർത്തനം ചെയ്യുന്ന നിയമം ഈ ആവശ്യകതയേക്കാൾ വളരെ വലിയ നയമാണ്, അത് പിന്നീട് നിങ്ങളെ അത്ഭുതപ്പെടുത്തും.

IPv6-ന് സ്വന്തം രൂപകൽപ്പന വേണം; IPv4 masquerade വരി പകർത്തുന്നത് വാസ്തുവിദ്യയല്ല. വിവർത്തനം ചെയ്ത പാത കാഷ് ചെയ്ത കണക്ഷനല്ല, പുതിയ കണക്ഷൻ ഉപയോഗിച്ച് പരീക്ഷിക്കുക.

പ്രാദേശിക ഡാറ്റാ പാത ഇപ്പോഴും പ്രവർത്തിക്കണം

വിവർത്തനം പ്രാദേശിക ജോലി ഒഴിവാക്കുന്നില്ല: ഗേറ്റ്‌വേയ്ക്ക് ഇപ്പോഴും ഡൗൺസ്‌ട്രീം ലക്ഷ്യങ്ങളിലേക്ക് റൂട്ട്, ശരിയായ WireGuard പിയർ ഉറവിട ഉടമസ്ഥത, സജീവ ഫോർവേഡിംഗ്, ഇന്റർഫേസുകൾക്കിടയിൽ ഇടുങ്ങിയ ഫയർവാൾ നയം എന്നിവ വേണം. ഗേറ്റ്‌വേയിൽ തന്നെ സൃഷ്ടിക്കുന്ന അഭ്യർത്ഥന ഈ അനുമതികളൊന്നും പരീക്ഷിക്കുന്നില്ല, അതുകൊണ്ടാണ് ഗേറ്റ്‌വേയിലെ പ്രാദേശിക പരിശോധനകൾ വിജയിക്കുകയും ഡൗൺസ്‌ട്രീം ഉപകരണങ്ങൾ പരാജയപ്പെടുകയും ചെയ്യുന്നത്.

ഗേറ്റ്‌വേയിൽ നിന്നല്ല, യഥാർത്ഥ ഡൗൺസ്‌ട്രീം ഉപകരണത്തിൽ നിന്ന് പരീക്ഷിക്കുക. ഉറവിട വിലാസമാണ് ഈ അഭ്യാസത്തിന്റെ മുഴുവൻ ഉദ്ദേശ്യം.

ഒരു ഉറവിടം എന്നാൽ ഒരു സെഷൻ ഐഡന്റിറ്റി

ദൂര സേവനം ഓരോ ഡൗൺസ്‌ട്രീം ഉപകരണത്തിനും സ്വതന്ത്ര പ്രാമാണീകരണമല്ല, ഗേറ്റ്‌വേയുടെ പ്രാമാണീകരിച്ച സെഷനും അതിന്റെ വിവർത്തനം ചെയ്ത വിലാസവുമാണ് കാണുന്നത്. ഉപകരണം തോറുമുള്ള അനുമതികളും ആപ്ലിക്കേഷൻ ഐഡന്റിറ്റികളും വ്യക്തമായി സൂക്ഷിക്കുക, ഒന്നിലധികം ഉപകരണങ്ങൾക്കുവേണ്ടി പ്രവർത്തിക്കുന്ന ഗേറ്റ്‌വേയ്ക്ക് അനുമതിയുണ്ടോ എന്ന് സേവന ഉടമയുമായി സ്ഥിരീകരിക്കുക. വിവർത്തനം ഉപകരണം തോറുമുള്ള രജിസ്ട്രേഷൻ ആവശ്യകത ഒഴിവാക്കാനുള്ള വഴിയല്ല; സേവനം ഓരോ ഉപകരണത്തിന്റെയും രജിസ്ട്രേഷൻ ആവശ്യപ്പെടുന്നുവെങ്കിൽ, ആ മാതൃക ഉപയോഗിക്കുക അല്ലെങ്കിൽ സൈറ്റ്-ടു-സൈറ്റ് ക്രമീകരണത്തിനായി ചർച്ച നടത്തുക.

ആ സ്ഥിരീകരണം നിയമത്തിന് അടുത്ത് runbook-ൽ എഴുതുക, കാരണം അടുത്ത അവലോകകൻ രൂപകൽപ്പന അംഗീകരിക്കപ്പെട്ടതാണോ അതോ സൗകര്യപ്രദമായിരുന്നുവോ എന്ന് ചോദിക്കും.

വിച്ഛേദിച്ച അവസ്ഥ നിർവചിച്ച്, പിന്നീട് മൂന്ന് അഭ്യർത്ഥനകൾ പരീക്ഷിക്കുക

അപ്‌സ്‌ട്രീം ടണൽ വീഴുമ്പോൾ എന്ത് സംഭവിക്കണം എന്ന് തീരുമാനിക്കുക. അനുവദിച്ച ദൂര ട്രാഫിക് നിരോധിതമായിടത്ത് സാധാരണ WAN ഫാൾബാക്കിനെ നിശ്ശബ്ദമായി പിന്തുടരരുത്, അതിനാൽ കടക്കാൻ അനുവദിക്കുന്ന ഫയർവാൾ നയവും അടഞ്ഞ അവസ്ഥയിൽ പരാജയപ്പെടണം. തുടർന്ന് യഥാർത്ഥ ഡൗൺസ്‌ട്രീം ഉപകരണത്തിൽ നിന്ന് മൂന്ന് സന്ദർഭങ്ങൾ പരീക്ഷിക്കുക: പ്രവർത്തിക്കുന്ന അനുവദിച്ച അഭ്യർത്ഥന, പരാജയപ്പെടുന്ന നിരോധിത അഭ്യർത്ഥന, അനുവദിച്ചതിനെ നിർത്തുന്ന അപ്‌സ്‌ട്രീം പരാജയം.

ഓരോ നിയമത്തിനും ഒരു വരിയിൽ റോൾബാക്ക് രേഖപ്പെടുത്തുക, ഉദ്ദേശ്യം വീണ്ടും നിർമ്മിക്കാതെ മാറ്റം റദ്ദാക്കാൻ കഴിയണം.