Linux-ൽ IPsec ഇല്ലാതെ L2TP: xl2tpd, pppd, NAT

സാധാരണ L2TP എന്നത് ഒരു കവറിനുള്ളിലെ PPP മാത്രമാണ്, അതിൽ കൂടുതലൊന്നുമില്ല. അത് നിങ്ങളുടെ ഫ്രെയിമുകൾ കൊണ്ടുപോകുന്നു; അവ എൻക്രിപ്റ്റ് ചെയ്യുന്നില്ല, മറുവശത്ത് ആരിരിക്കുന്നു എന്ന് തെളിയിക്കുന്നുമില്ല, അതുകൊണ്ടാണ് മിക്കവാറും എല്ലാ വിന്യാസവും അതിനടിയിൽ IPsec വയ്ക്കുന്നത്. നഗ്ന പതിപ്പ് പ്രവർത്തിപ്പിക്കാൻ സത്യസന്ധമായ കാരണങ്ങൾ ഇപ്പോഴുമുണ്ട്: ഒരു ലാബ് ബെഞ്ച്, ഒരു മൈഗ്രേഷൻ ഘട്ടം, അല്ലെങ്കിൽ മറ്റൊരു സംരക്ഷിത പാതയ്ക്കുള്ളിലുള്ള ഒരു ലിങ്ക്.

നിങ്ങൾ മുന്നോട്ടുപോകുന്നെങ്കിൽ, ആ മുന്നറിയിപ്പ് ഡിസൈൻ കുറിപ്പിൽ എഴുതി അവിടെത്തന്നെ വയ്ക്കുക. തുടർന്നുള്ളത് Debian, RHEL കുടുംബത്തിലെ ഹോസ്റ്റുകളിൽ ഞാൻ ഉപയോഗിക്കുന്ന പ്രവർത്തന പാതയാണ്: ഏത് ഫയൽ എന്തിന് ഉത്തരവാദിയാണ്, ക്ലാസിക് കുടുക്കം തടയുന്ന MTU, കൂടാതെ ടണൽ അർഥവത്താക്കുന്ന ഫോർവേഡിംഗ് നിയമങ്ങൾ.

മൂന്ന് ഫയലുകൾ ജോലി പങ്കിടുന്നു

xl2tpd നിയന്ത്രണ കണക്ഷൻ അവസാനിപ്പിച്ച് ഓരോ സെഷനും PPP ഡീമണിന് കൈമാറുന്നു, അതിനാൽ കോൺഫിഗറേഷൻ പരസ്പരം ഫയലുകൾ ഒരിക്കലും വായിക്കാത്ത രണ്ട് പ്രോഗ്രാമുകളിലായി വിഭജിച്ചിരിക്കുന്നു. ശ്രോതാവ് /etc/xl2tpd/xl2tpd.conf എന്നതിൽ, [lns default] വിഭാഗത്തിനുള്ളിൽ കഴിയുന്നു; അത് വിലാസ കുളത്തെ ip range കൊണ്ടും, സർവർ ഭാഗത്തെ local ip കൊണ്ടും, PPP-യിലേക്കുള്ള കൈമാറ്റത്തെ pppoptfile കൊണ്ടും പേരിടുന്നു. require authentication = yes ഓണാക്കി, length bit-ഉം flow bit-ഉം സജീവമായി വയ്ക്കുക, ഹോസ്റ്റിൽ മറ്റൊന്നും ഉപയോഗിക്കാത്ത കുളം തിരഞ്ഞെടുക്കുക.

PPP നയം ആ ഓപ്ഷൻ പേരിടുന്ന ഫയലിനുള്ളതാണ്, സാധാരണയായി /etc/ppp/options.xl2tpd: auth, pap, chap, mschap എന്നിവയ്ക്കുള്ള നിരസിക്കലുകൾ, require-mschap-v2, 1460-ന്റെ MTU-ഉം MRU-വും, ലിങ്ക് ഉയർന്നതിന് ശേഷം ക്ലയന്റിന് എത്താവുന്ന DNS വിലാസവും. ക്രെഡൻഷ്യലുകൾ വീണ്ടും മൂന്നാമത്തെ ഫയലാണ്, /etc/ppp/chap-secrets, അവിടെ രണ്ടാമത്തെ ഫീൽഡ് LNS വിഭാഗത്തിന്റെ പേരുമായി പൊരുത്തപ്പെടണം, നാലാമത്തെ ഫീൽഡിന് കുളത്തിൽ നിന്ന് ഒരു നിർദ്ദിഷ്ട വിലാസം പിന്ന് ചെയ്യാം.

ടണൽ എന്തുകൊണ്ട് ബന്ധിപ്പിച്ച് പിന്നീട് നിലയ്ക്കുന്നു

1500 ബൈറ്റിന്റെ Ethernet ഫ്രെയിം സ്വന്തം ഹെഡറുകൾക്ക് ബൈറ്റുകൾ ചെലവിടുന്ന ഒരു പാതയിൽ ഒതുങ്ങില്ല. പുറം IPv4 ഹെഡർ 20 എടുക്കുന്നു, UDP 8, L2TP ഹെഡർ ഏകദേശം 12, ഇത് PPP-യ്ക്കും അതിന്റെ പേലോഡിനും 1460 അവശേഷിപ്പിക്കുന്നു. PPP-യിൽ ആ ചെറിയ സംഖ്യ പ്രഖ്യാപിക്കുന്നതാണ് വലിയ പാക്കറ്റുകൾ കഷണങ്ങളാകുന്നതോ നടുവിൽ എവിടെയോ നിശ്ശബ്ദമായി വീഴുന്നതോ തടയുന്നത്.

യഥാർത്ഥ ട്രാഫിക് എത്തുന്നതുവരെ ആരോഗ്യകരമായി തോന്നുന്ന ടണലാണ് ലക്ഷണം: പിംഗുകളും നിയന്ത്രണ സന്ദേശങ്ങളും കടന്നുപോകുന്നു, ഫയൽ പകർപ്പ് കുടുങ്ങുന്നു, ലോഗിൽ ഒന്നും അത് വിശദീകരിക്കുന്നില്ല. ഇരു അറ്റങ്ങളിലും MTU-ഉം MRU-വും ഒരുമിച്ച് കുറയ്ക്കുക. ക്ലയന്റിനെ മാത്രം ക്രമീകരിച്ചാൽ കടുത്ത കുടുക്കം ഇടയ്ക്കിടെയുള്ളതായി മാറും, അത് രോഗനിർണയത്തിന് കൂടുതൽ മോശമാണ്.

ഒരു പോർട്ട് രണ്ട് സംഭാഷണങ്ങൾ വഹിക്കുന്നു

UDP 1701 പ്രോട്ടോക്കോളിന്റെ രണ്ട് പകുതികൾക്കും താഴെയാണ്, ആ ഒരു വസ്തുത ക്രമീകരണത്തിന്റെ മറ്റേതൊരു ഭാഗത്തെക്കാളും കൂടുതൽ ഫയർവോൾ നിയമങ്ങൾ തകർക്കുന്നു. ആദ്യം നിയന്ത്രണ-കണക്ഷൻ ആരംഭിക്കാനുള്ള അഭ്യർത്ഥനയും അതിന്റെ മറുപടിയും വരുന്നു; തുടർന്നുള്ള സെഷൻ അഭ്യർത്ഥനയും സ്ഥിരീകരണവും ഐഡന്റിഫയർ ജോഡിയിൽ കൂടുതലൊന്നും സ്ഥാപിക്കുന്നില്ല. പിന്നീട് PPP ഏറ്റെടുക്കുന്നു: ലിങ്ക് നിയന്ത്രണം, പിന്നെ പ്രാമാണീകരണം, പിന്നെ വിലാസങ്ങൾ തീരുമാനിക്കാൻ IP നിയന്ത്രണ പ്രോട്ടോക്കോൾ. ഓരോ ഘട്ടത്തിനും ലോഗിൽ സ്വന്തം പദാവലിയുണ്ട്, അവയൊന്നും തന്നെത്താൻ L2TP പരാജയമായി പ്രഖ്യാപിക്കുന്നില്ല.

കൃത്യമായ ആ ക്രമത്തിൽ ഒരു ക്യാപ്ചർ വായിച്ചാൽ ഏത് ഘട്ടം പരാജയപ്പെട്ടുവെന്ന് അറിയാം, PPP പ്രാമാണീകരണ പരാജയം xl2tpd എഡിറ്റ് ചെയ്ത് പരിഹരിക്കില്ല. പങ്കിട്ട പോർട്ട് മറ്റൊരു സാധാരണ പരാജയം വിശദീകരിക്കുന്നു: ഒഴുക്കിന്റെ ആദ്യ പാക്കറ്റുകൾക്ക് മാത്രം അനുമതി നൽകുന്ന നിയമം സെഷൻ ഉണ്ടാകാൻ അനുവദിച്ച് പിന്നീട് കൈമാറ്റം തടയുന്നു. മുഴുവൻ സംഭാഷണത്തിനും 1701, ഇരു ദിശകളിലും അനുവദിക്കുക.

ടണൽ ഉപയോഗപ്രദമാക്കുക: ഫോർവേഡിംഗും NAT-ഉം

സെഷൻ സ്വതന്ത്രമായി സർവറിലേക്ക് മാത്രം എത്തുന്നു. ക്ലയന്റിന്റെ ഇന്റർനെറ്റ് പ്രവേശനത്തിന് ഫോർവേഡിംഗ്, അപ്ലിങ്കിൽ കുളത്തിനുള്ള NAT നിയമം, ലിങ്ക് ഉയർന്നതിന് ശേഷം ക്ലയന്റിന് യഥാർത്ഥത്തിൽ ചോദിക്കാവുന്ന DNS എന്നിവ വേണം. കുളം LAN ശ്രേണിയിൽ നിന്ന് പുറത്തായിരിക്കണം, അല്ലെങ്കിൽ ക്ലയന്റുകൾക്ക് അയച്ച മറുപടികൾ ടണലിലേക്ക് തിരികെ തള്ളുന്നതിന് പകരം പ്രാദേശികമായി എത്തിക്കപ്പെടും.

സർവറിൽ sysctl -w net.ipv4.ip_forward=1 ഉപയോഗിച്ച് ഫോർവേഡിംഗ് ഓണാക്കി, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE ഉപയോഗിച്ച് കുളം വിവർത്തനം ചെയ്ത്, പിന്നീട് -i ppp0 -o eth0-നുള്ള FORWARD നിയമം കൊണ്ട് പുറത്തേക്കുള്ള ടണൽ ട്രാഫിക്കും, കണ്ണാടി നിയമത്തോടൊപ്പം -m state --state RELATED,ESTABLISHED കൊണ്ട് തിരികെ വരുന്ന ട്രാഫിക്കും സ്വീകരിക്കുക. ഈ നിയമങ്ങൾ റീബൂട്ടുകൾക്കിടയിൽ നിലനിർത്തുക, കാരണം അവയില്ലാതെ തിരികെ വരുന്ന സർവർ തകർന്ന L2TP കോൺഫിഗറേഷൻ പോലെത്തന്നെ കാണപ്പെടും.

സർവറിന്റെ സ്വന്തം LAN-ൽ എത്തുന്നത് മറ്റൊരു ജോലിയാണ്: LAN റൂട്ടറിൽ കുളത്തിനുള്ള റിട്ടേൺ റൂട്ട് ചേർക്കുക, അല്ലെങ്കിൽ സർവറിൽ proxy ARP ഉപയോഗിക്കുക. LAN-നുള്ളിലുള്ള എന്തെങ്കിലും ക്ലയന്റുകളെ നേരിട്ട് അഭിസംബോധന ചെയ്യേണ്ടിവരുമ്പോൾ അവരെ NAT-ന് പിന്നിൽ ഒളിപ്പിക്കുന്നത് പിന്നീട് രണ്ടാമത്തെ ഡീബഗ്ഗിംഗ് സെഷൻ ഷെഡ്യൂൾ ചെയ്യുക മാത്രമാണ്.

നഗ്ന സ്റ്റാക്ക് എന്ത് ചെയ്യുന്നില്ല, എങ്ങനെ പരിശോധിക്കാം

ഈ സ്റ്റാക്കിന്റെ ഒരു ഭാഗവും PPP ഫ്രെയിമുകൾ എൻക്രിപ്റ്റ് ചെയ്യുന്നില്ല, അതിലൊന്നും നിങ്ങൾ യഥാർത്ഥത്തിൽ തിരഞ്ഞെടുത്ത സർവറായി ദൂര അറ്റത്തെ പ്രാമാണീകരിക്കുന്നുമില്ല. MS-CHAPv2 കേൾക്കുന്ന ഒരാൾക്ക് ക്രെഡൻഷ്യൽ കൈമാറ്റം സംരക്ഷിക്കുന്നുവെങ്കിലും, പാതയിൽ ഇരിക്കുന്ന ആക്രമണകാരിക്ക് ഇപ്പോഴും സെഷനിൽ ഇടപെടാം. Windows-ന്റെ സ്വദേശീയ ക്ലയന്റ് L2TP IPsec-മായി മാത്രമാണ് നൽകുന്നത്, അതിനാൽ Linux, റൂട്ടർ ഫേംവെയർ, മൂന്നാം കക്ഷി ക്ലയന്റുകൾ എന്നിവയെ നിങ്ങളുടെ പങ്കാളികളായി കണക്കാക്കുക. നഗ്ന കോൺഫിഗറേഷനെ രോഗനിർണയത്തിന്റെ പടവായി കാണുക, ഒരിക്കലും നിർത്താനുള്ള സ്ഥലമായി അല്ല.

നിശ്ചിത ക്രമത്തിൽ പരിശോധിക്കുക: xl2tpd -D മുൻപിൽ പ്രവർത്തിപ്പിക്കുക, PPP ഘട്ടത്തിനായി ജേണൽ നിരീക്ഷിക്കുക, ഇരു അറ്റങ്ങളിലും ip addr-ൽ നിന്ന് അനുവദിച്ച വിലാസം വായിക്കുക, പിന്നീട് സെഷൻ ഉയർന്നതിന് ശേഷം ഡാറ്റ ഒഴുകുന്നുവെന്ന് സ്ഥിരീകരിക്കാൻ UDP 1701 ക്യാപ്ചർ ചെയ്യുക. നാലും ഒത്തുവന്നിട്ടും ട്രാഫിക് പരാജയപ്പെടുന്നെങ്കിൽ, കുറ്റം റൂട്ടിംഗിലോ NAT-ലോ MTU-വിലോ ആണ്, L2TP-യിൽ തന്നെയല്ല.