L2TP/IPsec-ന് IPsec-നു പുറമേ UDP 1701 എന്തിന് വേണം

IKE-ഉം ESP-ഉം അനുവദിച്ച് UDP 1701 അനുവദിക്കാത്ത ഫയർവാളുകൾ ക്രെഡൻഷ്യൽ പ്രശ്നം പോലെ തോന്നിക്കുന്ന രീതിയിൽ L2TP കണക്ഷനുകൾ തകർക്കുന്നു. കാരണം L2TP ആദ്യത്തിനുള്ളിൽ സഞ്ചരിക്കുന്ന രണ്ടാമത്തെ പ്രോട്ടോക്കോളാണ് എന്നതാണ്. IPsec കൈമാറ്റം വഹിക്കുകയും സാക്ഷ്യപ്പെടുത്തുകയും ചെയ്യുന്നു, L2TP അതിന്റെ സ്വന്തം ടണൽ UDP 1701-ന് മുകളിൽ പ്രവർത്തിപ്പിക്കുന്നു, അത് പ്രാദേശിക സ്റ്റാക്ക് ഇപ്പോഴും എത്തിക്കണം. ഓരോ ഹെഡറും എവിടെ പ്രത്യക്ഷപ്പെടുന്നു എന്ന് അറിയുന്നത് ഏത് ഉപകരണത്തിന് ഏത് നിയമം വേണമെന്ന് വിശദീകരിക്കുന്നു.

രണ്ട് പ്രോട്ടോക്കോളുകൾ, രണ്ട് പോർട്ട് സെറ്റുകൾ

L2TP/IPsec കണക്ഷൻ UDP 500-ൽ IKE, വിവർത്തനം ഉള്ളിടത്ത് UDP 4500-ൽ NAT കടന്നുപോകൽ, ഇല്ലാത്തിടത്ത് IP പ്രോട്ടോക്കോൾ 50 ആയി ESP എന്നിവ ഉപയോഗിക്കുന്നു. L2TP തന്നെ UDP 1701-ലെ ടണൽ പ്രോട്ടോക്കോളാണ്, IPsec ഇരയെ സാക്ഷ്യപ്പെടുത്തിയ ശേഷമാണ് അത് പ്രവർത്തിക്കുന്നത്. രണ്ട് പകുതികളും വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു, അവയെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്യുന്ന ലോഗ് വരികൾ വ്യത്യസ്ത ഘടകങ്ങളിൽ നിന്ന് വരുന്നു. ആദ്യ പകുതി മാത്രം ഉൾക്കൊള്ളുന്ന നിയമ സെറ്റ് ചർച്ച ചെയ്ത് പിന്നീട് ടണൽ ഘട്ടത്തിൽ ചാകുന്ന കണക്ഷൻ ഉണ്ടാക്കുന്നു.

പോർട്ട് നമ്പറുകൾ ഗതാഗത അന്ത്യബിന്ദുക്കളെ വിവരിക്കുന്നു, ESP പോർട്ടേ അല്ല. അതുകൊണ്ടാണ് TCP, UDP നിയമങ്ങൾ മാത്രം നൽകുന്ന ഫയർവാൾ ഇന്റർഫേസിന് പൂർണ്ണ IPsec നയം പ്രകടിപ്പിക്കാനാകാത്തത്. പ്രോട്ടോക്കോൾ 50 പ്രോട്ടോക്കോളായി അനുവദിക്കണം, UDP മാത്രം പരാമർശിക്കുന്ന നിയമം അതുമായി ഒരിക്കലും ഒത്തുപോകില്ല.

ആവരണമാണ് പോർട്ടിനെ വിശദീകരിക്കുന്നത്

വയറിൽ, L2TP/IPsec കണക്ഷൻ സാധാരണയായി 500-ൽ IKE-ഉം 4500-ൽ പൊതിഞ്ഞ ESP-ഉം കാണിക്കുന്നു. UDP 1701 ഹെഡർ സംരക്ഷിത പേലോഡിനുള്ളിൽ ഇരിക്കുന്നു, അതിനാൽ പുറം ഇന്റർഫേസിലെ ക്യാപ്ചർ അത് കാണിക്കുന്നില്ല. പ്രാദേശിക ഹോസ്റ്റ് ആ ഡാറ്റാഗ്രാം L2TP ഡീമണിലേക്ക് ഇപ്പോഴും എത്തിക്കണം, എത്തിക്കൽ ഡീകാപ്സുലേഷനു ശേഷമാണ് സംഭവിക്കുന്നത്. അതിനാൽ 1701 നിയമം എൻഡ്പോയിന്റിന്റെ സ്വന്തം ഫയർവാളിനാണ്, ഒരു ഇടനില ഉപകരണവും പോർട്ട് ഒരിക്കലും കാണുന്നില്ലെങ്കിലും.

പ്രോസസ്സിംഗ് ക്രമം ആശയക്കുഴപ്പത്തിന്റെ ഭൂരിഭാഗവും വിശദീകരിക്കുന്നു. സ്റ്റാക്ക് ഹോസ്റ്റ് ഫിൽട്ടറിന് മുമ്പ് IPsec നയം പ്രയോഗിച്ചാൽ, ഡീകാപ്സുലേറ്റ് ചെയ്ത L2TP പാക്കറ്റ് UDP 1701 ആയി പൊരുത്തപ്പെടുന്നു; ക്രമം തലതിരിഞ്ഞാൽ പുറം പോർട്ടുകളാണ് നിയമ സെറ്റ് കാണുന്നത്. രണ്ട് സ്വഭാവങ്ങളും പ്രായോഗികമായി നിലവിലുണ്ട്, അതിനാൽ ഒരേ നിയമ സെറ്റ് ഒരു പ്ലാറ്റ്ഫോമിൽ പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ പരാജയപ്പെടുകയും ചെയ്യുന്നതായി തോന്നുന്നു.

ക്രമത്തിൽ പാത പരിശോധിക്കുക

ആദ്യം പുറം ഇന്റർഫേസിൽ ക്യാപ്ചർ ചെയ്ത് IKE-ഉം പൊതിഞ്ഞ ESP-ഉം ഇരുവശത്തേക്കും നീങ്ങുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. പിന്നീട് ഡീകാപ്സുലേറ്റ് ചെയ്ത ട്രാഫിക്കിനായി പ്രാദേശിക ഫയർവാൾ കൗണ്ടറുകൾ പരിശോധിക്കുക. ക്രമം പ്രധാനമാണ്, കാരണം ഒന്നും കാണിക്കാത്ത ക്യാപ്ചർ എന്നാൽ പ്രശ്നം ഹോസ്റ്റിന് മുകളിലാണ് എന്നാണ്.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

ക്യാപ്ചർ കൈമാറ്റത്തിന്റെ ആദ്യ പകുതി സ്ഥിരീകരിക്കുകയും ഇര പ്രതികരിക്കുന്നുണ്ടോ എന്ന് കാണിക്കുകയും ചെയ്യുന്നു. നിയമ പട്ടിക 1701 നിയമം ഉണ്ടോ എന്നും ഏതെങ്കിലും ഡ്രോപ്പ് നയവുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ എവിടെ നിൽക്കുന്നു എന്നും കാണിക്കുന്നു. സോക്കറ്റ് പട്ടിക L2TP ഡീമൺ ബന്ധിപ്പിച്ച് കേൾക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുന്നു, ഇത് ഒരിക്കലും ആരംഭിക്കാത്ത സേവനത്തെ ഒഴിവാക്കുന്നു. നിയമം മാറ്റുന്നതിന് മുമ്പ് മൂന്നും വായിക്കുക, കാരണം കേൾവിക്കാരൻ ഇല്ലാത്തതും ഫിൽട്ടർ ചെയ്ത പോർട്ടും ഉപയോക്താവിൽ നിന്ന് ഒരേ പരാതി ഉണ്ടാക്കുന്നു.

പോർട്ട് സ്കാൻ കാണിക്കാൻ കഴിയാത്തത്

ശരിയായി കോൺഫിഗർ ചെയ്ത സെർവറിനെതിരായ UDP 1701-ന്റെ പുറം സ്കാൻ സാധാരണയായി ഒന്നും റിപ്പോർട്ട് ചെയ്യുന്നില്ല, അതാണ് പ്രതീക്ഷിത ഫലം. പോർട്ട് ഇന്റർനെറ്റിലേക്ക് തുറന്നിട്ടില്ല; IPsec ഇരയെ സാക്ഷ്യപ്പെടുത്തിയ ശേഷം മാത്രമേ അതിൽ എത്താനാകൂ. അടഞ്ഞ ഫലത്തെ തകരാറായി കാണുന്നത് അടഞ്ഞിരിക്കേണ്ട പോർട്ട് തുറക്കാൻ ഇടയാക്കുന്നു. ആപ്ലിക്കേഷൻ ട്രാഫിക് കാണാൻ കഴിയാത്തത്രയും ടണലിനുള്ളിൽ കാണാൻ സ്കാനിന് കഴിയില്ല.

പകരം യഥാർത്ഥ ക്ലയന്റ് ഉപയോഗിച്ച് പരീക്ഷിക്കുക, അത് ഏത് ഘട്ടത്തിൽ എത്തുന്നു എന്ന് വായിക്കുക. കണക്ഷൻ ചർച്ച ചെയ്ത് പിന്നീട് നിലയ്ക്കുന്നുവെങ്കിൽ L2TP ഡീമോണോ പ്രാദേശിക ഫിൽട്ടറോ സംശയിക്കപ്പെടുന്നു; ഒരിക്കലും ചർച്ച ചെയ്യുന്നില്ലെങ്കിൽ പുറം പോർട്ടുകളാണ് കുറ്റക്കാർ. ആ ഒരു വിഭജനം ഏത് നിയമം ചേർക്കണം എന്ന ഊഹത്തിന്റെ ഭൂരിഭാഗവും ഒഴിവാക്കുന്നു, പ്രോട്ടോക്കോൾ പാളികൾ അതിനെ രഹസ്യാത്മകത്തിനു പകരം പ്രവചനീയമാക്കുന്നു.