Docker-ൽ PPTP പ്രാമാണീകരിക്കുന്നു പക്ഷേ ട്രാഫിക്ക് കൊണ്ടുപോകുന്നില്ല
PPTP-ക്ക് നിയന്ത്രണത്തിന് TCP 1723-ഉം പേലോഡിന് GRE-യും വേണം. കണ്ടെയ്നറിൽ conntrack സഹായി പലപ്പോഴും ഇല്ല, അതിനാൽ ലോഗിൻ പ്രവർത്തിക്കും, മറ്റൊന്നുമില്ല.
ക്ലൈന്റ് പ്രാമാണീകരിക്കുന്നു, PPP ഒരു വിലാസം ചർച്ച ചെയ്യുന്നു, പിന്നെ ഒന്നും നീങ്ങുന്നില്ല. Ping പരാജയപ്പെടുന്നു, ബ്രൗസർ പരാജയപ്പെടുന്നു, കണ്ടെയ്നർ എപ്പോഴും ബന്ധിപ്പിച്ചിരിക്കുന്നതായി തോന്നുന്നു. ഈ മാതൃക റൂട്ടിംഗ് ടേബിളിന്റെ പ്രശ്നമല്ല, കാരണം റൂട്ടിംഗ് പ്രശ്നങ്ങൾ സാധാരണയായി നിയന്ത്രണ ബന്ധവും തകർക്കുന്നു. ഇത് പേലോഡിന്റെ പാതയാണ്, PPTP-യിൽ പേലോഡ് ഇപ്പോൾ വിജയിച്ച പ്രോട്ടോക്കോളിൽ നിന്ന് വ്യത്യസ്തമായ പ്രോട്ടോക്കോളാണ്.
ഏറ്റവും സമയം ലാഭിക്കുന്ന ക്രമത്തിൽ അഞ്ച് പരിശോധനകൾ.
പരിശോധന 1: നിയന്ത്രണ ചാനൽ പേലോഡിൽ നിന്ന് വേർതിരിക്കുക
PPTP TCP 1723-ൽ പ്രാമാണീകരിക്കുന്നു, തുടർന്ന് PPP പേലോഡ് GRE, IP പ്രോട്ടോക്കോൾ 47-നുള്ളിൽ കൊണ്ടുപോകുന്നു. GRE TCP അല്ല, UDP-യുമല്ല, അതിനാൽ നിയന്ത്രണ പോർട്ട് ഫോർവേഡ് ചെയ്യുന്ന ഓരോ നിയമവും അതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. 1723 കടത്തിവിടുന്ന NAT അല്ലെങ്കിൽ ഫയർവാൾ 47 പ്രോട്ടോക്കോളിനെ പരാതിയില്ലാതെ ഉപേക്ഷിക്കാം, സെഷൻ വിജയം പോലെ തോന്നുന്ന രീതിയിൽ പകുതി നിർമ്മിതമായി തുടരും.
ലോഗിൻ പ്രവർത്തിക്കുകയും ഒരു പാക്കറ്റും തിരികെ വരാതിരിക്കുകയും ചെയ്താൽ, ആദ്യം GRE അനുമാനിക്കുക, പിന്നീട് അത് തെളിയിക്കുക.
പരിശോധന 2: ഹോസ്റ്റ് കേർണലിലെ സഹായി ഉറപ്പാക്കുക
കണക്ഷൻ ട്രാക്കിംഗ് സഹായിയില്ലാതെ TCP നിയന്ത്രണ കണക്ഷനെ GRE ഫ്ലോയുമായി ബന്ധിപ്പിക്കാൻ കഴിയില്ല. മൊഡ്യൂൾ nf_conntrack_pptp ആണ്, അത് ഹോസ്റ്റ് കേർണലിൽ ജീവിക്കുന്നു, കണ്ടെയ്നർ ഇമേജിനുള്ളിൽ അത് ലോഡ് ചെയ്യുന്നത് ഒന്നും നേടുന്നില്ല കാരണം മൊഡ്യൂളുകൾ ഹോസ്റ്റ് മുഴുവനും ബാധകമാണ്. Docker ഹോസ്റ്റിൽ lsmod | grep nf_conntrack_pptp ആണ് പരിശോധന. അതില്ലെങ്കിൽ, modprobe nf_conntrack_pptp പ്രവർത്തിക്കുന്ന കേർണലിനായി അത് ലോഡ് ചെയ്യുന്നു, അടുത്ത ബൂട്ടിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ ഹോസ്റ്റ് കോൺഫിഗറേഷനിലും അത് ചേർക്കുക.
പുനരാരംഭത്തിൽ അപ്രത്യക്ഷമാകുന്ന മൊഡ്യൂൾ അടുത്ത മാസം അതേ ടിക്കറ്റായി മാറുന്നു.
പരിശോധന 3: അത് അപ്രാപ്തമാക്കുന്ന കേർണൽ നയം വായിക്കുക
മൊഡ്യൂൾ ഉണ്ടായിരുന്നാലും, 4.7 മുതലുള്ള കേർണലുകൾ net.netfilter.nf_conntrack_helper സ്വതവേ 0 ആയി സജ്ജമാക്കുന്നു, ഇത് ഓരോ പ്രോട്ടോക്കോളിനും സ്വയമേവയുള്ള സഹായി അനുവദനം ഓഫാക്കുന്നു. ആ സ്വതവേയുള്ള മൂല്യമാണ് ശരിയായി ഇൻസ്റ്റാൾ ചെയ്ത മൊഡ്യൂളും ഒന്നും ചെയ്യാത്തതിന്റെ കാരണം: കോഡ് ഉണ്ട്, നയം അത് ഉപയോഗിക്കരുതെന്ന് പറയുന്നു. sysctl net.netfilter.nf_conntrack_helper നിലവിലെ മൂല്യം റിപ്പോർട്ട് ചെയ്യുന്നു, പ്രവർത്തന സമയത്ത് അത് 1 ആക്കുന്നത് സഹായിയെ വീണ്ടും ലഭ്യമാക്കുന്നു. ഡിസൈൻ അനുവദിക്കുന്നുവെങ്കിൽ ഹോസ്റ്റിന്റെ sysctl കോൺഫിഗറേഷനിലൂടെ മൂല്യം നിലനിർത്തുക.
സ്വയമേവയുള്ള അനുവദനം ട്രാഫിക്ക് പരോക്ഷമായി പ്രതീക്ഷകൾ സൃഷ്ടിക്കാൻ അനുവദിക്കുന്നു, അതുകൊണ്ടാണ് സ്വതവേയുള്ള മൂല്യം മാറ്റിയത്. അത് വിശ്വസനീയമായ ഹോസ്റ്റിലേക്ക് പരിമിതപ്പെടുത്തുക, അല്ലെങ്കിൽ സഹായിയെ ലക്ഷ്യമിടുന്ന വ്യക്തമായ നിയമം ഉപയോഗിക്കുക.
പരിശോധന 4: കണ്ടെയ്നറിന്റെ പാത പ്രത്യേകം നോക്കുക
ലോഡ് ചെയ്ത സഹായി ഒരു റൂട്ട് സൃഷ്ടിക്കുന്നില്ല. കണ്ടെയ്നറിന് PPTP സെർവറിലേക്ക് ഒരു പാത വേണം, ഹോസ്റ്റ് ഫോർവേഡിംഗ് ഇരു ദിശകളിലും GRE അനുവദിക്കണം: iptables -L FORWARD -v -n 47 പ്രോട്ടോക്കോൾ സ്വീകരിക്കപ്പെടുന്നുണ്ടോ, കൗണ്ടറുകൾ നീങ്ങുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. Docker-ന്റെ masquerade നിയമങ്ങൾ TCP-യും UDP-യും വിവർത്തനം ചെയ്യുന്നു, 47 പ്രോട്ടോക്കോളല്ല, അതിനാൽ ബ്രിഡ്ജ് ചെയ്ത കണ്ടെയ്നറിന് വ്യക്തമായ forward അനുമതിയും ചില ഹോസ്റ്റുകളിൽ സ്വന്തം വിവർത്തന നിയമവും ആവശ്യമായി വന്നേക്കാം. കണ്ടെയ്നറിന് അതിന്റെ ഇമേജ് പ്രതീക്ഷിക്കുന്ന PPP ഉപകരണ പിന്തുണയുണ്ടെന്നും ഉറപ്പാക്കുക.
നിയമത്തിന്റെ വാചകമല്ല, കൗണ്ടറുകൾ വായിക്കുക. നിലനിൽക്കുന്നതും ഒന്നിനോടും പൊരുത്തപ്പെടാത്തതുമായ നിയമം അലങ്കാരമാണ്.
പരിശോധന 5: GRE ട്രാക്ക് ചെയ്യപ്പെടുന്നുവെന്ന് തെളിയിക്കുക, പിന്നെ PPTP-യെക്കുറിച്ച് തീരുമാനിക്കുക
ക്ലൈന്റ് പ്രവർത്തിക്കുമ്പോൾ ട്രാക്കിംഗ് ടേബിൾ വായിക്കുക. സ്ഥാപിതമായ PPTP നിയന്ത്രണ എൻട്രിയും ബന്ധപ്പെട്ട GRE എൻട്രിയും ഉണ്ടെങ്കിൽ സഹായി ഫ്ലോകളെ ബന്ധിപ്പിക്കുന്നു എന്നും ബാക്കി തകരാർ മറ്റൊരിടത്താണ് എന്നും അർത്ഥം. GRE എൻട്രിയില്ലാത്ത നിയന്ത്രണ എൻട്രി എന്നാൽ പേലോഡ് ഉപേക്ഷിക്കപ്പെടുന്നു അല്ലെങ്കിൽ ട്രാക്ക് ചെയ്യപ്പെടുന്നില്ല, ഇത് നിങ്ങളെ പരിശോധന 2, 3 എന്നിവയിലേക്ക് തിരികെ കൊണ്ടുവരുന്നു.
PPTP തന്നെ പഴയതാണ്, MS-CHAPv2 ദുർബലമാണ്. സെർവർ L2TP/IPsec, IKEv2 അല്ലെങ്കിൽ WireGuard എന്നിവയും വാഗ്ദാനം ചെയ്യുന്നുവെങ്കിൽ, അവയിലൊന്നിലേക്ക് മാറുന്നത് ഈ മുഴുവൻ വിഭാഗം പ്രശ്നങ്ങളും ഇല്ലാതാക്കുന്നു.
PPTP നിൽക്കേണ്ടിടത്ത്, കണ്ടെയ്നറിനുള്ളിൽ അല്ലാതെ ഹോസ്റ്റിൽ ക്ലൈന്റ് പ്രവർത്തിപ്പിക്കുന്നത് NAT-ന്റെയും ഫിൽട്ടറിംഗിന്റെയും ഒരു പാളി ഒഴിവാക്കുന്നു, ഇത് പലപ്പോഴും വിലകുറഞ്ഞ തീരുമാനമാണ്.