LAN ഹോസ്റ്റ് OpenVPN ക്ലയന്റിന്റെ വിലാസത്തിന് ARP എന്തിന് അയയ്ക്കുന്നു

LAN ഹോസ്റ്റും VPN ക്ലയന്റും തമ്മിലുള്ള എത്തിച്ചേരൽ പ്രശ്നങ്ങൾ പലപ്പോഴും വിലാസ പ്ലാനിലേക്കുതന്നെ മടങ്ങുന്നു. ആ ഹോസ്റ്റിന് 10.0.100.0/22-ൽ ഒരു ഇന്റർഫേസ് നൽകുക; അത് 10.0.100.0 മുതൽ 10.0.103.255 വരെയുള്ള ഓരോ വിലാസത്തെയും നേരിട്ട് ബന്ധിപ്പിച്ചതായി കണക്കാക്കും, 10.0.101.0/24-ൽ നിശ്ശബ്ദമായി വച്ച ക്ലയന്റ് പൂൾ ഉൾപ്പെടെ. മറുപടി ഒരിക്കലും റൗട്ടറിലേക്ക് പോകുന്നില്ല, കാരണം ഹോസ്റ്റിന്റെ കാഴ്ചയിൽ ഒരു റൗട്ടറും ഉൾപ്പെടുന്നില്ല. പാക്കറ്റ് ഒരു അയൽക്കാരനെ ലക്ഷ്യമിട്ട് വയറിൽ ആവശ്യപ്പെടുന്നു.

ഈ സംവിധാനം മുഴുവൻ റിപ്പോർട്ട് കുടുംബത്തിന്റെ പിന്നിലുണ്ട്: ടണൽ പ്രവർത്തിക്കുന്നു, സർവറിന് ഒരു റൂട്ടുണ്ട്, എന്നിട്ടും LAN ഹോസ്റ്റിന് ക്ലയന്റിനെ എത്താൻ കഴിയുന്നില്ല.

/24 വിഴുങ്ങുന്ന /22

പ്രിഫിക്സ് ഒരു പരിധിയായി വായിക്കുക, സ്ട്രിംഗായി അല്ല. ഒരു /22-ൽ 1024 വിലാസങ്ങളുണ്ട്, 10.0.100.0/22 10.0.100.0 മുതൽ 10.0.103.255 വരെ വ്യാപിക്കുന്നു, അതിനാൽ 10.0.101.0/24-ലെ പൂൾ പൂർണ്ണമായും അതിനുള്ളിലാണ്. ഈ തെറ്റ് അവലോകനത്തെ അതിജീവിക്കുന്നു, കാരണം പൂളിന്റെ ആദ്യ ഒക്ടെറ്റുകൾ LAN-ന്റെ ആദ്യ ഒക്ടെറ്റുകളിൽനിന്ന് വ്യത്യസ്തമായി കാണപ്പെടുന്നു, മൂന്നാം ഒക്ടെറ്റ് മാത്രമാണ് ഈ ഉൾച്ചേർക്കൽ വെളിപ്പെടുത്തുന്നത്. രണ്ട് പരിധികളും സംഖ്യകളിൽ എഴുതുക, അവയെ വേറിട്ടതായി പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ്.

അതേ ഉൾച്ചേർക്കൽ തലകീഴായി ദിശയിലും പ്രത്യക്ഷപ്പെടാം. ഇപ്പോൾ ആരും ഉപയോഗിക്കാത്തതിനാൽ ശൂന്യമായി തോന്നുന്ന പൂളും ഏതെങ്കിലും സൈറ്റ് റൗട്ടർ പ്രഖ്യാപിച്ച പ്രിഫിക്സിനുള്ളിൽ വീഴാം, വിലാസ പ്ലാൻ മാത്രമാണ് ഇത് കാണിക്കുന്ന ഏക രേഖ.

നേരിട്ടുള്ള കണക്ഷൻ അർത്ഥം ARP, റൗട്ടിംഗ് അല്ല

/22 ഇന്റർഫേസുള്ള ഹോസ്റ്റ് 10.0.101.25-ലേക്ക് അയയ്ക്കുമ്പോൾ, കേർണൽ ലക്ഷ്യത്തെ ഇന്റർഫേസിന്റെ പ്രിഫിക്സുമായി താരതമ്യം ചെയ്ത് പൊരുത്തം കണ്ടെത്തുന്നു. പാക്കറ്റ് റൗട്ട് ചെയ്ത പാക്കറ്റിനുപകരം അയൽക്കാരൻ തിരയലായി മാറുന്നു, ഈതർനെറ്റിൽ അയൽക്കാരൻ തിരയൽ ആ വിലാസത്തിനുള്ള ARP അഭ്യർത്ഥനയാണ്. വിലാസം റൗട്ട് ചെയ്ത ഗേറ്റ്വേയ്ക്ക് പിന്നിലുള്ള VPN ക്ലയന്റിന്റേതാണെങ്കിൽ, LAN-ൽ ഒരു ഹോസ്റ്റും അതിന്റെ ഉടമയല്ല, അതിനാൽ അഭ്യർത്ഥന മറുപടിയില്ലാതെ തുടരും, പാക്കറ്റുകൾ വലിച്ചെറിയപ്പെടും. ടണൽ കുറ്റക്കാരനല്ല, ക്ലയന്റ് ട്രാഫിക് ഒരിക്കലും കാണുന്നില്ല.

അതുകൊണ്ടാണ് പരാജയം അസമമായും ഇടയ്ക്കിടെ തടസ്സപ്പെട്ടതായും തോന്നുന്നത്. VPN ഹോസ്റ്റ് പലപ്പോഴും LAN-ൽ എത്തുന്നു, കാരണം അതിന്റെ സ്വന്തം റൂട്ടുകൾ ശരിയായ ദിശ കാണിക്കുന്നു, എന്നാൽ LAN ഹോസ്റ്റിന് മറുപടി നൽകാനാവില്ല, പഴയ ARP എൻട്രി കാഷ് ചെയ്യുന്ന ഏതും ലക്ഷണത്തെ മിന്നിത്തിളങ്ങാൻ വയ്ക്കുന്നു.

TUN, TAP എന്നിവയും ഓരോന്നും എന്ത് ചുമക്കുന്നു

TUN ഉപകരണം IP പാക്കറ്റുകളും TAP ഉപകരണം ഈതർനെറ്റ് ഫ്രെയിമുകളും ചുമക്കുന്നു. റൗട്ട് ചെയ്ത TUN ലിങ്ക് IP പ്രവേശനം നൽകാൻ ARP ചുമക്കേണ്ടതില്ല, അതുകൊണ്ടാണ് മുകളിലെ മറുപടിയില്ലാത്ത അഭ്യർത്ഥന പ്രതീക്ഷിക്കപ്പെടുന്നത്, കേടായതല്ല. മനഃപൂർവമുള്ള ബ്രിഡ്ജിനൊപ്പം TAP പ്രക്ഷേപണ ഡൊമെയ്ൻ വിപുലീകരിക്കാനും ARP പ്രവർത്തിപ്പിക്കാനും കഴിയും, പക്ഷേ ക്ലയന്റിന് എന്ത് കാണാനാകും എന്നത് മാറ്റുന്നു, അതേ ഫ്രെയിമിംഗ് പിന്തുണയ്ക്കുന്ന അറ്റങ്ങൾ ആവശ്യപ്പെടുന്നു, ഇത് ഓവർലാപ്പിംഗ് പ്രിഫിക്സിനുള്ള അറ്റകുറ്റപ്പണിയല്ല, നെറ്റ്വർക്ക് മാതൃകയുടെ പുനർരൂപകൽപ്പനയാണ്. വിലാസ പ്ലാൻ പിശക് ചികിത്സിക്കാൻ റൗട്ട് ചെയ്ത വിന്യാസം TAP-ലേക്ക് മാറ്റുന്നത് ചെറിയ പ്രശ്നത്തെ വലിയതുമായി കൈമാറുന്നു.

നിഗമനങ്ങളിൽ എത്തുന്നതിന് മുമ്പ് ARP അഭ്യർത്ഥന എവിടെ പ്രത്യക്ഷപ്പെട്ടു, ഏത് സംവിധാനം അയച്ചു എന്ന് രേഖപ്പെടുത്തുക. അയയ്ക്കുന്നയാൾ ലക്ഷ്യത്തെക്കുറിച്ച് താൻ എന്ത് കരുതുന്നു എന്ന് പറയുന്നു, ടണൽ എന്ത് ചെയ്യുന്നു എന്നല്ല.

ഓവർലാപ്പ് ചെയ്യാനാവാത്ത പൂൾ രൂപകൽപ്പന ചെയ്യുക

ഓരോ ബന്ധിപ്പിച്ച പ്രിഫിക്സിനും ഓരോ പ്രഖ്യാപിത സൈറ്റ് പ്രിഫിക്സിനും പുറത്ത് പൂൾ തിരഞ്ഞെടുക്കുക, പിന്നീട് അതിനെ രണ്ട് ദിശകളിലും എത്താൻ കഴിയുന്നതാക്കുന്ന റൂട്ടുകൾ ചേർക്കുക. പ്ലാനിന്റെ ഉപയോഗിക്കാത്ത ഭാഗത്ത് 10.8.0.0/24 പോലുള്ള ഒരു പരിധി ചിന്തിക്കാൻ എളുപ്പമാണ്, അതിൽ എത്തേണ്ട LAN, VPN സർവറിലേക്ക് ചൂണ്ടുന്ന ഒരു സ്ഥിതിക റൂട്ട് നേടുന്നു. അനുവദനം, പ്രഖ്യാപിത റൂട്ടുകൾ, അനുവദിച്ച ഉറവിട വിലാസങ്ങൾ, ഫയർവാൾ നിയമങ്ങൾ എന്നിവ ഒരുമിച്ച് മാറ്റുക, കാരണം അവ നാല് ക്രമീകരണങ്ങളല്ല, ഒരു രൂപകൽപ്പനയെ വിവരിക്കുന്നു.

സർവറിലെ Source NAT പൂളിനെ LAN-ൽനിന്ന് റൗട്ട് ചെയ്യാവുന്ന വിലാസത്തിന് പിന്നിൽ ഒളിപ്പിക്കാം, ഇത് നിയമാനുസൃതമായ കുടിയേറ്റ ഉപകരണമാണ്. ഇത് ഉറവിടവും വീണ്ടും എഴുതുന്നു, അതിനാൽ കണക്ഷനുകളെ വ്യക്തിഗത ക്ലയന്റുകൾക്ക് ആരോപിക്കാനും ക്ലയന്റ് അനുസരിച്ച് നിയമങ്ങൾ പ്രയോഗിക്കാനുമുള്ള കഴിവ് LAN നഷ്ടപ്പെടുന്നു.

സ്വീകരണത്തിന് യഥാർത്ഥ ക്ലയന്റിന് യഥാർത്ഥത്തിൽ അനുവദിച്ച വിലാസവും LAN ഹോസ്റ്റിൽനിന്നുള്ള യഥാർത്ഥ ആപ്ലിക്കേഷൻ അഭ്യർത്ഥനയും ഉപയോഗിച്ച്, തുടർന്ന് മറുപടി വയറിനെയല്ല, ആസൂത്രിത ഗേറ്റ്വേയെ പിന്തുടരുന്നു എന്ന് സ്ഥിരീകരിക്കുക.