റൂട്ട് ചെയ്ത VPN ക്ലയന്റ് സെർവറിൽ എത്തുന്നു പക്ഷേ LAN ഹോസ്റ്റുകളിൽ എത്തുന്നില്ല

ടണൽ ഉയരുന്നു, ക്ലയന്റ് VPN സെർവറിലേക്ക് പിംഗ് അയയ്ക്കുന്നു, ഒരു ചുവട് അകലെയുള്ള മെഷീനിലെ പങ്കിട്ട ഫോൾഡർ ഒരിക്കലും മറുപടി നൽകുന്നില്ല. ക്ലയന്റ് കോൺഫിഗറേഷനിൽ ഇത് വിശദീകരിക്കുന്ന ഒന്നുമില്ല, കാരണം അഭ്യർത്ഥന ക്ലയന്റിൽ നിന്ന് യഥാർത്ഥത്തിൽ പുറപ്പെട്ടു, യഥാർത്ഥത്തിൽ എത്തി. പരാജയപ്പെട്ടത് തിരികെയുള്ള യാത്രയാണ്, പരാജയപ്പെട്ട ഉപകരണം സാധാരണയായി VPN ഹോസ്റ്റല്ല, LAN ഗേറ്റ്വേയാണ്. മറുപടി പാക്കറ്റ് ട്രേസ് ചെയ്യുന്നത് ഈ ലക്ഷണ വർഗ്ഗത്തെ മുഴുവൻ വിശദീകരിക്കുന്നു.

അഭ്യർത്ഥനയല്ല, മറുപടിയെ പിന്തുടരുക

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

ക്ലയന്റിൽ ലക്ഷണം നിശ്ശബ്ദമായ സമയപരിധിയാണ്: നിരസിക്കലില്ല, റീസെറ്റില്ല, ഒന്നുമില്ല. പങ്കിട്ട ഫോൾഡർ ബ്രൗസ് ചെയ്യുന്നത് തടയുന്നു, പിംഗ് മറുപടിയില്ലെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, സെർവർ ലോഗുകൾ ആരോഗ്യകരമായി തോന്നുന്നു, കാരണം സെർവർ അതിന്റെ ജോലി ചെയ്തു.

ഹോസ്റ്റുകൾ നോക്കുന്നിടത്ത് റിട്ടേൺ റൂട്ട് വയ്ക്കുക

ഓരോ LAN ഹോസ്റ്റും അതിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേയോട് ആലോചിക്കുന്നു, അതിനാൽ ടണൽ പൂൾ എവിടെയാണെന്ന് അറിയേണ്ട ഏക ഉപകരണം ഗേറ്റ്വേയാണ്. അവിടെ ഒരു സ്റ്റാറ്റിക് റൂട്ട് ചേർക്കുക, ഓരോ ഹോസ്റ്റും തൊടാതെ ശരിയായ വഴി പാരമ്പര്യമായി നേടും.

ഗേറ്റ്വേ അതിന്റെ സ്വന്തം വിലാസം DHCP ഓപ്ഷനായി വിതരണം ചെയ്യുന്നുവെങ്കിൽ, റൂട്ട് അതേ രീതിയിൽ വിതരണം ചെയ്യുക, പുതിയ മെഷീനുകൾ അത് സ്വയമേവ എടുക്കും. അല്ലെങ്കിൽ റൂട്ട് ഒരു കോൺഫിഗറേഷൻ ഫയലിൽ കഴിയുന്നു, അടുത്ത പുനർനിർമ്മാണത്തിൽ അപ്രത്യക്ഷമാകുന്നു.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

സോഴ്സ് NAT അത് ശരിയാക്കുന്നതായി തോന്നുന്നത് എന്തുകൊണ്ട്

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

ആ കൈമാറ്റം ചിലപ്പോൾ ശരിയാണ്, ഉദാഹരണത്തിന് ഒരു വെണ്ടർ ഉപകരണത്തിന് സ്റ്റാറ്റിക് റൂട്ട് നൽകാൻ കഴിയാത്തപ്പോൾ. നിയമം നിലവിലെ പൂളിനെക്കാൾ വിശാലമാക്കരുത്, കാരണം /24-നായി എഴുതിയ നിയമം പൂൾ /16-ലേക്ക് പുനർനമ്പർ ചെയ്യുന്ന ദിവസം പൊരുത്തപ്പെടുന്നത് നിർത്തുന്നു, ആദ്യ സൂചന ബന്ധിപ്പിക്കുകയും എവിടെയും എത്താതിരിക്കുകയും ചെയ്യുന്ന പുതിയ ക്ലയന്റുകളുടെ കൂട്ടമാണ്.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

ക്ലൗഡ് വഴിക്ക് മൂന്ന് ക്രമീകരണങ്ങൾ വേണം

VPC-യിൽ അതേ വിടവ് മറ്റൊരു രൂപത്തിൽ മടങ്ങുന്നു, കാരണം സബ്നെറ്റിന് ക്ലയന്റ് ശ്രേണിക്ക് ഒരു റൂട്ടുമില്ല. റൂട്ട് ടേബിളിന് ടണൽ പൂളിനായി ഇൻസ്റ്റൻസിന്റെ നെറ്റ്വർക്ക് ഇന്റർഫേസ് ലക്ഷ്യമാക്കുന്ന ഒരു എൻട്രി വേണം, ഇന്റർഫേസിൽ സോഴ്സ്, ഡെസ്റ്റിനേഷൻ പരിശോധന ഓഫ് ചെയ്തിരിക്കണം, അപ്പോൾ സ്വന്തം വിലാസമല്ലാത്ത ഉറവിടമുള്ള പാക്കറ്റുകൾ പ്ലാറ്റ്ഫോം സ്വീകരിക്കും. സെക്യൂരിറ്റി ഗ്രൂപ്പുകളും നെറ്റ്വർക്ക് ACL-കളും ഇരു ദിശകളിലും പൂൾ അനുവദിക്കണം.

ഓരോ വിട്ടുപോകലും വ്യത്യസ്തമായ ഭാഗിക പരാജയം സൃഷ്ടിക്കുന്നു. റൂട്ട് ടേബിളിലെ എൻട്രി വിട്ടുപോയാൽ, സ്വകാര്യ ഇൻസ്റ്റൻസുകൾ മറുപടി പൂളിലേക്ക് തിരികെ കൊണ്ടുപോകാൻ കഴിയാത്ത സബ്നെറ്റിലേക്ക് മറുപടി നൽകുന്നു. പരിശോധന ഓണായിരിക്കുമ്പോൾ, ഇൻസ്റ്റൻസ് ഇതിനകം അയച്ചതിന് ശേഷം പ്ലാറ്റ്ഫോം മറുപടി ഉപേക്ഷിക്കുന്നു. സെക്യൂരിറ്റി ഗ്രൂപ്പ് നിയമമില്ലാതെ അഭ്യർത്ഥന തന്നെ ഒരിക്കലും എത്തുന്നില്ല, ക്ലയന്റ് സമയപരിധി ഒരു പാളി മുൻപേ കാണുന്നു.

പരിശോധനകൾ ഈ ക്രമത്തിൽ നടത്തുക

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

ക്ലയന്റ് LAN ഹോസ്റ്റിലേക്ക് പിംഗ് ചെയ്യുമ്പോൾ അവിടെ എടുത്ത ക്യാപ്ചറോടെ അവസാനിപ്പിക്കുക. ചേരുന്ന മറുപടിയില്ലാതെ എത്തുന്ന അഭ്യർത്ഥന തിരികെയുള്ള വഴി തെളിയിക്കുന്നു, ഒരിക്കലും എത്താത്ത അഭ്യർത്ഥന കുറ്റം സെർവറിലേക്കോ ടണലിലേക്കോ തിരികെ അയയ്ക്കുന്നു.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

സോഴ്സ്, ഡെസ്റ്റിനേഷൻ പരിശോധന ഇലാസ്റ്റിക് നെറ്റ്വർക്ക് ഇന്റർഫേസ് ഗൈഡിൽ രേഖപ്പെടുത്തിയിരിക്കുന്നു. ടണൽ ട്രാഫിക് യഥാർത്ഥത്തിൽ വഹിക്കുന്ന ഇന്റർഫേസിൽ അത് സജ്ജമാക്കുക, അതേ ഇൻസ്റ്റൻസിൽ ഘടിപ്പിച്ച അനുബന്ധമല്ലാത്ത അഡാപ്റ്ററിൽ അല്ല.