OpenVPN ക്ലയന്റുകൾ ഗേറ്റ്വേയുടെ IPsec സെലക്ടറുകൾ എന്തുകൊണ്ട് നഷ്ടപ്പെടുത്തുന്നു

ഗേറ്റ്വേയിൽ നിന്ന് വിദൂര IPsec ടണലിന് പിന്നിലുള്ള ഹോസ്റ്റിലേക്ക് ping അയയ്ക്കുമ്പോൾ അത് വൃത്തിയായി മറുപടി നൽകുന്നു, അതിനാൽ ടണൽ ആരോഗ്യകരമായി തോന്നുന്നു, ടിക്കറ്റ് മുന്നോട്ട് പോകുന്നു. പിന്നീട് കണക്ട് ചെയ്ത ക്ലയന്റ് അതേ ഹോസ്റ്റ് പരീക്ഷിക്കുന്നു, ഒന്നും തിരികെ കിട്ടുന്നില്ല. ആ ping ഒരിക്കലും ക്ലയന്റിന്റെ ഫ്ലോയുടെ തെളിവായിരുന്നില്ല, കാരണം അത് ഗേറ്റ്വേയുടെ സ്വന്തം സോഴ്സ് വിലാസവുമായി പുറത്തുപോയി മറ്റൊരു IPsec സെലക്ടറുമായി പൊരുത്തപ്പെട്ടു. ഈ രണ്ട് സന്ദർഭങ്ങൾ എന്തുകൊണ്ട് വ്യത്യാസപ്പെടുന്നു എന്ന് മനസ്സിലാക്കുന്നതാണ് പരിഹാരത്തിന്റെ വലിയ ഭാഗം.

ഗേറ്റ്വേയുടെ ping നിങ്ങളുടെ ക്ലയന്റ് ഒരിക്കലും ഉപയോഗിക്കാത്ത ഫ്ലോ പരിശോധിക്കുന്നു

ഏത് നയമാണ് ബാധകമാകുന്നത് എന്ന് തീരുമാനിക്കുന്നത് സോഴ്സ് വിലാസമാണ്. ഗേറ്റ്വേയിൽ സൃഷ്ടിക്കുന്ന പാക്കറ്റ് അതിന്റെ പ്രാദേശിക LAN അല്ലെങ്കിൽ ടണലിന്റെ അന്ത്യബിന്ദുവിന്റെ വിലാസവുമായി പുറപ്പെടുന്നു, അതിനോട് പൊരുത്തപ്പെടുന്ന നയം കൃത്യമായി ആ സന്ദർഭത്തിനായി എഴുതിയതാണ്. ക്ലയന്റിന്റെ പാക്കറ്റ് ക്ലയന്റ് പൂളിലെ വിലാസവുമായി OpenVPN ഇന്റർഫേസിൽ എത്തുന്നു, അത് തികച്ചും വ്യത്യസ്തമായ ഒരു സെലക്ടറാണ്.

അതുകൊണ്ടാണ് പരാജയം റൂട്ടിംഗ് പ്രശ്നമായി തോന്നുന്നത്, യഥാർത്ഥത്തിൽ അത് നയത്തിന്റെ പരിധിയുടെ പ്രശ്നമാണ്. ഗേറ്റ്വേയിൽ നിന്നുള്ള എത്തിച്ചേരൽ പീർ സജീവമാണെന്നും നിർദ്ദേശങ്ങൾ ചർച്ച ചെയ്തുവെന്നും തെളിയിക്കുന്നു, പൂൾ സംരക്ഷിതമാണോ എന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

ആപ്ലിക്കേഷന് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള വിദൂര പ്രിഫിക്സ് പുഷ് ചെയ്യുക

കണക്ട് ചെയ്ത ക്ലയന്റുകൾക്കായി 10.8.0.0/24, സംരക്ഷിത വിദൂര നെറ്റ്വർക്കിനായി 172.30.239.0/25 എന്ന ഉദാഹരണ ജോടി എടുക്കുക. ക്ലയന്റിന് ആവശ്യമുള്ളത് രണ്ടാമത്തെ പ്രിഫിക്സിലേക്കുള്ള റൂട്ടാണ്, ഗേറ്റ്വേയുടെ LAN അല്ല, മറ്റൊരു ടണൽ വിലാസവുമല്ല. പൂളിലേക്ക് പുഷ് ചെയ്യുന്ന റൂട്ടാണ് ക്ലയന്റിനെ ആ ട്രാഫിക് ഗേറ്റ്വേയ്ക്ക് കൈമാറാൻ പ്രേരിപ്പിക്കുന്നത്. അതില്ലാതെ പാക്കറ്റ് നിങ്ങൾ ഡീബഗ് ചെയ്യുന്ന നയ തീരുമാനത്തിൽ എത്തുന്നില്ല.

പുഷ് ചെയ്ത റൂട്ടുകൾ സ്വീകരിക്കുന്ന Community സെർവറിൽ നിർദ്ദേശം യഥാർത്ഥ മാസ്ക് എടുക്കുന്നു: push "route 172.30.239.0 255.255.255.128". Access Server അതേ ലക്ഷ്യസ്ഥാനം ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിന്റെ സ്വകാര്യ-നെറ്റ്വർക്ക് അല്ലെങ്കിൽ ആക്സസ്-റൂൾ ക്രമീകരണങ്ങളിലൂടെ കോൺഫിഗർ ചെയ്യുന്നു, റൂട്ടഡ് അല്ലെങ്കിൽ ട്രാൻസ്ലേറ്റഡ് മോഡ് ബോധപൂർവ്വം തിരഞ്ഞെടുക്കുന്നു. ഉടമയുടെ കോൺഫിഗറേഷനു പകരം ജനറേറ്റ് ചെയ്ത ഫയർവാൾ ചെയിനുകൾ എഡിറ്റ് ചെയ്യുന്നതാണ് പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റാളേഷൻ പുനർനിർമ്മിക്കാൻ അസാധ്യമാക്കുന്ന വഴി.

കണക്ട് ചെയ്ത ശേഷം സെർവറിന്റെ ഉദ്ദേശ്യമല്ല, ക്ലയന്റിന്റെ റൂട്ടിംഗ് ടേബിൾ വായിക്കുക. പൂൾ മാത്രം ഉൾക്കൊള്ളുന്ന റൂട്ട് എന്നാൽ പുഷ് ഒരിക്കലും എത്തിയില്ല എന്നാണ്, ടണലിലൂടെയുള്ള ഡിഫോൾട്ട് റൂട്ട് ഈ ആവശ്യകതയേക്കാൾ വിശാലമാണ്, പിന്നീട് നിങ്ങളെ അത്ഭുതപ്പെടുത്തും. മാസ്കും പ്രിഫിക്സും പരിശോധിക്കുക, കാരണം /25 നെ /24 ആയി പുഷ് ചെയ്യുമ്പോൾ അയൽ വിലാസങ്ങളുടെ ട്രാഫിക് അത് വഹിക്കാൻ കഴിയാത്ത വഴിയിലേക്ക് പോകുന്നു. തുടർന്ന് ക്ലയന്റ് ആ ലക്ഷ്യത്തിനായി ടണൽ ഇന്റർഫേസ് തിരഞ്ഞെടുത്തുവെന്ന് ഉറപ്പാക്കുക.

സെലക്ടറുകൾ ക്ലയന്റ് പൂൾ ഉൾക്കൊള്ളുന്നതാക്കുക

ക്ലയന്റ് വിലാസങ്ങൾ നിലനിർത്തുന്ന റൂട്ടഡ് ആക്സസിന്, IPsec നയം പൂളും വിദൂര പ്രിഫിക്സും തമ്മിലുള്ള ട്രാഫിക് സംരക്ഷിക്കണം. ഗേറ്റ്വേയുടെ സ്വന്തം LAN-നായി എഴുതിയ സെലക്ടറുകൾ ping അനുവദിച്ച് ക്ലയന്റിന്റെ അഭ്യർത്ഥന വലിച്ചെറിയുന്നു, ഈ അന്വേഷണം തുടങ്ങിയ അസമമിതി അതാണ്.

കോൺഫിഗർ ചെയ്ത നിർദ്ദേശങ്ങൾക്കൊപ്പം ചർച്ച ചെയ്ത നയവും പരിശോധിക്കുക, ഉദാഹരണത്തിന് strongSwan-ൽ ipsec statusall അല്ലെങ്കിൽ നിങ്ങളുടെ നടപ്പാക്കലിനുള്ള തത്തുല്യമായ സ്റ്റാറ്റസ് കമാൻഡ്. നയാധിഷ്ഠിത IPsec-ൽ സാധാരണ റൂട്ട് ഒരു ഭൗതിക ഇന്റർഫേസിലേക്ക് ചൂണ്ടാം, പൊരുത്തപ്പെടുന്ന ട്രാഫിക് ഇപ്പോഴും എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു, അതിനാൽ ടണൽ ഉപകരണം ഇല്ലാത്തത് ഒന്നും തെളിയിക്കുന്നില്ല. സെലക്ടർ ജോടികൾ നിങ്ങൾ എഴുതിയ പൂളും പ്രിഫിക്സുമായി താരതമ്യം ചെയ്യുക.

ഗേറ്റ്വേയിലെ പൊതു സോഴ്സ് NAT-ഉം പൊരുത്തം തകർക്കാം. നയ പരിശോധനയ്ക്ക് മുമ്പ് masquerade നിയമം ക്ലയന്റിന്റെ സോഴ്സ് മാറ്റിയെഴുതുന്നുവെങ്കിൽ, പാക്കറ്റ് ഇനി നിങ്ങൾ എഴുതിയ സെലക്ടറിനെപ്പോലെ തോന്നില്ല. വിശാലമായ masquerade നിയമം രണ്ടാമത്തെ VPN-ന് മോശം പരിഹാരമാകുന്നതിന്റെ ഒരു കാരണം ഇതാണ്: ഏത് നയം ബാധകമാകുമെന്നും വിദൂര വശം ഏത് വിലാസം രേഖപ്പെടുത്തുമെന്നും അത് മാറ്റുന്നു. നിങ്ങൾ റൂട്ട് ചെയ്യാൻ ഉദ്ദേശിക്കുന്ന ട്രാഫിക് ഒഴിവാക്കുക, അല്ലെങ്കിൽ ബോധപൂർവ്വം അത് വിവർത്തനം ചെയ്ത് സെലക്ടറുകൾ പുതുക്കുക.

റൂട്ടിംഗോ വിവർത്തനമോ ബോധപൂർവ്വം തിരഞ്ഞെടുക്കുക

റൂട്ടിംഗ് ക്ലയന്റ് വിലാസം വിദൂര വശത്തിന് ദൃശ്യമായി നിർത്തുന്നു, അതിനാൽ വിദൂര ലോഗുകളും ഓരോ സോഴ്സിനുമുള്ള നിയമങ്ങളും അർത്ഥവത്തായി തുടരുന്നു, വിദൂര ഗേറ്റ്വേ പൂളിലേക്കുള്ള മടങ്ങിവരവ് പാത അറിയണമെന്ന് അത് ആവശ്യപ്പെടുന്നു. വിവർത്തനം പൂളിനെ ഒരു വിലാസത്തിന് പിന്നിൽ ഒളിപ്പിക്കുന്നു, അത് മടങ്ങിവരവ് റൂട്ട് പ്രശ്നം ഒഴിവാക്കി ഓരോ ക്ലയന്റിന്റെയും ഐഡന്റിറ്റി നശിപ്പിക്കുന്നു.

ഒരു ഡിസൈൻ തിരഞ്ഞെടുത്ത് എഴുതിവയ്ക്കുക, കാരണം രണ്ടിനും വ്യത്യസ്ത സെലക്ടറുകളും വ്യത്യസ്ത ഫയർവാൾ ക്രമവും വേണം. പകുതി പ്രയോഗിച്ച masquerade അവയ്ക്കിടയിൽ വീഴുന്നു, ഒന്നിനെയും തൃപ്തിപ്പെടുത്തുന്നില്ല. എഴുതിയ തിരഞ്ഞെടുപ്പാണ് അടുത്ത എഞ്ചിനീയർക്ക് ബഗ്ഗും ബോധപൂർവമായ തീരുമാനവും തമ്മിൽ വേർതിരിക്കാൻ അവസരം നൽകുന്നത്.

ഫോർവേഡിംഗിലും മറുപടിയിലും ലൂപ്പ് അടയ്ക്കുക

ഗേറ്റ്വേ നിങ്ങൾ ഉദ്ദേശിക്കുന്ന പ്രോട്ടോക്കോളും ലക്ഷ്യവും ഫോർവേഡ് ചെയ്യണം, അതായത് IP ഫോർവേഡിംഗ് സജീവമായിരിക്കണം, ജോടിയെ അനുവദിക്കുന്ന ഫോർവേഡ് ചെയിൻ ഉണ്ടാകണം. തുടർന്ന് വിദൂര വശം IPsec പാതയിലൂടെ മറുപടികൾ തിരികെ അയയ്ക്കണം, അത് അവരുടെ ഗേറ്റ്വേയിലെ റൂട്ടിംഗ് തീരുമാനമാണ്, നിങ്ങളുടേതല്ല. രണ്ട് പകുതികളും സാധാരണ കോൺഫിഗറേഷനാണ്, രണ്ടും പകുതി വിട്ടേക്കാൻ എളുപ്പമാണ്. വേർതിരിച്ച് പരീക്ഷിക്കുക, കാണാത്ത ഫോർവേഡ് നിയമത്തെ തകർന്ന ടണലായി തെറ്റിദ്ധരിക്കാതിരിക്കാൻ.

ക്ലയന്റിൽ നിന്ന് ആപ്ലിക്കേഷനിലേക്കുള്ള ഒരു യഥാർത്ഥ അഭ്യർത്ഥന കൊണ്ട് പരിശോധിക്കുക, അത് OpenVPN ഇന്റർഫേസ്, IPsec തീരുമാനം, വിദൂര ഹോസ്റ്റ് എന്നിവ കടന്നുപോകുന്നത് നിരീക്ഷിക്കുക. മറുപടി പ്രത്യേക നിരീക്ഷണമായി പരിശോധിക്കുക, കാരണം എത്തുന്ന അഭ്യർത്ഥനയും ഒരിക്കലും തിരികെ വരാത്ത മറുപടിയും ക്ലയന്റിന്റെ സ്ഥാനത്തുനിന്ന് ഒരുപോലെ തോന്നുന്നു. ട്രേസ് ചെയ്ത ഒരു അഭ്യർത്ഥന എത്ര ഗേറ്റ്വേ ping-നേക്കാളും വിലപ്പെട്ടതാണ്.

പരീക്ഷിക്കുമ്പോൾ ലക്ഷ്യത്തിന്റെ അധികാരം ഇടുങ്ങിയതായി സൂക്ഷിക്കുക, നിയമമില്ലാത്ത ക്ലയന്റിന് സേവനത്തിൽ എത്താൻ കഴിയില്ലെന്ന് ഉറപ്പാക്കുക. ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടും സ്ഥാപിതമായ അസോസിയേഷനും നൽകിയ ആക്സസിന് തുല്യമല്ല.