NAT വഴി L2TP/IPsec: യഥാർത്ഥത്തിൽ എന്ത് തകരുന്നു, എന്തുകൊണ്ട്
NAT traversal ESP-യെ UDP-യിലേക്ക് നീക്കുന്നു, മാപ്പിംഗ്, ഫയർവാൾ, ഓപ്പറേറ്റർ എന്നിവ ഓരോന്നും വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു. ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഘട്ടം കണ്ടെത്തുക.
NAT L2TP/IPsec തകർക്കുന്നു എന്ന വാദം പകുതി ശരിയാണ്, അതിനാൽ ഉപയോഗശൂന്യമാണ്. വിലാസ പരിഭാഷണം സാധാരണമാണ്, NAT traversal അതിനെ അതിജീവിക്കാനാണ് ഉള്ളത്, ഒപ്പം ദിവസേന ലക്ഷക്കണക്കിന് ക്ലയന്റുകൾ റൗട്ടറിന് പിന്നിൽ നിന്ന് കണക്റ്റ് ചെയ്യുന്നു. തകരുന്നത് ഒരു നിർദ്ദിഷ്ട കൈമാറ്റത്തിന്റെ ഒരു നിർദ്ദിഷ്ട ഘട്ടമാണ്: IKE-ക്ക് ഒരിക്കലും മറുപടി ലഭിക്കുന്നില്ല, ഒരു പ്രോട്ടോക്കോളിന് മാത്രം അനുവാദം നൽകുന്ന നയം എൻകാപ്സുലേറ്റ് ചെയ്ത ടണൽ വലിച്ചെറിയുന്നു, അല്ലെങ്കിൽ ടണൽ നിഷ്ക്രിയമായിരിക്കുമ്പോൾ മാപ്പിംഗ് കാലഹരണപ്പെടുന്നു. ഏത് ഘട്ടത്തിലാണ് നിങ്ങളെന്ന് അറിഞ്ഞാൽ, പരിഹാരം സാധാരണയായി ഒരു നിയമമോ keepalive-ഉം ആണ്, പുതിയ VPN ഡിസൈൻ അല്ല.
മിഥ്യയാണ് തെറ്റായ ചോദ്യം
ഉപയോഗപ്രദമായ ചോദ്യം “NAT ഇത് തകർക്കുന്നുണ്ടോ” എന്നല്ല, മറിച്ച് “കൈമാറ്റത്തിന്റെ ഏത് ഭാഗമാണ് പരിഭാഷപ്പെടുത്തുന്നത്, പരിഭാഷപ്പെടുത്തുന്ന ഉപകരണം അതിനോട് എന്ത് ചെയ്യുന്നു” എന്നാണ്. L2TP/IPsec പാളികളുള്ള പ്രോട്ടോക്കോളാണ്: IKE ചർച്ച ചെയ്യുന്നു, ESP സംരക്ഷിക്കുന്നു, ഒപ്പം L2TP ആ സംരക്ഷണത്തിനുള്ളിൽ PPP വഹിക്കുന്നു. വിലാസ പരിഭാഷണം ഓരോ പാളിയെയും വ്യത്യസ്തമായി ബാധിക്കുന്നു, പിശക് ഡയലോഗിന് പകരം ചർച്ചയുടെ ഘട്ടം നോക്കിയാൽ പരാജയ ലക്ഷണങ്ങൾ വേർതിരിച്ചറിയാം.
വെബ് വിജയകരമായി ബ്രൗസ് ചെയ്യുന്ന റൗട്ടർ സ്രോതസ്സ് പോർട്ട് പരിഭാഷണത്തോടെ TCP പ്രവർത്തിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു. UDP 500, UDP 4500 അല്ലെങ്കിൽ പ്രോട്ടോക്കോൾ 50-നെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല, ഈ വിന്യാസം ആ മൂന്നിനെയാണ് ആശ്രയിക്കുന്നത്.
ഘട്ടം 1: IKE-ക്ക് എങ്ങനെയും മറുപടി ലഭിക്കണം
ആദ്യ കൈമാറ്റം UDP 500-ൽ പ്രതികരിക്കുന്നയാളിലേക്ക് പോകുന്നു. മറുപടി തിരികെ വന്നില്ലെങ്കിൽ, ബാക്കിയൊന്നും പ്രധാനമല്ല: മുൻകൂട്ടി പങ്കിട്ട കീയും നിർദ്ദേശവും ക്രെഡൻഷ്യലുകളും വായിക്കപ്പെടാതെ കിടക്കും. ക്ലയന്റിന്റെ ടൈംഔട്ടിൽ നിന്ന് അനുമാനിക്കാതെ അഭ്യർത്ഥനയും മറുപടിയും നിരീക്ഷിക്കുക:
sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas
മറുപടിയില്ലാത്ത അഭ്യർത്ഥന സാധാരണയായി ഫയർവാളോ മുകളിലത്തെ ഓപ്പറേറ്ററോ പാക്കറ്റ് വലിച്ചെറിയുന്നു എന്നാണ് അർത്ഥമാക്കുന്നത്, സർവർ അത് നിരസിച്ചു എന്നല്ല. ഒരു നിർദ്ദേശമോ സർട്ടിഫിക്കറ്റ് പ്രശ്നമോ പേരെടുത്ത് പറയുന്ന അറിയിപ്പ് പേലോഡുള്ള മറുപടി എന്നാൽ പാക്കറ്റുകൾ എത്തി, ഉള്ളടക്കം കാരണം ചർച്ച പരാജയപ്പെട്ടു എന്നാണ്, അത് തികച്ചും വ്യത്യസ്തമായ ഒരു അറ്റകുറ്റപ്പണിയാണ്.
ഇരു കക്ഷികളും പരിഭാഷണത്തിന് പിന്നിലാണെങ്കിൽ, ആരംഭിക്കുന്നയാൾക്ക് പ്രതികരിക്കുന്നയാളിലേക്ക് എത്തിയാൽ മതി, അതിനാൽ ഭൂരിഭാഗം ക്ലയന്റ് വശ വിന്യാസങ്ങളും ഘട്ടം 1 മുതൽ പ്രവർത്തിക്കുന്നു. സർവർ വശത്തെ ഹോസ്റ്റിംഗ് ആണ് ഇൻബൗണ്ട് പ്രശ്നം തുടങ്ങുന്നിടം, അതുകൊണ്ടാണ് ഈ രണ്ട് സാഹചര്യങ്ങളും ഒന്നായി ചർച്ച ചെയ്യരുതാത്തത്.
ഘട്ടം 2: എൻകാപ്സുലേഷൻ ഫയർവാൾ കാണുന്നതിനെ മാറ്റുന്നു
ESP ഒരു IP പ്രോട്ടോക്കോളാണ്, TCP അല്ലെങ്കിൽ UDP പോർട്ടല്ല, സാധാരണ പോർട്ട് വിലാസ പരിഭാഷണത്തിൽ വീണ്ടും എഴുതാൻ പോർട്ട് ഫീൽഡില്ല. അതുകൊണ്ടാണ് NAT traversal സംരക്ഷിത പേലോഡിനെ UDP 4500-ലേക്ക് നീക്കുന്നത്: എൻകാപ്സുലേഷൻ പരിഭാഷപ്പെടുത്തുന്ന ഉപകരണത്തിന് പരിഭാഷപ്പെടുത്താൻ അറിയാവുന്ന ഒന്ന് നൽകുന്നു. അത് സംഭവിച്ചാൽ, UDP 500-ന് മാത്രം എഴുതിയ ഫയർവാൾ നിയമം ചർച്ച അനുവദിക്കുകയും ടണൽ വലിച്ചെറിയുകയും ചെയ്യും, ഇത് ലോഗിൽ വിജയകരമായ ഘട്ടം 1-ഉം ഒരു ട്രാഫിക്കും ഇല്ലെന്നും കാണിക്കുന്ന ആശയക്കുഴപ്പമുള്ള ഫലം നൽകുന്നു.
NAT കണ്ടെത്തിയതിന് ശേഷം IKE കൈമാറ്റം തന്നെ UDP 4500-ലേക്ക് നീങ്ങാം, ഇത് 500 മാത്രം അനുവദിച്ചവരെ അത്ഭുതപ്പെടുത്തുന്നു. പാതയിൽ രണ്ട് പോർട്ടുകളും രണ്ട് ദിശകളിലും അനുവദിക്കുക, സ്റ്റേറ്റ്ഫുൾ ഫയർവാൾ ട്രാഫിക് കാണുന്നിടത്തോളം മാത്രമേ ഫ്ലോ നിലനിർത്തൂ എന്ന് ഓർക്കുക.
പ്രോട്ടോക്കോൾ 50 പരിഭാഷണമില്ലാത്ത പാതകളിലും ഇടനില പെട്ടി അത് അനുവദിക്കാൻ കോൺഫിഗർ ചെയ്ത പാതകളിലും ഇപ്പോഴും പ്രധാനമാണ്. ഒഴിവാക്കലിലൂടെ രോഗനിർണയം ചെയ്യുന്നുവെങ്കിൽ, നിയമങ്ങൾ കൂട്ടത്തോടെ ചേർക്കുന്നതിന് പകരം സിദ്ധാന്തം ഓഫ് ചെയ്യുക: 500, 4500, ESP അനുവദിക്കുക, ടണൽ ഉയരുന്നുവെന്ന് ഉറപ്പാക്കുക, പിന്നീട് അനാവശ്യമെന്ന് തെളിഞ്ഞത് നീക്കുക. ആർക്കും വിശദീകരിക്കാനാവാത്ത നിയമം അടുത്ത തടസ്സത്തിന്റെ കാരണമാകുമ്പോൾ ആരും നീക്കാത്ത നിയമമാണ്. ചുരുക്കൽ മാറ്റരേഖയിൽ അത് ശരിയാക്കിയ ഘട്ടത്തോടൊപ്പം എഴുതുക, അടുത്ത എഞ്ചിനീയർ അതേ വിരൽനിയമത്തിൽ നിന്നല്ല, നിങ്ങളുടെ തെളിവുകളിൽ നിന്ന് തുടങ്ങാൻ.
ഘട്ടം 3: മാപ്പിംഗ് കാലഹരണപ്പെടുന്നു, ടണൽ മരിക്കുന്നു
പരിഭാഷപ്പെടുത്തുന്ന ഉപകരണം കൈമാറുന്ന ഫ്ലോകൾക്ക് അവസ്ഥ സൂക്ഷിക്കുന്നു, ആ അവസ്ഥയ്ക്ക് ആയുസ്സുണ്ട്. ആരും ഉപയോഗിക്കാത്തപ്പോൾ L2TP/IPsec ടണൽ കുറച്ച് ട്രാഫിക്ക് മാത്രം വഹിക്കുന്നു, അതിനാൽ നിഷ്ക്രിയ ടണൽ അതിന്റെ മാപ്പിംഗിനെ അതിജീവിച്ച് തിരിച്ചുവരുന്ന ട്രാഫിക്ക് സ്വീകരിക്കുന്നത് നിർത്താം. ക്ലയന്റ് കണക്റ്റ് ചെയ്തിരിക്കുന്നു എന്ന് ഉറച്ചു വിശ്വസിക്കുന്നു, സർവർ ഒന്നും കാണുന്നില്ല, ആദ്യ ലക്ഷണം സാധാരണയായി VPN പിശകല്ല, ആപ്ലിക്കേഷൻ ടൈംഔട്ടാണ്.
ഡെഡ് പിയർ കണ്ടെത്തലും NAT keepalive-ഉം ഇതിനാണ്, രണ്ട് അറ്റങ്ങളും അവ അയക്കാൻ തയ്യാറായിരിക്കണം. നിങ്ങളുടെ സർവർ പരിഭാഷണത്തിന് പിന്നിലാണെങ്കിൽ, Windows വശത്തെ ആവശ്യകത സർവറിന് സ്വന്തം ഔട്ട്ബൗണ്ട് പാക്കറ്റുകൾക്ക് UDP എൻകാപ്സുലേഷൻ അനുമാനിക്കാൻ പ്രേരിപ്പിക്കുന്ന രേഖപ്പെടുത്തിയ രജിസ്ട്രി ക്രമീകരണമാണ്; അതില്ലാതെ പ്രതികരിക്കുന്നയാൾ പരിഭാഷപ്പെടുത്തുന്ന ഉപകരണത്തിന് തിരികെ മാപ്പ് ചെയ്യാനാവാത്ത ESP അയക്കുന്നു. ഇത് സർവർ കോൺഫിഗറേഷന്റെ കാര്യമാണ്, ക്ലയന്റിന്റേതല്ല.
WAN വിലാസം മാറുന്നത് മറ്റൊരു ദിശയിൽ നിന്ന് അതേ ഫലം നൽകുന്നു: പുതിയ വിലാസത്തിന് ചുറ്റും മാപ്പിംഗ് പുനർനിർമ്മിക്കുന്നു, പഴയ സുരക്ഷാ അസോസിയേഷൻ ഇപ്പോൾ നിലവിലില്ലാത്ത ഒരു ട്യൂപ്പിളിലേക്ക് ചൂണ്ടുന്നു. വീണ്ടും കണക്റ്റ് ചെയ്യുന്ന സ്വഭാവം ക്ലയന്റ് നടപ്പാക്കലിന്റേതാണ്, അതുകൊണ്ടാണ് “റൗട്ടർ റീബൂട്ടിന് ശേഷം വീണ്ടും കണക്റ്റ് ചെയ്യുക” ഒരു ക്ലയന്റിൽ പ്രവർത്തിക്കുന്നതും മറ്റൊന്നിൽ കൈകൊണ്ട് ടോഗിൾ ആവശ്യമാകുന്നതും.
കാരിയർ-ഗ്രേഡ് NAT-ന് പിന്നിൽ ഹോസ്റ്റിംഗ് മറ്റൊരു പ്രശ്നമാണ്
വീട്ടിൽ L2TP/IPsec സർവർ ഹോസ്റ്റ് ചെയ്ത് പുറത്തുനിന്ന് എത്താൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ആവശ്യകത ആവശ്യപ്പെടാത്ത ഇൻബൗണ്ട് എത്തിച്ചേരൽ സാധ്യതയാണ്, അതല്ല NAT traversal നൽകുന്നത്. നിങ്ങളുടെ റൗട്ടറിന് മുമ്പിൽ കാരിയർ-ഗ്രേഡ് NAT ഉണ്ടെങ്കിൽ പൊതു വിലാസം പങ്കിടുന്നതും മാപ്പിംഗ് ഔട്ട്ബൗണ്ട് മാത്രമായതും കാരണം നിങ്ങളെ എത്താവുന്നതാക്കാൻ ഫോർവേഡ് ചെയ്യാവുന്ന ഒരു പോർട്ടും ഇല്ല.
ഒരു IPsec പാസ്-ത്രൂ ചെക്ക്ബോക്സും ഇത് മാറ്റുന്നില്ല, ഒരു ക്ലയന്റ് കോൺഫിഗറേഷനും ഇത് നികത്തുന്നില്ല. പിന്തുണയ്ക്കുന്ന മറുപടികൾ യഥാർത്ഥത്തിൽ എത്താവുന്ന വിലാസം, ഹോസ്റ്റ് ചെയ്ത എൻഡ്പോയിന്റ്, അല്ലെങ്കിൽ ഓരോ പങ്കാളിയും ഔട്ട്ബൗണ്ട് കണക്ഷൻ ഉണ്ടാക്കുന്ന ആർക്കിടെക്ചർ എന്നിവയാണ്. UDP എൻകാപ്സുലേഷൻ സ്പെസിഫിക്കേഷൻ നിലവിലുള്ള ഫ്ലോകൾക്ക് പരിഭാഷണ പ്രശ്നം പരിഹരിക്കുന്നു; കാരിയർ നൽകാത്തിടത്ത് അത് ഇൻബൗണ്ട് പാത സൃഷ്ടിക്കുന്നില്ല.
അതിനാൽ ഊഹിക്കുന്നതിന് പകരം നെറ്റ്വർക്കുകൾ താരതമ്യം ചെയ്യുക. അതേ ഉപകരണവും പ്രൊഫൈലും മറ്റൊരു അനുവദനീയ നെറ്റ്വർക്കിലേക്ക് കൊണ്ടുപോയി അവിടെ ഏത് ഘട്ടം പരാജയപ്പെടുന്നു എന്ന് നോക്കുക. മറ്റെവിടെയെങ്കിലും പ്രവർത്തിക്കുന്നുവെങ്കിൽ വ്യത്യാസം പാതയിലാണ്, അത് മുഴുവൻ കോൺഫിഗറേഷനും പകരം മുകളിലെ മൂന്ന് ഘട്ടങ്ങളിലേക്ക് തിരച്ചിൽ ചുരുക്കുന്നു.