LAN സെർവറിലെ VPN ക്ലയന്റ്: മറുപടികൾ തെറ്റായ വഴിയിലേക്ക് പോകുന്നതെന്തുകൊണ്ട്

ലക്ഷണങ്ങൾ ഒരേ ആകൃതി പിന്തുടരുന്നു: ഒരു ഹോസ്റ്റ് പ്രവർത്തിക്കുന്നു, പിന്നീട് അത് ക്ലയന്റായി VPN-ലേക്ക് ബന്ധിപ്പിക്കുന്നു, ഇപ്പോൾ LAN ക്ലയന്റുകൾ അതിലേക്ക് എത്തുന്നു, അതേസമയം അതിന്റെ മറുപടികൾ അപ്രത്യക്ഷമാകുന്നു. ഹോസ്റ്റിൽ എടുത്ത ക്യാപ്ചർ കാണിക്കുന്നത് മറുപടികൾ LAN ഇന്റർഫേസിന് പകരം ടണൽ ഉപകരണത്തിലൂടെ പുറത്തുപോകുന്നു എന്നാണ്. ടണലിൽ ഒന്നും തകർന്നിട്ടില്ല, പരിഹാരം ഒരു റൂട്ടാണ്, വീണ്ടും കണക്ട് ചെയ്യലല്ല. താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക.

മറുപടി ഒരു പുതിയ പാക്കറ്റാണ്, വഴിയുടെ തിരിച്ചുപോക്കല്ല

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

അതുകൊണ്ടാണ് LAN-നും സേവനം നൽകുന്ന ഒരു മെഷീനിൽ പൂർണ്ണ ടണൽ ക്ലയന്റ് ഇത്ര ആശയക്കുഴപ്പമുള്ള ഒരു പരാജയം സൃഷ്ടിക്കുന്നത്. ക്ലയന്റ് ഒരു സ്ഥിര റൂട്ടോ, ചില ക്ലയന്റുകൾ ഇഷ്ടപ്പെടുന്ന രണ്ട് പകുതി-സ്ഥിര റൂട്ടുകളോ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, LAN ക്ലയന്റിനുള്ള മറുപടി ഇപ്പോൾ ടണലുമായി ഒത്തുപോകുന്നു. അത് ദാതാവിന്റെ അടുത്തേക്ക് പോകുന്നു, അവർക്ക് അത് കൈമാറാൻ കാരണമില്ല, ഹോസ്റ്റ് പ്രവർത്തിക്കുകയും പ്രാദേശികമായി മറുപടി നൽകുകയും ചെയ്യുമ്പോഴും LAN ക്ലയന്റ് കാലഹരണം കാണുന്നു. ക്യാപ്ചർ അത് വ്യക്തമാക്കുന്നു, റൂട്ടിംഗ് പട്ടിക അത് വിശദീകരിക്കുന്നു.

ബാക്കി വായിക്കുമ്പോൾ രണ്ട് ഉപനെറ്റ്വർക്കുകൾ മനസ്സിൽ സൂക്ഷിക്കുക. ഒന്ന് ദൂരെയുള്ള ക്ലയന്റുകൾ വരുന്ന VPN വിലാസ പൂൾ, ഈ ഉദാഹരണത്തിൽ 10.64.0.0/24. മറ്റൊന്ന് പ്രവർത്തിച്ചുകൊണ്ടിരിക്കേണ്ട LAN, 172.16.24.0/24, അതിന്റെ റൂട്ടർ 172.16.24.1 ൽ. പിഴവ് എന്നത് അവയ്ക്കിടയിലുള്ള ട്രാഫിക് സ്ഥിര റൂട്ട് തീരുമാനിക്കുന്നു എന്നതാണ്.

ക്യാപ്ചറും ലുക്കപ്പും കൊണ്ട് അത് തെളിയിക്കുക

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് മറുപടി ഏത് ഉപകരണം ഉപയോഗിക്കുമെന്ന് സ്ഥിരീകരിക്കുക. ലുക്കപ്പ് ക്യാപ്ചറിനേക്കാൾ വേഗമേറിയതാണ്, പാക്കറ്റ് നിർമ്മിക്കുമ്പോൾ കേർണൽ ഉത്തരം നൽകുന്ന അതേ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

മറുപടി രണ്ട് ഭാഗങ്ങളായി വായിക്കുക. അത് dev tun0 എന്ന് പേരിട്ടാൽ, ഹോസ്റ്റ് മറുപടി എൻകാപ്സുലേറ്റ് ചെയ്ത് ദാതാവിന് നൽകും, LAN ക്ലയന്റ് അത് ഒരിക്കലും കാണില്ല. അത് dev eth0 എന്ന് പേരിട്ടിട്ടും ക്ലയന്റ് ഇപ്പോഴും കാലഹരണം നേടുന്നുവെങ്കിൽ, റൂട്ട് ഇതിനകം ശരിയാണ്, പാക്കറ്റ് പിന്നീട് ഉപേക്ഷിക്കപ്പെടുന്നു, അത് മറ്റൊരു പ്രശ്നവും മറ്റൊരു പരിഹാരവുമാണ്.

അതേ ഘട്ടത്തിലെ ക്യാപ്ചർ ping പരിഹരിക്കാനാകാത്ത സംശയം തീർക്കുന്നു. LAN ക്ലയന്റിലേക്ക് എത്തുന്ന എക്കോ മറുപടി ഏതോ ഒരു വഴി പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, ഏത് ഇന്റർഫേസ് അത് വഹിച്ചു എന്നല്ല, അതിനാൽ ക്യാപ്ചർ ഹോസ്റ്റിൽ തന്നെ പ്രവർത്തിപ്പിച്ച് ഫ്രെയിമുകൾ എവിടെനിന്ന് പുറത്തുപോകുന്നു എന്ന് നോക്കുക. അതേ ഉപനെറ്റ്വർക്കിലെ പ്രിന്റർ മറുപടി നൽകുന്നത് തുടരുന്നു, കാരണം അതിന്റെ നേരിട്ടുള്ള റൂട്ട് ടണലിന്റെ സ്ഥിര റൂട്ടിനേക്കാൾ കൃത്യമാണ്. ഫോർവേഡ് ചെയ്ത പോർട്ട് മറ്റേതെങ്കിലും ഫ്ലോ പോലെ തന്നെ പരാജയപ്പെടുന്നു, കാരണം ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നത് പട്ടികയാണ്, കണക്ഷനല്ല.

ടണലിനെ മറികടക്കുന്ന ഏറ്റവും ഇടുങ്ങിയ റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുക

പ്രിഫിക്സ് നീളമാണ് തീരുമാനിക്കുന്നത്, മെട്രിക് അല്ല, അതിനാൽ LAN റൂട്ടർ വഴിയുള്ള ക്ലയന്റ് പൂൾ റൂട്ട് VPN ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഏത് സ്ഥിര റൂട്ടിനെയും തോൽപ്പിക്കുന്നു. മെട്രിക് ശസ്ത്രക്രിയ ആവശ്യമില്ല, സ്ഥിര റൂട്ട് ക്ലയന്റ് ഇട്ട അതേ സ്ഥലത്ത് തുടരാം.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

രണ്ടാമത്തെ add പകരം replace ഉപയോഗിക്കുക, കാരണം വീണ്ടും കണക്ട് ചെയ്യുന്ന ക്ലയന്റ് അതിന്റെ സ്വന്തം എൻട്രി ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടാകും, രണ്ടാമത്തെ add അനുമതി പ്രശ്നമായി വായിക്കുന്ന നിലവിലുള്ള റൂട്ട് പിശകിനാൽ പരാജയപ്പെടുന്നു. Windows ഹോസ്റ്റിൽ തുല്യമായത് route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p ആണ്, അവിടെ -p റീബൂട്ടുകൾക്കിടയിൽ എൻട്രി നിലനിർത്തുന്നു, കാരണം ടണൽ വീണ്ടും ഉയരുമ്പോൾ ക്ലയന്റ് പട്ടിക പുനർനിർമ്മിക്കാം. ആധുനിക Windows ഹോസ്റ്റിൽ പിന്തുണയുള്ള തുല്യമായത് New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore ആണ്, പഴയ route കമാൻഡ് പാരമ്പര്യ രൂപമായി നിലനിർത്തുന്നു.

ഒരു വിശദാംശം ഇത് ശരിയാണോ വെറും വിശ്വസനീയമാണോ എന്ന് തീരുമാനിക്കുന്നു: അടുത്ത ഹോപ്പ് ക്ലയന്റുകളിലേക്കുള്ള തിരിച്ചുവരവ് വഴി യഥാർത്ഥത്തിൽ കൈവശം വയ്ക്കുന്ന റൂട്ടർ ആയിരിക്കണം. ടണലിലൂടെ തന്നെ എത്തുന്ന ഒരു വിലാസത്തിലേക്ക് റൂട്ട് ചൂണ്ടിക്കാണിക്കുന്നത്, വ്യക്തമായ പരാജയത്തിന് പകരം ഇടയ്ക്കിടെയുള്ള നഷ്ടമായി പ്രത്യക്ഷപ്പെടുന്ന ഒരു ലൂപ്പ് സൃഷ്ടിക്കുന്നു. വരി സ്ഥിരീകരിക്കുന്നതിന് മുമ്പ് അടുത്ത ഹോപ്പ് LAN ഉപനെറ്റ്വർക്കിലാണെന്ന് ഉറപ്പാക്കുക.

വീണ്ടും കണക്ട് ചെയ്തതിന് ശേഷം മറുപടി നിലനിർത്തുക

കൈകൊണ്ട് ചേർത്ത റൂട്ട് ഏറ്റവും നല്ലതിൽ അടുത്ത വീണ്ടും കണക്ട് ചെയ്യൽ വരെ നിലനിൽക്കുന്നു. ക്ലയന്റ് പൂൾ ചലനാത്മകമാണെങ്കിൽ, നിങ്ങൾ റൂട്ട് ചെയ്ത പ്രിഫിക്സ് ക്ലയന്റുകൾക്ക് ലഭിക്കുന്ന പ്രിഫിക്സ് ആയി തുടരാൻ അത് സെർവർ കോൺഫിഗറേഷനിൽ പിൻ ചെയ്യുക; അല്ലെങ്കിൽ എൻട്രി ശൂന്യമായ ശ്രേണിയെ ചൂണ്ടിക്കാണിക്കുകയും ലക്ഷണം ആഴ്ചകൾക്ക് ശേഷം വ്യക്തമായ കാരണമില്ലാതെ മടങ്ങുകയും ചെയ്യുന്നു. റൂട്ട് ക്ലയന്റിന്റെ സ്വന്തം up-സ്ക്രിപ്റ്റിൽ എഴുതുന്നത് മറ്റൊരു വിശ്വസനീയമായ ഓപ്ഷനാണ്, കാരണം ക്ലയന്റ് പട്ടിക വീണ്ടും എഴുതിയതിന് ശേഷമാണ് അത് പ്രവർത്തിക്കുന്നത്.

സ്റ്റേറ്റ്ഫുൾ ഫയർവാൾ ശരിയായ റൂട്ടിനെ ഇപ്പോഴും തോൽപ്പിക്കാം. ക്യാപ്ചർ ഇപ്പോൾ മറുപടി eth0 വഴി പുറത്തുപോകുന്നു എന്ന് കാണിക്കുകയും ക്ലയന്റ് ഇപ്പോഴും കാലഹരണം നേടുകയും ചെയ്താൽ, ഹോസ്റ്റ് അയയ്ക്കുന്നതിന് മുമ്പ് പാക്കറ്റ് ഉപേക്ഷിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. കർശനമായ റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ് ഉം net.ipv4.conf.all.rp_filter 1 ആക്കി സജ്ജീകരിക്കുന്നതും, വന്ന ഇന്റർഫേസിലൂടെ തിരികെ റൂട്ട് ചെയ്യപ്പെടാത്ത ഉറവിടമുള്ള പാക്കറ്റുകൾ ഉപേക്ഷിക്കുന്നു, അത് നിങ്ങൾ ഇപ്പോൾ സൃഷ്ടിച്ച് പിന്നീട് പരിഹരിച്ച അസമമായ കേസ് തന്നെയാണ്, conntrack അവസ്ഥ ഫോർവേഡ് ചെയ്ത പോർട്ടുകൾക്കും അതേ കഥ പറയുന്നു.

അവസാന പരിശോധന ആളുകൾ ഒഴിവാക്കുന്നതാണ്: ടണൽ താഴേക്ക് പോയി വീണ്ടും ഉയർന്നതിന് ശേഷം ലുക്കപ്പ് ആവർത്തിക്കുക. നാല് മൂല്യങ്ങൾ നിങ്ങൾ എഴുതിയതുമായി ഒത്തുപോകണം: ലക്ഷ്യം, അടുത്ത ഹോപ്പ്, ഉപകരണം, തിരഞ്ഞെടുത്ത ഉറവിടം. അവയിലൊന്ന് നീങ്ങിയിട്ടുണ്ടെങ്കിൽ, ക്ലയന്റ് പട്ടിക വീണ്ടും എഴുതി, പരിഹാരം അതിന്റെ ഹൂക്കുകളിലാണ്, shell ചരിത്രത്തിലല്ല.