വീട്ടിലെ റൂട്ടറിന് പിന്നിലെ PPTP സെർവർ: ആദ്യം 1723-ഉം GRE-യും ശരിയാക്കുക

വീട്ടിലെ റൂട്ടറിന് പിന്നിൽ PPTP രണ്ട് ബന്ധമില്ലാത്ത വിധങ്ങളിൽ പരാജയപ്പെടുന്നു, അവ തമ്മിൽ കൂട്ടിക്കുഴച്ചാൽ ഒരു സായാഹ്നം മുഴുവൻ നഷ്ടമാകും. ഒരു പരാജയം ഫോർവേഡിംഗിലെ വിടവാണ്: റൂട്ടർ TCP 1723 കടത്തിവിടുന്നു, IP പ്രോട്ടോക്കോൾ 47 ഉപേക്ഷിക്കുന്നു, അതിനാൽ ക്ലയന്റ് പിശക് 619-ൽ നിൽക്കുന്നു. മറ്റൊന്ന് വലിപ്പത്തിലെ പ്രശ്നമാണ്: ടണൽ ഉയരുന്നു, പ്രാമാണീകരിക്കുന്നു, പിന്നീട് പൂർണ വലിപ്പത്തിലുള്ള പാക്കറ്റ് കടക്കേണ്ടിവരുമ്പോൾ മരവിക്കുന്നു. ഇവയിൽ ഏതാണ് നിങ്ങൾക്കുള്ളതെന്ന് കണ്ടെത്തുന്നതാണ് ആദ്യത്തെ യഥാർത്ഥ ചുവട്; ബാക്കിയുള്ളത് നിങ്ങളുടെ റൂട്ടർ എന്ത് പ്രകടിപ്പിക്കാൻ കഴിയും എന്നതിനെ താരതമ്യം ചെയ്യുന്നു, ഏത് ബ്രാൻഡിനാണ് മെച്ചം എന്നല്ല.

രണ്ട് വാഹകർ, അവയിൽ ഒന്നിന് മാത്രം പോർട്ടുണ്ട്

PPTP രണ്ട് വാഹകരായി പിരിയുന്നു: TCP 1723-ലെ നിയന്ത്രണ ബന്ധം, വിപുലീകൃത GRE-യിൽ പൊതിഞ്ഞ PPP ഫ്രെയിമുകൾ, അതായത് IP പ്രോട്ടോക്കോൾ 47. GRE-യ്ക്ക് പോർട്ട് നമ്പറില്ല, അതിനാൽ പോർട്ട് 1723 ഫോർവേഡ് എന്ന് എഴുതിയ നിയമത്തിന് അത് ഉൾക്കൊള്ളാൻ കഴിയില്ല, വെബ് ഇന്റർഫേസ് ആ ഫീൽഡിന് എന്ത് പേരിട്ടാലും. ഗാർഹിക റൂട്ടർ സാധാരണയായി പ്രോട്ടോക്കോൾ നിയമത്തിന് പകരം PPTP പാസ്ത്രൂ എന്ന ചെക്ക്ബോക്സ് നൽകുന്നു, ആ ചെക്ക്ബോക്സ് രണ്ട് ജോലി ചെയ്യുന്നു: ഫയർവാളിലൂടെ പ്രോട്ടോക്കോൾ 47 കടത്തിവിടുന്നു, NAT-ന് GRE പ്രവാഹം പിന്തുടരാൻ പഠിപ്പിക്കുന്നു. ലിനക്സ് റൂട്ടറിൽ ഈ ജോലികൾ വേർതിരിച്ച മൊഡ്യൂളുകളും വേർതിരിച്ച നിയമങ്ങളുമാണ്, അതിനാൽ പകുതി കോൺഫിഗർ ചെയ്ത പാസ്ത്രൂവും പ്രവർത്തിക്കുന്ന നിയന്ത്രണ ചാനൽ നൽകുന്നു. എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഏത് പകുതിയാണ് ഉള്ളതെന്ന് കണ്ടെത്തുക.

സെർവറിന്റെ സ്വന്തം ഫയർവാളും റൂട്ടറിന്റെ വിലാസത്തിൽ നിന്ന് പ്രോട്ടോക്കോൾ 47 അനുവദിക്കണം. 1723/tcp മാത്രം സ്വീകരിക്കുന്ന ഹോസ്റ്റ് ഫയർവാൾ LAN-നുള്ളിൽ നിന്ന് പിശക് 619 പുനരുൽപ്പാദിപ്പിക്കുന്നു, അതിനാൽ തകർന്ന ഫോർവേഡിംഗും തകർന്ന ഹോസ്റ്റ് നിയമവും ഒരേപോലെ തോന്നും.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

മൊഡ്യൂളുകൾ ഇല്ലെങ്കിൽ sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre ഉപയോഗിച്ച് ലോഡ് ചെയ്ത് ലോഡിംഗ് സ്ഥിരമാക്കുക, കാരണം സഹായിയെ മറക്കുന്ന റീബൂട്ട് പ്രവർത്തിക്കുന്ന ടണലിനെ വീണ്ടും പിശക് 619 ആക്കുന്നു. ഫോർവേഡിംഗ് നിയമം പ്രോട്ടോക്കോൾ 47 സെർവറിന്റെ വിലാസത്തിലേക്ക് മാത്രം സ്വീകരിക്കണം, മുഴുവൻ LAN അല്ല. RFC 2637 നിർവചനം നിയന്ത്രണ, ഡാറ്റ പാതകളെ വേർതിരിക്കുന്നു, അതിനാൽ ഒരൊറ്റ പോർട്ട് ഫോർവേഡ് സ്ക്രീനും PPTP പൂർണമായി വിവരിക്കുന്നില്ല.

പാസ്ത്രൂ ചെക്ക്ബോക്സോ വ്യക്തമായ പ്രോട്ടോക്കോൾ നിയമമോ

ഫയർവാൾ മാത്രം തുറക്കുന്ന പാസ്ത്രൂ ചെക്ക്ബോക്സ് കോൾ ഐഡന്റിഫയറുകൾ വീണ്ടും എഴുതുന്ന ALG-യെക്കാൾ ശരിയോട് അടുത്താണ്. ഫയർവാൾ പകുതി പ്രവചനീയമാണ്, കാരണം പ്രോട്ടോക്കോൾ 47 ഒന്നുകിൽ സ്വീകരിക്കുന്നു അല്ലെങ്കിൽ ഉപേക്ഷിക്കുന്നു, കൗണ്ടറുകൾ ഏതെന്ന് പറയുന്നു. വീണ്ടും എഴുത്തിന്റെ പകുതിയാണ് നിർമ്മാതാക്കൾ വ്യത്യാസപ്പെടുന്ന സ്ഥലം, കാരണം PPTP-യുടെ കോൾ ഐഡന്റിഫയറുകൾ ഓരോ ടണലിനുമാണ്, അവ തിരുത്തുന്ന NAT അത് തൊടുന്ന ഓരോ കോളും പിന്തുടരണം. ഒരു ക്ലയന്റ് ബന്ധിപ്പിക്കുകയും രണ്ടെണ്ണം ബന്ധിപ്പിക്കാതിരിക്കുകയും ചെയ്യുമ്പോൾ ALG ആണ് ആദ്യ സംശയിതൻ.

1723-നുള്ള ലക്ഷ്യ NAT നിയമത്തിനും ഉടമസ്ഥത പ്രശ്നമുണ്ട്. പഴയ നിയമം ഇപ്പോഴും സെർവർ നിർത്തിയ ഹോസ്റ്റിലേക്ക് 1723 അയച്ചാൽ പാക്കറ്റുകൾ അടച്ച പോർട്ടിൽ വീഴുന്നു, റൂട്ടറിന്റെ സ്വന്തം PPTP സേവനം ഉത്തരം നൽകുന്നത് നിർത്തുന്നു, ഇത് ഫയർവാൾ പരാജയമായി വായിക്കപ്പെടുന്നു പക്ഷേ യഥാർത്ഥത്തിൽ പഴയ ലക്ഷ്യമാണ്. രണ്ടാമത്തേത് ചേർക്കുന്നതിന് മുൻപ് നിയമവും അതിന്റെ ലക്ഷ്യവും വായിക്കുക. PPTP സ്വയം അവസാനിപ്പിക്കുന്ന റൂട്ടറുകളിൽ WAN നിയമം ഉൾനിർമ്മിത സേവനവുമായി മത്സരിക്കുന്നു, അതിനാൽ 1723-നും പ്രോട്ടോക്കോൾ 47-നും ഒരു ഉടമയെ തിരഞ്ഞെടുക്കുക.

ഒരേ NAT-ന് പിന്നിലെ രണ്ട് ക്ലയന്റുകളാണ് ലളിതമായ ഫോർവേഡിംഗിനെ ബുദ്ധിമാനിൽ നിന്ന് വേർതിരിക്കുന്ന സന്ദർഭം. കോൾ ഐഡന്റിഫയറുകൾ വീണ്ടും എഴുതാതെ പ്രോട്ടോക്കോൾ 47 ഫോർവേഡ് ചെയ്യുന്നത് അവ ശരിയാക്കാൻ ശ്രമിക്കുന്ന സഹായിയെക്കാൾ സാധാരണയായി മെച്ചമായി പെരുമാറുന്നു.

റൂട്ടറിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് ടണൽ അളക്കുക

PPTP ഉപയോഗ്യ പേലോഡ് ചെറുതാക്കുന്നു, ആ ചുരുക്കം രഹസ്യമല്ല, ഗണിതമാണ്. ഓരോ ടണൽ പാക്കറ്റും പുറത്തെ IP ഹെഡർ, വിപുലീകൃത GRE ഹെഡർ, PPP ഹെഡർ, എൻക്രിപ്ഷനുണ്ടെങ്കിൽ MPPE ഹെഡർ എന്നിവ വഹിക്കുന്നു. ഫലമായ ഫ്രെയിം കടത്താൻ പാതയ്ക്ക് കഴിയാതെ വരുമ്പോൾ ചെറിയ പാക്കറ്റുകൾ കടക്കുന്നു, ലോഗിൻ പൂർത്തിയാകുന്നു, ഫയൽ കൈമാറ്റമോ TLS ഹസ്തദാനമോ പൂർണ വലിപ്പത്തിലുള്ള പാക്കറ്റ് അയക്കുന്ന ആദ്യ അവസരത്തിൽ സെഷൻ നിലയ്ക്കുന്നു.

ഊഹിക്കുന്നതിന് പകരം സംഖ്യ കണക്കാക്കുക. വിപുലീകൃത GRE-യ്ക്ക് 8 ബൈറ്റ്, PPP-യ്ക്ക് 4, MPPE-യ്ക്ക് 4, പുറത്തെ IP ഹെഡറിന് 20 എന്നിവ വേണം, അതിനാൽ ടണൽ ഏതെങ്കിലും പേലോഡിന് മുൻപ് 36 ബൈറ്റ് തിന്നുന്നു. 1492-ൽ അവസാനിക്കുന്ന PPPoE WAN-ൽ ഒതുങ്ങുന്ന ഏറ്റവും വലിയ PPP MTU 1492 മൈനസ് 36 ആണ്, അതായത് 1456. PPP ഓപ്ഷനുകളിൽ mtu, mru എന്നിവ ആ മൂല്യത്തിൽ സജ്ജമാക്കി ഫ്രാഗ്മെന്റേഷനില്ലാത്ത പിംഗ് ഉപയോഗിച്ച് വീണ്ടും പരീക്ഷിക്കുക.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

പിംഗ് പാത അളക്കുന്നു, ടണൽ അല്ല: 1464 ബൈറ്റ് പേലോഡും 28 ബൈറ്റ് IP, ICMP ഹെഡറുകളും കൂടി 1492 ബൈറ്റിന്റെ ഫ്രെയിം കൃത്യമായി നിറയ്ക്കുന്നു. ആ പിംഗ് പരാജയപ്പെട്ടാൽ കടക്കുന്നത് വരെ സംഖ്യ കുറയ്ക്കുക, എന്നിട്ട് ഫലത്തിൽ നിന്ന് 36 കുറയ്ക്കുക. പാതയുടെ പരിധിക്ക് മുകളിൽ സജ്ജമാക്കിയ ടണൽ MTU വലിപ്പം പരാമർശിക്കുന്ന ഒരു ലോഗ് വരിപോലുമില്ലാതെ മരവിപ്പ് ഉണ്ടാക്കുന്നു.

ഒരേ റൂട്ടറിൽ PPTP, L2TP/IPsec അല്ലെങ്കിൽ OpenVPN

അതേ റൂട്ടറിന് മൂന്ന് സാധാരണ ടണലുകളിൽ ഏതും വഹിക്കാം, വ്യത്യാസം അത് എന്ത് പ്രകടിപ്പിക്കണം എന്നതിലാണ്. PPTP-യ്ക്ക് രണ്ട് വ്യത്യസ്ത പാളികളിൽ രണ്ട് നിയമങ്ങൾ വേണം. IPsec-ന് മുകളിലുള്ള L2TP-യ്ക്ക് താക്കോൽ കൈമാറ്റത്തിന് UDP 500, 4500 വേണം, NAT-T അത് വഹിക്കുന്നില്ലെങ്കിൽ പേലോഡിന് പ്രോട്ടോക്കോൾ 50 വേണം. OpenVPN-ന് ഒരു UDP പോർട്ട് മതി, സഹായി ഒന്നും വേണ്ട.

L2TP-യുടെ നിര സ്വയമേവ GRE-യെക്കാൾ സൗഹൃദപരമല്ല. ESP IP പ്രോട്ടോക്കോൾ 50 ആണ്, അതിനും പോർട്ടില്ല, അതിനാൽ പ്രോട്ടോക്കോൾ 47-ൽ ബുദ്ധിമുട്ടുന്ന റൂട്ടറിന് അതേ കാരണത്താൽ പ്രോട്ടോക്കോൾ 50-ലും ബുദ്ധിമുട്ടാം. ESP-യെ UDP 4500-നുള്ളിൽ പൊതിയാൻ NAT-T ഉണ്ട്, രണ്ട് അറ്റങ്ങളും അത് പിന്തുണയ്ക്കുമ്പോൾ പ്രോട്ടോക്കോൾ 50-ന്റെ നിയമം അനാവശ്യമാകുന്നു. അത് അറ്റങ്ങളുടെ സ്വഭാവമാണ്, റൂട്ടറിന്റെ PPTP ചെക്ക്ബോക്സിന്റേതല്ല. രണ്ടിനും നിയമങ്ങൾ എഴുതുന്നതിന് മുൻപ് ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഏത് എൻക്യാപ്സുലേഷനാണ് ചർച്ച ചെയ്തതെന്ന് ഉറപ്പാക്കുക.

OpenVPN ആണ് റൂട്ടർ വശത്ത് ഏറ്റവും കുറഞ്ഞ ചലിക്കുന്ന ഭാഗങ്ങളുള്ള ഓപ്ഷൻ. ഒരു UDP പോർട്ട്, ഒരു ഫോർവേഡിംഗ്, കണക്ഷൻ ട്രാക്കിംഗ് സഹായി ഇല്ല, കോൾ ഐഡന്റിഫയർ പുനരെഴുത്തുമില്ല. പകരം ഉൾനിർമ്മിത ഡയലറിന് പകരം ഇൻസ്റ്റാൾ ചെയ്യേണ്ട ക്ലയന്റാണ്, PPTP സംഭാഷണത്തിൽ തുടരുന്നതിന്റെ ഏക കാരണം പലപ്പോഴും അതാണ്.

എന്ത് നന്നാക്കണം, എന്ത് മാറ്റണം

ഫോർവേഡിംഗും MTU-വും നന്നാക്കിയാൽ പ്രവർത്തിക്കുന്ന ടണൽ ലഭിക്കും, സൂക്ഷിക്കേണ്ട ടണലല്ല. PPTP-യുടെ MSCHAPv2 പ്രാമാണീകരണം വർഷങ്ങളായി ആക്രമിക്കാവുന്നതാണ്, പ്രവർത്തിക്കുന്ന ടണൽ ഓഫ്ലൈനായി വീണ്ടെടുക്കാവുന്ന ക്രെഡൻഷ്യലുകൾ കൈമാറുന്നു. ദൂരെയുള്ള ഉപകരണത്തിന് L2TP/IPsec അല്ലെങ്കിൽ OpenVPN പ്രവർത്തിപ്പിക്കാമെങ്കിൽ നന്നാക്കലിനെ തീയതിയുള്ള താൽക്കാലിക നടപടിയായി കാണുക.

തീരുമാനം ദൂരെയുള്ള അറ്റം എന്ത് പിന്തുണയ്ക്കുന്നു, ക്രമീകരണം എത്രകാലം നിലനിൽക്കണം എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. PPTP മാത്രം സംസാരിക്കുന്ന പഴയ ഉപകരണത്തിന് നന്നാക്കൽ ലഭിക്കും; ക്ലയന്റ് ഇൻസ്റ്റാൾ ചെയ്യാവുന്ന എല്ലാം കൈമാറ്റം ചെയ്യപ്പെടും.

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