VPN വിലാസത്തിലെ Samba: ശ്രോതാവ് എന്തുകൊണ്ട് അപ്രത്യക്ഷമാകുന്നു
ടണൽ വീണ്ടും ആരംഭിക്കുന്നതുവരെ പങ്കിടൽ പ്രവർത്തിക്കുന്നു, പിന്നീട് ping ഇപ്പോഴും മറുപടി നൽകുമ്പോൾ സമയം കഴിയുന്നു. അപ്രത്യക്ഷമായ വിലാസത്തിൽ ബന്ധിച്ച ശ്രോതാവ് മുഴുവൻ മാതൃകയും വിശദീകരിക്കുന്നു.
പങ്കിടൽ രാവിലെ മുഴുവൻ പ്രവർത്തിക്കുന്നു, ഉച്ചയ്ക്ക് ടണൽ വീണ്ടും ബന്ധിപ്പിക്കുന്നു, ഇപ്പോൾ അതേ UNC പാത സമയം കഴിഞ്ഞ് പരാജയപ്പെടുന്നു, അതേസമയം സർവറിലേക്കുള്ള ping ഇപ്പോഴും മറുപടി നൽകുന്നു. പങ്കിടലിന്റെ നിർവചനത്തിൽ ഒന്നും മാറിയിട്ടില്ല, VPN പ്രവർത്തിക്കുന്നു. മാറിയത് Samba ബന്ധിച്ചിരുന്ന പ്രാദേശിക വിലാസമാണ്, ഇന്റർഫേസ് വീണ്ടും സൃഷ്ടിച്ചതിന് ശേഷം അത് നിലവിലില്ല. ആ പരാജയരീതി ശ്രോതാവിന്റെ ജീവിതചക്രത്തിന്റെ പ്രശ്നമാണ്, അനുമതിയുടെ പ്രശ്നമല്ല.
ടണൽ വീണ്ടും ആരംഭിക്കുന്നതുവരെ പങ്കിടൽ പ്രവർത്തിക്കുന്നു
ഒരു സേവനത്തെ ഒരു വിലാസത്തിൽ ബന്ധിക്കുന്നത് അതിന്റെ സോക്കറ്റിനെ ആ വിലാസത്തിന്റെ ആയുസ്സുമായി ബന്ധിപ്പിക്കുന്നു. ടണൽ ഇന്റർഫേസ് നശിപ്പിച്ച് വീണ്ടും നിർമ്മിക്കുമ്പോൾ പഴയ വിലാസം അപ്രത്യക്ഷമാകുന്നു, അതിൽ ബന്ധിച്ച സോക്കറ്റും അതിനൊപ്പം പോകുന്നു. സേവനം പ്രവർത്തിക്കുന്നു, പക്ഷേ ക്ലയന്റുകളെ അയക്കുന്നിടത്ത് ഒന്നും ശ്രവിക്കുന്നില്ല.
പുതിയ വിലാസം ICMP-യോട് പ്രതികരിച്ചാൽ ping ഇപ്പോഴും വിജയിച്ചേക്കാം, അതുകൊണ്ടാണ് പങ്കിടൽ മരിച്ചിരിക്കുമ്പോൾ പ്രാപ്യത നന്നായി തോന്നുന്നത്. ആ ഒറ്റ തെറ്റിദ്ധരിപ്പിക്കുന്ന വിജയമാണ് ആളുകളെ ഫയർവാളിലേക്ക് അയക്കുന്നത്.
പ്രാപ്യത ബന്ധന വിലാസമല്ല
ഇവിടെ മൂന്ന് തീരുമാനങ്ങൾ കൂടിക്കലരുന്നു. റൂട്ട് ക്ലയന്റ് പാക്കറ്റ് എത്തുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. ശ്രവിക്കുന്ന സോക്കറ്റ് പ്രാദേശിക വിലാസത്തിൽ എന്തെങ്കിലും അത് സ്വീകരിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. പങ്കിടൽ കോൺഫിഗറേഷനും ഫയൽസിസ്റ്റം അനുമതികളും അതിനു ശേഷം എന്ത് സംഭവിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. ഇന്റർഫേസ് വീണ്ടും സൃഷ്ടിക്കുമ്പോൾ രണ്ടാമത്തേത് മാത്രം തകരുന്നു.
VPN പൂളിലെ വിലാസവും സ്വയമേവ പ്രാദേശിക ബന്ധന വിലാസമാകുന്നില്ല. അത് ഒരു ക്ലയന്റിന്റേതാണ്, ഫയൽ സർവറിന്റേതല്ല. ഫയൽ സേവനത്തിന് ping മോശം പരിശോധനയാണ്.
ഡോക്യുമെന്റേഷനിലും ആ ഉടമകളെ വേർതിരിച്ച് നിർത്തുക. VPN പൂളിലെ ഭാവി മാറ്റത്തിന് Samba തിരുത്തേണ്ടതില്ല, പങ്കിടൽ അനുമതിയുടെ മാറ്റത്തിന് ടണൽ പുനരാരംഭിക്കേണ്ടതുമില്ല.
പകരം സ്ഥിരമായ ഒരു വിലാസത്തിൽ ബന്ധിക്കുക
കൂടുതൽ സ്ഥിരതയുള്ള രൂപകൽപ്പന Samba-യെ സ്ഥിരമായ വിലാസത്തിൽ നിർത്തി ക്ലയന്റുകളെ അവിടേക്ക് VPN എത്തിക്കാൻ അനുവദിക്കുന്നു. ടണൽ ഇളകുമ്പോൾ സർവർ വിലാസം മാറുന്നില്ല, അതിനാൽ ശ്രോതാവിന് ഇന്റർഫേസ് പിന്തുടരേണ്ടതില്ല. അപ്പോൾ പ്രവേശനം VPN പാതയും ഹോസ്റ്റ് ഫയർവാളും നടപ്പിലാക്കുന്നു, അവ ആ ജോലിക്കായി നിർമ്മിച്ചവയാണ്.
ടണലിൽ ബന്ധിക്കേണ്ടതുണ്ടെങ്കിൽ, ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിന്റെ കരാർ മനസ്സിലാക്കുക. interfaces, bind interfaces only പാരാമീറ്ററുകൾ ഒന്നല്ല, കൂടാതെ ബന്ധന ഡോക്യുമെന്റേഷൻ ഇടയ്ക്കിടെ മാറുന്ന ഇന്റർഫേസുകളെക്കുറിച്ച് മുന്നറിയിപ്പ് നൽകുന്നു. ചില പ്ലാറ്റ്ഫോമുകളിൽ ഗതിക ശ്രോതാവ് കൈകാര്യം ഉണ്ട്, പക്ഷേ അത് അനുമാനിക്കേണ്ടതല്ല, പരിശോധിക്കേണ്ട കഴിവാണ്. ഇളക്കത്തിന് മുമ്പും ശേഷവും പട്ടിക വായിച്ച് രണ്ട് ഔട്ട്പുട്ടുകളും താരതമ്യം ചെയ്യുക.
ss -ltnp | grep ':445'വീണ്ടും ബന്ധിപ്പിക്കൽ പരിശോധിക്കുക, പച്ച വിളക്കല്ല
സേവനം ആരംഭിച്ചതിന് ശേഷം മാത്രമല്ല, വീണ്ടും ബന്ധിപ്പിച്ചതിന് ശേഷം ശ്രോതാവ് പരിശോധിക്കുക. ടണൽ വീണ്ടും സൃഷ്ടിക്കുക, തുടർന്ന് ശ്രവണ പട്ടിക വായിച്ച് ക്ലയന്റുകളെ അയക്കുന്ന വിലാസത്തിൽ സോക്കറ്റ് ഉണ്ടെന്ന് ഉറപ്പാക്കുക. പച്ച ടണൽ സൂചകവും വിജയകരമായ കോൺഫിഗറേഷൻ പരിശോധനയും ഇവ രണ്ടും തെളിയിക്കുന്നില്ല.
smbclient -L //files.corp.example -U aliceതുടർന്ന് ഒരു ക്ലയന്റിൽ നിന്ന് അനുവദനീയമായ ഒരു പ്രവർത്തനവും നിഷേധിക്കപ്പെട്ട ഒരു പാതയും പ്രവർത്തിപ്പിച്ച് രണ്ടാം വീണ്ടും ബന്ധിപ്പിക്കലിന് ശേഷം ആവർത്തിക്കുക. പങ്കിടൽ ആദ്യ ഇളക്കം വരെ മാത്രം പ്രവർത്തിക്കുന്നുവെങ്കിൽ, ബന്ധനം ഇപ്പോഴും ഇന്റർഫേസിന്റെ ആയുസ്സുമായി ബന്ധിതമാണ്, രൂപകൽപ്പന ശരിയാക്കിയിട്ടില്ല. ബന്ധനമോ സേവന വിലാസമോ മാറ്റുക, ലക്ഷണം വീണ്ടും വരില്ല.