ഹെയർപിൻ NAT: ഉള്ളിൽ നിന്ന് VPN എൻഡ്പോയിന്റ് എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

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

പാക്കറ്റ് പുറത്തുപോയി തിരികെ അകത്തേക്ക് വരുന്നു

പാക്കറ്റ് പിന്തുടരുക. ക്ലയന്റ് പൊതു നാമം പരിഹരിക്കുന്നു, പൊതു വിലാസത്തിലേക്ക് ബന്ധിപ്പിക്കുന്നു, റൂട്ടറിന്റെ ലക്ഷ്യ NAT ലക്ഷ്യസ്ഥാനം ആന്തരിക സെർവറിലേക്ക് വീണ്ടും എഴുതുന്നു. സെർവറിന്റെ മറുപടി ക്ലയന്റിന്റെ LAN വിലാസത്തിലേക്ക് അഭിസംബോധന ചെയ്തിരിക്കുന്നു, അതിനാൽ ഉറവിടം തിരികെ വിവർത്തനം ചെയ്യുമായിരുന്ന NAT നിയമം ഒരിക്കലും കടക്കാതെ അത് റൂട്ടറിന്റെ LAN ഇന്റർഫേസിലൂടെ തിരികെ പോകുന്നു.

ഇപ്പോൾ ക്ലയന്റ് ഒരിക്കലും ഒന്നും അയച്ചിട്ടില്ലാത്ത ഒരു വിലാസത്തിൽ നിന്ന് പാക്കറ്റ് സ്വീകരിച്ച് അത് ഉപേക്ഷിക്കുന്നു. ആ അസമത്വമാണ് മുഴുവൻ തകരാറും.

ഈ സാഹചര്യത്തിൽ NAT-ൽ നിന്ന് പ്രതീക്ഷിക്കുന്ന സ്വഭാവം RFC 4787 വിവരിക്കുന്നു, ചുരുക്കം എന്നത് സിദ്ധാന്തത്തിൽ വ്യക്തമാക്കിയിടത്തും പ്രായോഗികമായി അത് ഐച്ഛികമാണ് എന്നാണ്. ചില റൂട്ടറുകൾ ഈ ക്രമീകരണത്തെ NAT loopback എന്ന് വിളിക്കുന്നു, മറ്റുള്ളവ ഹെയർപിൻ NAT അല്ലെങ്കിൽ NAT reflection എന്ന് വിളിക്കുന്നു, ചിലത് ഒന്നും കാണിക്കുന്നുമില്ല. ഇതില്ലാത്ത റൂട്ടർ തെറ്റായി ക്രമീകരിച്ചതല്ല; അത് സാധാരണ കാര്യം ചെയ്യുന്നു, പരിഹാരം മറ്റൊരിടത്താണ്. പ്രാദേശിക പരിശോധന പരാജയപ്പെട്ടതിൽ നിന്ന് പൊതു ഫോർവേഡിംഗ് നിയമം തെറ്റാണെന്ന് അനുമാനിക്കരുത്.

പരിശോധന 1: രണ്ട് പാതകളും വെവ്വേറെ പരിശോധിക്കുക

LAN-ന് പുറത്തുനിന്ന് യഥാർത്ഥ ഉപയോക്താവ് ഉപയോഗിക്കുന്ന അതേ പ്രൊഫൈലിൽ ബന്ധിപ്പിച്ച് സെഷൻ സ്ഥാപിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. അകത്തുനിന്ന് അതേ പ്രൊഫൈലിൽ പൊതു വിലാസത്തിലേക്ക് ബന്ധിപ്പിച്ച് കൃത്യമായ പിശകും സമയവും രേഖപ്പെടുത്തുക.

കൃത്യമായ പ്രാദേശിക പരിശോധന ഹോസ്റ്റ്നെയിം നിലനിർത്തി വിലാസം മാത്രം മാറ്റുന്നു: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ അഭ്യർത്ഥന പൊതു വിലാസത്തിലേക്ക് അയക്കുന്നു, അതേസമയം ശരിയായ സെർവർ നാമം അവതരിപ്പിക്കുന്നു. ഇത് നാമ പരിഹാര പ്രശ്നത്തെ വിവർത്തന പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കുന്നു, ഒരേ നാമം ഒരു കോഫി ഷോപ്പിൽ നിന്ന് പ്രവർത്തിക്കുമ്പോൾ അവ തമ്മിൽ എളുപ്പം കൂട്ടിമറിയുന്നു. ക്ലയന്റ് TCP കണക്ഷനിൽ പരാജയപ്പെടുന്നുണ്ടോ അതോ പിന്നീട് TLS-ൽ ആണോ എന്ന് ശ്രദ്ധിക്കുക, കാരണം ആദ്യത്തേത് വിവർത്തനത്തെയും രണ്ടാമത്തേത് ഐഡന്റിറ്റിയെയും സൂചിപ്പിക്കുന്നു.

പരിശോധന 2: സെർവർ എന്ത് കാണുന്നു എന്ന് വായിക്കുക

ഏറ്റവും ഉപയോഗപ്രദമായ നിരീക്ഷണം സെർവറിന്റെ കാഴ്ചയാണ്. VPN ഹോസ്റ്റിൽ ക്ലയന്റിന്റെ LAN വിലാസത്തിലേക്കും റൂട്ടറിന്റെ LAN വിലാസത്തിലേക്കും ഫിൽട്ടർ ചെയ്ത ക്യാപ്ചർ പ്രവർത്തിപ്പിച്ച ശേഷം പ്രാദേശിക ശ്രമം ആവർത്തിക്കുക. ഒന്നും എത്തുന്നില്ലെങ്കിൽ പാക്കറ്റ് വിവർത്തനത്തെ അതിജീവിച്ചിട്ടില്ല.

കണക്ഷൻ ക്ലയന്റിന്റെ വിലാസത്തിൽ നിന്നല്ല, റൂട്ടറിന്റെ LAN വിലാസത്തിൽ നിന്ന് എത്തുന്നുവെങ്കിൽ ഹെയർപിന്നിംഗ് നടക്കുന്നു, ഉറവിടം വീണ്ടും എഴുതിയിട്ടുണ്ട്. അത് പ്രവർത്തിക്കുന്ന ക്രമീകരണമാണ്, തകരാറല്ല.

പരിശോധന 3: പുറം പാത തൊടാതെ അത് ശരിയാക്കുക

മൂന്ന് പിന്തുണയുള്ള രൂപങ്ങളുണ്ട്, സ്വാധീനത്തിന്റെ വ്യാപ്തി കൂടുന്ന ക്രമത്തിൽ. ഏറ്റവും ഇടുങ്ങിയത് വിഭജിത DNS ആണ്: ആന്തരിക റെക്കോർഡ് പ്രസിദ്ധീകരിച്ച് അതേ സെർവർ നാമം LAN-ലെ ക്ലയന്റുകൾക്ക് ആന്തരിക വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെടാൻ ഇടയാക്കുക, ഇത് പൊതു പാത പൂർണ്ണമായി ഒഴിവാക്കുന്നു. അടുത്തത് റൂട്ടറിന്റെ രേഖപ്പെടുത്തിയ loopback അല്ലെങ്കിൽ reflection ഓപ്ഷൻ ഉണ്ടെങ്കിൽ സജീവമാക്കി ഈ സേവനത്തിന് മാത്രം പ്രയോഗിക്കുകയാണ്. ഏറ്റവും വിശാലമായത് റൂട്ടറിലെ source-NAT നിയമമാണ്, അത് LAN-ൽ നിന്ന് വരുന്ന ട്രാഫിക് സെർവറിലേക്ക് വീണ്ടും എഴുതി മറുപടി റൂട്ടറിലൂടെ തിരികെ വരാൻ ഇടയാക്കുന്നു; Linux റൂട്ടറിൽ അത് സെർവറിന്റെ വിലാസത്തിനും പോർട്ടിനും യോജിക്കുന്ന MASQUERADE നിയമം POSTROUTING ആണ്. മൂന്നും പുറം പാത തൊടാതെ വിടുന്നു, സംരക്ഷിക്കേണ്ട സ്വത്ത് അതാണ്.

പ്രാദേശിക പാതയെ പുറം പാതയോട് സാമ്യമുള്ളതാക്കാൻ ബന്ധമില്ലാത്ത പോർട്ട് ഫോർവേഡിംഗ് വിപുലീകരിക്കരുത്, പ്രശ്നം ഒഴിവാക്കാൻ സേവനം മറ്റൊരു പോർട്ടിലേക്ക് മാറ്റരുത്. രണ്ട് മാറ്റങ്ങളും അകത്തെ ലോകം മാത്രം കാണുന്ന ഒന്ന് ശരിയാക്കാൻ പുറം ലോകത്തിന് എത്താനാകുന്നത് മാറ്റുന്നു.

വിഭജിത DNS-ന് പരാമർശിക്കേണ്ട ഒരു കെണിയുണ്ട്. ഹോസ്റ്റ്നെയിം ഏകപക്ഷീയമായ IP ഉപയോഗിച്ച് മാറ്റുന്നത് ക്ലയന്റ് എന്ത് സാധൂകരിക്കുന്നു എന്നത് മാറ്റുന്നു, അതിനാൽ ആന്തരിക റെക്കോർഡ് ഇപ്പോഴും സർട്ടിഫിക്കറ്റിലെ നാമവുമായി യോജിക്കണം.

പരിശോധന 4: പിന്നീട് രണ്ട് പാതകളും പരിശോധിക്കുക

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

രേഖ ചുരുക്കി സൂക്ഷിക്കുക: ഏത് ക്ലയന്റ് ഏത് വിലാസം ഉപയോഗിച്ചു, സെർവർ എന്ത് കണ്ടു, മൂന്ന് പരിഹാരങ്ങളിൽ ഏതാണ് പ്രയോഗിച്ചത്. RFC 4787-ലെ ഹെയർപിന്നിംഗ് ആവശ്യകതകൾ ഇവിടെ NAT-ൽ നിന്ന് എന്ത് പ്രതീക്ഷിക്കുന്നു എന്നതിനുള്ള റഫറൻസാണ്, ഈ സവിശേഷതയില്ലാത്ത റൂട്ടർ സാധാരണമായി പെരുമാറുന്നത് എന്തുകൊണ്ടെന്ന് അവ വിശദീകരിക്കുന്നു. പുറം ലോകത്തിന് പുനർനിർമ്മിക്കാനാകാത്ത പ്രാദേശിക പരാജയം വിപരീതം തെളിയിക്കുന്നതുവരെ വിവർത്തനത്തിന്റെ ചോദ്യമാണ്, അതിനാൽ അത് അപ്രകാരം പരിശോധിക്കുക.