Access Server ഗേറ്റ്‌വേ ഉപയോക്താവ്: ക്ലയന്റിന്റെ ശാഖാ LAN റൂട്ടിംഗ്

OpenVPN ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിലേക്ക് ping ചെയ്യാം, പക്ഷേ അതിനു പിന്നിലെ LAN-ൽ ഒരു ഹോസ്റ്റിലും എത്തില്ല. Access Server ക്ലയന്റിന് VPN പൂളിൽ നിന്ന് വിലാസം നൽകുന്നു; പൂൾ വിലാസം മാത്രമാണ് സർവർ തന്റേതായി അറിയുന്നത്. ശാഖയുടെ പ്രിഫിക്സ് വെവ്വേറെ പ്രഖ്യാപിക്കേണ്ട കാര്യമാണ്; അതിനുശേഷവും ശാഖയ്ക്ക് ഫോർവേർഡർ, ആസ്ഥാനത്തിന് തിരിച്ചുവരവ് പാത എന്നിവ വേണം. തെറ്റായ സ്ഥലത്ത് എഴുതിയ റൂട്ട് ഒന്നും മാറ്റില്ല.

രണ്ട് വിലാസങ്ങൾ, രണ്ട് വ്യത്യസ്ത ഉടമസ്ഥാവകാശങ്ങൾ

ക്ലയന്റ് ബന്ധിപ്പിക്കുമ്പോൾ Access Server ക്രമീകരിച്ച VPN പൂളിൽ നിന്ന് വിലാസം നൽകുന്നു, ഉദാ. 10.90.0.0/24. അത് ഒരു ഹോസ്റ്റിനുള്ള പാട്ടമാണ്. അതേ ക്ലയന്റ് 10.60.0.0/24-ന്റെ മുന്നിലുമുണ്ടെന്ന് ബന്ധം പറയുന്നില്ല; സർവർ ഊഹിക്കില്ല: അഡ്മിൻ പ്രഖ്യാപിച്ചാൽ മാത്രമേ LAN പ്രിഫിക്സ് ഒരു നിർദ്ദിഷ്ട ക്ലയന്റിലൂടെ എത്തുകയുള്ളൂ.

അതുകൊണ്ട് മറ്റൊരു മെഷീനിലെ സ്റ്റാറ്റിക് റൂട്ട് ഫലിക്കില്ല. റൂട്ട് 10.60.0.0/24 ഈ വിലാസത്തിലേക്ക് അയക്കാൻ പറയുന്നു; വിലാസം ഗേറ്റ്‌വേയായി അടയാളപ്പെടുത്താത്ത ക്ലയന്റിന്റേതാണെങ്കിൽ, ആ പാക്കറ്റുകൾ അവിടെ എത്തിക്കാൻ സർവറിന് കാരണമില്ല, ക്ലയന്റ് സ്റ്റാക്ക് അവ ഉപേക്ഷിച്ചേക്കാം. പ്രഖ്യാപനവും റൂട്ടും ഒരു സംവിധാനത്തിന്റെ രണ്ട് പകുതികളാണ്.

ഗേറ്റ്‌വേ ക്രമീകരണം യഥാർത്ഥത്തിൽ എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു

Admin Web UI-ൽ പ്രഖ്യാപനം ഒരു ഉപയോക്തൃ ഗുണമാണ്: കണക്ടർ ഉപയോക്താവിൽ Configure VPN gateway സജീവമാക്കി ശാഖയുടെ യഥാർത്ഥ പ്രിഫിക്സ് Network on the VPN client side-ൽ നൽകുക. ആ ഉപയോക്താവും മറ്റുള്ളവരെപ്പോലെ പ്രാമാണീകരിക്കപ്പെടുന്നു, അതിനാൽ നിരീക്ഷണമില്ലാത്ത ഉപകരണത്തിന് യോജിച്ച ക്രെഡൻഷ്യൽ നയം വേണം; സ്വയം ലോഗിൻ പ്രൊഫൈൽ രഹസ്യമാണ്.

ആ ചെക്ക്ബോക്സിന് പിന്നിൽ സർവർ പ്രിഫിക്സിനെ ആ ക്ലയന്റിന്റെ പൂൾ വിലാസത്തിലൂടെ എത്താവുന്നതായി കണക്കാക്കുന്നു; Access Controls-ന് കീഴിലുള്ള റൂട്ടിംഗ് ക്രമീകരണം മറ്റ് ക്ലയന്റുകളോട് എന്ത് പറയണമെന്ന് തീരുമാനിക്കുന്നു: സാധാരണ ക്ലയന്റുകൾക്ക് അയക്കുന്ന റൂട്ടുകളും ആസ്ഥാന നെറ്റ്‌വർക്കുകളിൽ നിന്ന് ക്ലയന്റ് വിലാസങ്ങളിലേക്കുള്ള ആക്സസ് നിയമങ്ങളും. ശാഖയിൽ എത്തേണ്ട നെറ്റ്‌വർക്കുകൾക്ക് റൂട്ടിംഗ് സജീവമാക്കി അനുവദിച്ച പട്ടിക ചെറുതായി സൂക്ഷിക്കുക.

ജനറേറ്റ് ചെയ്ത ഫയലിൽ ഒട്ടിച്ച Community ശൈലിയിലുള്ള നിർദ്ദേശം ഈ മാതൃകയിൽ പങ്കെടുക്കുന്നില്ല. ഉൽപ്പന്നം അയക്കുന്ന റൂട്ടിംഗ് പട്ടിക അതിന്റേതാണ്; കൈകൊണ്ട് തിരുത്തിയ വരി അവഗണിക്കപ്പെടും.

രണ്ട് നെറ്റ്‌വർക്കുകളുടെയും തിരിച്ചുവരവ് പാതകൾ പൂർത്തിയാക്കുക

നിർദ്ദിഷ്ട പദ്ധതി: ആസ്ഥാനം 10.40.0.0/24, ശാഖ 10.60.0.0/24, VPN പൂൾ 10.90.0.0/24, Access Server ആസ്ഥാനത്തിന്റെ വശത്തുള്ള സ്വകാര്യ വിലാസത്തിൽ ലഭ്യം. ആസ്ഥാന റൗട്ടറിന് ശാഖാ പ്രിഫിക്സിനും പൂളിനും റൂട്ടുകൾ വേണം, രണ്ടും Access Server-ലേക്ക്. ഇല്ലെങ്കിൽ മറുപടി ഡിഫോൾട്ട് ഗേറ്റ്‌വേയിലൂടെ പുറത്തുപോകുന്നു, ഇത് പകുതി തുറന്ന കണക്ഷൻ സൃഷ്ടിക്കുന്നു.

ശാഖയിൽ കണക്ടർ തന്നോട് അഭിസംബോധന ചെയ്യാത്ത പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യണം: OS-ൽ IP ഫോർവേഡിംഗും ടണൽ, LAN ഇന്റർഫേസുകളിൽ പരിമിതപ്പെടുത്തിയ അനുമതിയും; Linux-ൽ net.ipv4.ip_forward=1 ഫോർവേഡ് ചെയിൻ നിയമങ്ങളോടൊപ്പം, Windows-ൽ routing and remote access. തുടർന്ന് ശാഖാ ഹോസ്റ്റുകൾക്ക് തിരിച്ചുവരവ് പാത വേണം: കണക്ടർ അവരുടെ ഡിഫോൾട്ട് ഗേറ്റ്‌വേയാകണം, അല്ലെങ്കിൽ നിലവിലുള്ള ഗേറ്റ്‌വേ ആസ്ഥാന-പൂൾ പ്രിഫിക്സുകൾക്ക് പ്രത്യേക റൂട്ടുകൾ വഹിക്കണം.

കണക്ടറിന്റെ റൂട്ടിംഗ് പട്ടിക ശാഖാ LAN-ലെ എല്ലാ ഹോസ്റ്റുകളെയും വീണ്ടും ക്രമീകരിക്കുന്നില്ല. ഹോസ്റ്റുകൾ മറ്റൊരു റൗട്ടറിനെ ചൂണ്ടുന്നുവെങ്കിൽ തിരിച്ചുവരവ് റൂട്ടുകൾ അവിടെയാണ്; അത് കാണുന്ന ഉറവിട വിലാസം പ്രാദേശിക സബ്നെറ്റിലെ അയൽക്കാരനല്ലെന്ന് അംഗീകരിക്കണം.

പരാജയത്തെ പാതയായി വായിക്കുക

നിശ്ചിത ക്രമത്തിൽ പരിശോധിക്കുക. ആദ്യം Access Server-ൽ നിന്ന് ശാഖാ ഹോസ്റ്റിലേക്ക് അനുവദിച്ച സേവനം, പിന്നെ ആസ്ഥാനത്തെ സാധാരണ ഹോസ്റ്റിൽ നിന്ന് അതേ സേവനം, നയം അനുവദിച്ചാൽ വിപരീത ദിശ. ആദ്യത്തേത് കടന്ന് രണ്ടാമത്തേത് പരാജയപ്പെട്ടാൽ അയച്ച റൂട്ടുകളോ ആക്സസ് നിയമങ്ങളോ പ്രശ്നം. രണ്ടും കടന്നിട്ടും മറുപടി വരുന്നില്ലെങ്കിൽ ശാഖയിലെ ഫോർവേഡിംഗും ആസ്ഥാനത്തെ തിരിച്ചുവരവ് റൂട്ടും പരിശോധിക്കുക.

ഹോസ്റ്റ് ഫയർവാൾ അടുത്ത സംശയം, കാരണം റൂട്ടഡ് ആക്സസിൽ ലക്ഷ്യം ആസ്ഥാനത്തിന്റെയോ പൂളിന്റെയോ വിലാസത്തെ ഉറവിടമായി കാണുന്നു. പ്രാദേശിക സബ്നെറ്റിനായി എഴുതിയ നിയമം യോജിക്കില്ല; റൂട്ടിംഗ് മികച്ചതായി പ്രവർത്തിച്ച ശേഷം പാക്കറ്റ് ഉപേക്ഷിക്കപ്പെടുന്നു.

രണ്ട് ഡിസൈനുകൾക്ക് കൂടുതൽ വേണം. സൈറ്റുകൾക്കിടയിൽ ഓവർലാപ്പ് ചെയ്യുന്ന പ്രിഫിക്സുകൾ ലക്ഷ്യത്തെ അവ്യക്തമാക്കി പുനർനമ്പറിംഗോ വിവർത്തനമോ ആവശ്യപ്പെടുന്നു; ക്ലസ്റ്റർ Access Server-ന് റൂട്ട് ഒരു നോഡിൽ സൂക്ഷിക്കുന്നതിനുപകരം എല്ലാ നോഡുകൾക്കും ശാഖാ കണക്ടറിലേക്ക് പ്രവർത്തിക്കുന്ന പാത വേണം. മാറ്റങ്ങൾ സാധാരണ സേവ്, അപ്ഡേറ്റ് പാതയിലൂടെ പ്രയോഗിച്ച് കണക്ടർ വീണ്ടും ബന്ധിപ്പിച്ച് ഇരു വശങ്ങളിൽ നിന്നും പരിശോധിക്കുക; എല്ലാ മെഷീനുകളുടെയും പൂർണ്ണ റീബൂട്ട് നടപടിക്രമത്തിന്റെ ഭാഗമല്ല.

Access Server site-to-site ട്യൂട്ടോറിയൽ അതേ ക്രമീകരണങ്ങൾ ഉൽപ്പന്ന ക്രമത്തിൽ ലിസ്റ്റ് ചെയ്യുന്നു; ഡിസൈൻ ക്രമീകരിക്കുന്നതിന് മുമ്പ് ഒരിക്കൽ പിന്തുടരാൻ യോഗ്യം.