OpenVPN ക്ലയന്റുകളെ Cloudflare വഴി റൂട്ട് ചെയ്യണോ? ആദ്യം റോൾ പരിശോധിക്കുക
ഒരു ഉപകരണ ക്ലയന്റ് റൗട്ടർ അല്ല. Cloudflare റോൾ മറ്റ് ഹോസ്റ്റുകളുടെ പാക്കറ്റുകൾ കൈമാറുന്നുവെന്ന് ഉറപ്പാക്കി, സെർവറിന്റെ സ്വന്തം ടണൽ അതിന്റെ പഴയ വഴിയിൽ തന്നെ നിർത്തുക.
നിങ്ങൾക്ക് പ്രവർത്തിക്കുന്ന ഒരു OpenVPN സെർവറും Cloudflare-ന്റെ ഉപകരണ സോഫ്റ്റ്വെയർ കൂടി പ്രവർത്തിപ്പിക്കുന്ന ഒരു ഹോസ്റ്റും ഉണ്ട്, അടുത്ത വ്യക്തമായ ഘട്ടം ക്ലയന്റ് ട്രാഫിക് അങ്ങോട്ട് അയയ്ക്കുന്നതാണെന്ന് തോന്നുന്നു. ഒരു മെഷീനിൽ രണ്ട് പ്രവർത്തിക്കുന്ന കണക്ഷനുകൾ ചേർന്ന് ഒരു ട്രാൻസിറ്റ് ഗേറ്റ്‌വേ ആകുന്നില്ല. ഇല്ലാത്തത് മറ്റൊരാൾക്കുള്ള പാക്കറ്റുകൾ കൈമാറാൻ രേഖപ്പെടുത്തിയ ഒരു റോളും, ആ പാക്കറ്റുകൾ എത്തുമ്പോൾ അവയെ തരംതിരിക്കുന്ന ഒരു നയവുമാണ്.
ഏതു നിയമത്തിനും മുമ്പ് നാല് ചോദ്യങ്ങളുണ്ട്: ഏത് ട്രാഫിക് അകത്തേക്ക് വരുന്നു, അത് പിന്നെ എങ്ങോട്ട് പോകുന്നു, മറുപടികൾ തിരികെയുള്ള വഴി എങ്ങനെ കണ്ടെത്തുന്നു, ആ രണ്ടാം വഴി പരാജയപ്പെടുമ്പോൾ ഡിസൈൻ എന്ത് ചെയ്യുന്നു. ആദ്യ രണ്ടും കഴിവിന്റെ ചോദ്യങ്ങളാണ്.
ഒരു ഹോസ്റ്റിലെ രണ്ട് സേവനങ്ങൾ ട്രാൻസിറ്റ് വഴിയല്ല
ഉപകരണ ക്ലയന്റ് പ്രവർത്തിക്കുന്ന മെഷീനിൽ ഉത്ഭവിക്കുന്ന ട്രാഫിക് കൈകാര്യം ചെയ്യാൻ നിർമ്മിച്ചതാണ്. അത് പേര് നിർണ്ണയം അല്ലെങ്കിൽ തിരഞ്ഞെടുത്ത ആപ്ലിക്കേഷൻ ട്രാഫിക് തടഞ്ഞ് സ്വന്തം ടണൽ വഴി അയയ്ക്കുന്നു, അതിന്റെ നയം ആ ഉപകരണത്തിന്റെ ഉപയോക്താവിനും ആ ഉപകരണത്തിന്റെ പ്രക്രിയകൾക്കും വേണ്ടി എഴുതിയതാണ്. OpenVPN ക്ലയന്റിൽ നിന്ന് കൈമാറുന്ന പാക്കറ്റ് പ്രാദേശിക ഔട്ട്പുട്ട് അല്ല, അതിനാൽ അതേ നിയമങ്ങൾ അതിനെ തരംതിരിക്കുന്നില്ല. ഇത് വിശാലമായ നിയമം കൊണ്ട് മറയ്ക്കാവുന്ന ഒരു കോൺഫിഗറേഷൻ വിശദാംശമല്ല, കാരണം സോഫ്റ്റ്വെയർ പാക്കറ്റ് ഒട്ടും കാണുന്നുണ്ടോ എന്ന് ഇത് തീരുമാനിക്കുന്നു.
അതുകൊണ്ടാണ് ഡിസൈൻ ചോദ്യം കഴിവിന്റെ ചോദ്യമാകുന്നത്. ഒന്നുകിൽ ഇൻസ്റ്റാൾ ചെയ്ത ഉൽപ്പന്നത്തിന് മറ്റ് നെറ്റ്വർക്കുകൾക്കുള്ള ട്രാഫിക് കൈമാറുന്ന രേഖപ്പെടുത്തിയ റോളുണ്ട്, അല്ലെങ്കിൽ ട്രാൻസിറ്റ് ഫംഗ്ഷൻ തികച്ചും മറ്റൊരു സ്ഥലത്തിനുള്ളതാണ്.
Cloudflare-ന്റെ ഏത് റോളിനാണ് കൈമാറാൻ അനുമതി
Cloudflare-ന്റെ ഉപകരണ ക്ലയന്റ് പരിധിയിൽ വ്യത്യസ്തമായ മോഡുകൾ നൽകുന്നു: പേര് നിർണ്ണയം മാത്രം, ഉപകരണത്തിൽ നിന്നുള്ള ട്രാഫിക്, ചിലപ്പോൾ രണ്ടും. ആ മോഡുകളിൽ ഒന്നും മറ്റൊരു ടണൽ വഴി എത്തുന്ന സ്വകാര്യ ശ്രേണിക്ക് ഹോസ്റ്റിനെ റൗട്ടറാക്കുന്നില്ല. സമർപ്പിത റൂട്ടിംഗ് റോൾ സ്വന്തം കണക്ടർ, രജിസ്ട്രേഷൻ, നെറ്റ്വർക്ക് മോഡൽ എന്നിവയുള്ള വേറിട്ട ഉൽപ്പന്നമാണ്.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
അതിനു ചുറ്റും റൂട്ടുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത റോൾ പരിശോധിക്കുക. കണക്ടർ ഏത് ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നു, അത് നിർദ്ദിഷ്ട പ്രിഫിക്സുകളോ ഡിഫോൾട്ട് റൂട്ടോ പ്രഖ്യാപിക്കുന്നുണ്ടോ, പ്രാദേശിക നയം പ്രാദേശിക പാക്കറ്റുകൾക്കൊപ്പം കൈമാറിയ പാക്കറ്റുകൾക്കും ബാധകമാണോ എന്ന് വായിക്കുക. പ്രാദേശിക ട്രാഫിക് മാത്രം കൈകാര്യം ചെയ്യുന്നുവെങ്കിൽ, വിവർത്തന നിയമം എങ്ങനെ എഴുതിയാലും OpenVPN സെർവറിന് ട്രാൻസിറ്റ് പോയിന്റ് ആകാനാവില്ല.
ഇവിടെയാണ് പൊതു എഗ്രെസ് ആവശ്യകത കൃത്യമായി പറയേണ്ടത്. കൈമാറിയ ക്ലയന്റ് ട്രാഫിക്കിനായി Cloudflare നൽകുന്ന എഗ്രെസ് ഒരു നിർദ്ദിഷ്ട ഉപയോഗ കേസാണ്, അത് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള സേവനത്തിനെതിരെ സ്ഥിരീകരിക്കേണ്ടതുണ്ട്.
പുറം ടണൽ പുതിയ റൂട്ടിൽ നിന്ന് സ്വതന്ത്രമായി നിർത്തുക
പുതിയ ഇന്റർഫേസിലേക്ക് ഡിഫോൾട്ട് റൂട്ട് ചേർക്കുന്ന നിമിഷം സെർവറിന്റെ സ്വന്തം ഔട്ട്ബൗണ്ട് ട്രാഫിക് അതിനായി മത്സരിക്കാൻ തുടങ്ങുന്നു, അതിൽ OpenVPN ക്ലയന്റുകൾക്കുള്ള മറുപടികളും മെഷീനിലേക്കുള്ള നിങ്ങളുടെ SSH സെഷനും ഉൾപ്പെടുന്നു. സാധാരണ ലക്ഷണം സ്ഥാപിക്കപ്പെട്ട് പിന്നീട് മരിക്കുന്ന ഒരു ടണലാണ്, അല്ലെങ്കിൽ മാറ്റം പ്രവർത്തിച്ചതായി തോന്നുമ്പോൾ പുറത്ത് പൂട്ടിയിടുന്ന ഒരു അഡ്മിനിസ്ട്രേറ്റർ. എൻഡ്പോയിന്റിനായി ip route get മുമ്പും ശേഷവും താരതമ്യം ചെയ്യുക, സെർവറിന്റെ സ്വന്തം ഗതാഗതം ഉണ്ടായിരുന്നിടത്ത് നിർത്താൻ പോളിസി അടിസ്ഥാനമാക്കിയ റൂട്ടിംഗ് അല്ലെങ്കിൽ ഹോസ്റ്റ് റൂട്ട് ഉപയോഗിക്കുക. ആ താരതമ്യം യന്ത്രത്തിൽ നിന്നു തന്നെ നടത്തുക, കാരണം സെർവറിന്റെ സ്വന്തം റൂട്ടിനെക്കുറിച്ചുള്ള കാഴ്ചപ്പാടാണ് പ്രധാനം.
സെർവറിന്റെ പൊതു വിലാസത്തിനുള്ള ഒഴിവാക്കൽ മാത്രം പര്യാപ്തമല്ല, കാരണം ഓരോ ദൂരസ്ഥ അഡ്മിനിസ്ട്രേറ്ററുടെയും തിരിച്ചുവരവ് വഴി വേറെ ഒഴുക്കാണ്. ആ ഒഴുക്കുകളിൽ ഏതൊക്കെ മാറ്റത്തെ അതിജീവിക്കണമെന്ന് തീരുമാനിക്കുക, പിന്നെ ആദ്യത്തേത് ബാക്കിയുള്ളവയെ ഉൾക്കൊള്ളുന്നു എന്ന് അനുമാനിക്കുന്നതിന് പകരം ഓരോന്നും പരിശോധിക്കുക.
കൈമാറ്റവും വിവർത്തനവും ഒരു ഒഴുക്കിൽ മാത്രമാക്കുക
സ്വീകരിക്കുന്ന പാക്കറ്റുകൾ പ്രാദേശിക ഔട്ട്പുട്ട് വഴിയല്ല, കൈമാറ്റ വഴിയാണ് പോകുന്നത്, അതിനാൽ പ്രധാന നിയമം forward ഹൂക്കിൽ ജീവിക്കുന്നു. അടുത്ത ഇന്റർഫേസിന് വിവർത്തനം ആവശ്യമുള്ളിടത്ത്, ഉറവിടം ക്ലയന്റ് പൂളിലേക്കും ലക്ഷ്യം അനുവദിച്ചതിലേക്കും എഗ്രെസ് ആ ഒരു ഇന്റർഫേസിലേക്കും പരിമിതപ്പെടുത്തുക. ഇന്റർഫേസുമായി മാത്രം ബന്ധിപ്പിച്ച masquerade നിയമം സ്വയം ഒരു റൂട്ടും തിരഞ്ഞെടുക്കുന്നില്ല, മറ്റേതെങ്കിലും ഫിൽട്ടറിനെ മറികടന്ന് കൈമാറാൻ അനുവദിക്കുന്നുമില്ല.
പരാജയത്തിൽ അടയ്ക്കുന്ന സ്വഭാവം മുൻകൂട്ടി തീരുമാനിച്ച്, പിന്നീട് പരിശോധിക്കുക. അടുത്ത വഴി നിർത്തി, ക്ലയന്റുകൾ സാധാരണ അപ്ലിങ്കിലേക്ക് നിശബ്ദമായി മടങ്ങുന്നതിന് പകരം ഉദ്ദേശിച്ച എഗ്രെസ് നഷ്ടപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം ട്രാഫിക് തെറ്റായ വാതിലിലൂടെ പുറത്തുപോകുന്നതുവരെ ആരും ശ്രദ്ധിക്കാത്ത ഫലം അതാണ്. പേര് നിർണ്ണയത്തിനും IPv6-നും പരിശോധന ആവർത്തിക്കുക, കാരണം v4-ന് മാത്രമുള്ള നിയമക്കൂട്ടം v6 വഴി തുറന്നിടുന്നു.
നിങ്ങൾ എത്തിച്ചേർന്ന നാല് ഉത്തരങ്ങളും ഓരോന്നിനെയും തെളിയിക്കുന്ന നിരീക്ഷണവും എഴുതിവയ്ക്കുക. നിങ്ങൾക്ക് വിവരിക്കാൻ കഴിയുന്ന ട്രാൻസിറ്റ് വഴിയാണ് അടുത്ത സംഭവ അവലോകനത്തിൽ നിങ്ങൾക്ക് പ്രതിരോധിക്കാൻ കഴിയുന്ന വഴി.