OpenVPN auth-user-pass: ഫയൽ, stdin അല്ലെങ്കിൽ പ്രോംപ്റ്റ്? എങ്ങനെ തിരഞ്ഞെടുക്കാം

ഏത് ക്രെഡൻഷ്യൽ ഉറവിടം ഉപയോഗിക്കണം എന്ന് മൂന്ന് കാര്യങ്ങൾ തീരുമാനിക്കുന്നു: കൺസോളിൽ ഒരു വ്യക്തി ഇരിക്കുന്നുണ്ടോ, രഹസ്യം ഡിസ്കിൽ ജീവിക്കാമോ, മറ്റൊരു പ്രോസസ് പ്രോംപ്റ്റിന് ഉത്തരം നൽകണോ. തെറ്റായി തിരഞ്ഞെടുത്താൽ, പാസ്വേഡ് പൂർണ്ണമായി സാധുവായിരിക്കുമ്പോൾ തന്നെ ക്ലയന്റ് stdin പ്രശ്നം റിപ്പോർട്ട് ചെയ്യുന്നു, ഇത് മിക്കവരെയും കാരണമില്ലാതെ സെർവറിലേക്ക് അയയ്ക്കുന്നു. ആദ്യം പാത തിരഞ്ഞെടുക്കുക; ഏത് പാത അവ സൃഷ്ടിച്ചു എന്ന് അറിഞ്ഞാൽ മാത്രമേ പിശക് സന്ദേശങ്ങൾക്ക് അർത്ഥമുള്ളൂ.

അത് തീരുമാനിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

കൺസോൾ പ്രോംപ്റ്റ് ഒരു വ്യക്തിയെ ആവശ്യപ്പെടുന്ന ഏക പാതയാണ്, അതിനാൽ systemd യൂണിറ്റിലോ കണ്ടെയ്നറിലോ നിശബ്ദമായി പരാജയപ്പെടുന്ന ഏക പാതയും അതാണ്. ഒരു വ്യക്തി ക്ലയന്റ് ആരംഭിച്ച് പാസ്വേഡ് ടൈപ്പ് ചെയ്താൽ, ഒരു ഫയലും ഉൾപ്പെടുന്നില്ല, സംവേദനക്ഷമമായ ഒന്നും ഡിസ്കിൽ എത്തുന്നുമില്ല. ക്ലയന്റ് ബൂട്ടിൽ ആരംഭിച്ചാൽ, അതേ പ്രോംപ്റ്റ് തൂങ്ങിക്കിടക്കലായി മാറുന്നു, കാലഹരണം സാധാരണയായി ക്രെഡൻഷ്യൽ പിശകിന് പകരം പൊതുവായ കണക്ഷൻ പരാജയമായി കാണപ്പെടുന്നു.

പ്രോസസ് മേൽനോട്ടമില്ലാതെ ആരംഭിക്കുകയും നിയന്ത്രിത അനുമതി ഗണത്തിന് കീഴിൽ രഹസ്യം ഡിസ്കിൽ നിലനിൽക്കാനും കഴിയുമ്പോൾ ക്രെഡൻഷ്യൽ ഫയൽ ശരിയായ ഉത്തരമാണ്. രഹസ്യം ഒട്ടും എഴുതാൻ പാടില്ലാത്തപ്പോൾ - വോൾട്ട് മാത്രം നയം, ഹ്രസ്വകാല ടോക്കൺ - ക്ലയന്റിന് തുറക്കാൻ കഴിയുന്ന ഒരു സ്ട്രീം വേണം, അത് പ്രായോഗികമായി പ്രോസസ് പകരംവയ്പ്പ് അല്ലെങ്കിൽ ഫയൽ ഡിസ്ക്രിപ്റ്ററിലേക്ക് എഴുതുന്ന സഹായി എന്നാണ് അർത്ഥമാക്കുന്നത്. മാനേജ്മെന്റ് ഇന്റർഫേസ് നാലാമത്തെ കേസ് ഉൾക്കൊള്ളുന്നു: ടണലിന്റെ ജീവിതചക്രം ഇതിനകം കൈകാര്യം ചെയ്യുന്നതും സോക്കറ്റ് വഴി ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാൻ കഴിയുന്നതുമായ ഒരു കൺട്രോളർ.

• കൺസോളിൽ വ്യക്തി, ഓട്ടോമേഷൻ ഇല്ല: ഇന്ററാക്ടീവ് പ്രോംപ്റ്റ്.
• മേൽനോട്ടമില്ലാത്ത തുടക്കം, രഹസ്യം സംഭരിക്കാം: മോഡ് 0600 ക്രെഡൻഷ്യൽ ഫയൽ.
• മേൽനോട്ടമില്ലാത്ത തുടക്കം, രഹസ്യം സംഭരിക്കാൻ പാടില്ല: പ്രോസസ് പകരംവയ്പ്പ് അല്ലെങ്കിൽ രഹസ്യ ഏജന്റ് എഴുതുന്ന fd.
• മറ്റൊരു പ്രോസസിന് ക്ലയന്റിന്റെ ഉടമസ്ഥതയുണ്ട്: മാനേജ്മെന്റ് ഇന്റർഫേസ്.

രണ്ട് ഉത്തരങ്ങൾ യോജിക്കുമ്പോൾ, രഹസ്യം argv-നും shell ചരിത്രത്തിനും പുറത്ത് നിർത്തുന്നത് തിരഞ്ഞെടുക്കുക. പ്രോഗ്രാം ആർഗ്യുമെന്റായി നൽകുന്ന പാസ്വേഡ് പ്രോസസ് ലിസ്റ്റ് വഴി ഏത് പ്രാദേശിക ഉപയോക്താവിനും വായിക്കാം, ആ വെളിപ്പെടുത്തൽ പിൻവലിക്കാൻ പ്രയാസമാണ്.

ഓരോ ഇൻപുട്ട് പാതയും യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

--auth-user-pass ഒറ്റയ്ക്ക് കൺസോളിൽ ഉപയോക്തൃനാമവും പാസ്വേഡും ആവശ്യപ്പെടുന്നു. ഫയൽനാമം നൽകിയാൽ, ക്ലയന്റ് ആദ്യ വരി ഉപയോക്തൃനാമമായും രണ്ടാം വരി പാസ്വേഡായും എടുക്കുന്നു; ഉദ്ധരണികൾ, കമന്റുകൾ, കീ-മൂല്യ സിന്റാക്സ് എന്നിവയൊന്നും പിന്തുണയ്ക്കുന്നില്ല. ഇതാണ് മുഴുവൻ ഫോർമാറ്റ്, അതിനാൽ INI ഫയൽ പ്രതീക്ഷിച്ച് എഡിറ്റ് ചെയ്യുന്ന ആരും അത് തകർക്കുന്നു. ഇൻലൈൻ <auth-user-pass> ബ്ലോക്ക് പ്രൊഫൈലിനുള്ളിൽ അതേ രണ്ട് വരികൾ സൂക്ഷിക്കുന്നു, ഇത് പ്രൊഫൈലിനെ തന്നെ രഹസ്യമാക്കുകയും സ്വകാര്യ കീയുടെ അതേ കൈകാര്യം ചെയ്യൽ വിഭാഗത്തിൽ ഉൾപ്പെടുത്തുകയും ചെയ്യുന്നു.

ബാക്കിയുള്ള രണ്ട് പാതകൾ സ്ട്രീമും സോക്കറ്റുമാണ്. OpenVPN-ന് വായിക്കാവുന്ന ഫയൽ ഡിസ്ക്രിപ്റ്റർ മാത്രം മതി, അതിനാൽ പ്രോസസ് പകരംവയ്പ്പ്, പൈപ്പ് പിന്തുണയുള്ള /dev/fd എൻട്രി, യഥാർത്ഥത്തിൽ FIFO ആയ ഫയൽനാമം എന്നിവ സ്വീകരിക്കും. മാനേജ്മെന്റ് ഇന്റർഫേസ് സ്വഭാവത്തിൽ വ്യത്യസ്തമാണ്: ക്ലയന്റ് മൂല്യങ്ങൾ സ്വയം വായിക്കുന്നതിന് പകരം മേൽനോട്ട പ്രോസസിനോട് ചോദിക്കുന്നു. വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ ആ വ്യത്യാസം പ്രധാനമാണ്: ക്രെഡൻഷ്യൽ ഫയൽ, രഹസ്യ സഹായി വീണ്ടും എഴുതാൻ കഴിയുന്ന FIFO, മാനേജ്മെന്റ് ഇന്റർഫേസ് എന്നിവയ്ക്ക് മനുഷ്യനില്ലാതെ വീണ്ടും നൽകാം; പ്രോസസ് പകരംവയ്പ്പിന് കഴിയില്ല, കാരണം ഡിസ്ക്രിപ്റ്റർ ആദ്യ വായനയിൽ തന്നെ ചെലവഴിക്കപ്പെടുന്നു.

ഫയൽ കൃത്യമായി രണ്ട് വരികൾ ആയിരിക്കണം

തകർന്ന ക്രെഡൻഷ്യൽ ഫയലുകളിൽ ഭൂരിഭാഗവും രണ്ട് പരാജയ മാതൃകകൾ ഉൾക്കൊള്ളുന്നു. Windows എഡിറ്റർ CRLF അവസാനങ്ങൾ വിടുന്നു, ക്യാരേജ് റിട്ടേൺ പാസ്വേഡിന്റെ ഭാഗമായിത്തീരുന്നു, സ്ക്രീനിൽ ശരിയായി തോന്നുന്ന മൂല്യം സെർവർ നിരസിക്കുന്നു. കാലി രണ്ടാം വരി - പാസ്വേഡ് ഉണ്ടായിരിക്കേണ്ടയിടത്ത് കാലി വരി - ക്ലയന്റിനെ കാലി പാസ്വേഡുമായി വിടുന്നു, സ്ക്രീനിലെ മൂല്യം ശരിയായി തോന്നിയാലും സെർവർ അത് നിരസിക്കുന്നു. പാസ്വേഡിന് ശേഷമുള്ള അധിക പുതിയ വരി നിരുപദ്രവകരമാണ്. ഫയൽ എഡിറ്ററിൽ നിന്നല്ല, shell-ൽ നിന്ന് എഴുതി ബൈറ്റുകൾ പരിശോധിക്കുക:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

പാത ഉള്ളടക്കത്തിന്റെ അത്ര തന്നെ പ്രധാനമാണ്. ആപേക്ഷിക പാത പ്രോസസിന്റെ പ്രവർത്തന ഡയറക്ടറിയുമായി താരതമ്യം ചെയ്ത് പരിഹരിക്കുന്നു, ഒരു സേവനത്തിന് അത് നിങ്ങൾ പരീക്ഷിച്ച ഡയറക്ടറി ആയിരിക്കുന്നത് അപൂർവമാണ്. കേവല പാത ഉപയോഗിക്കുക, ഫയൽ ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിന്റെ ഉടമസ്ഥതയിലാക്കുക, ഗ്രൂപ്പിനും മറ്റുള്ളവർക്കും വായിക്കാനാകാതിരിക്കാൻ മോഡ് 0600 നിലനിർത്തുക. OpenVPN 2.6 മാനുവൽ ഡയറക്ടീവിന്റെ സ്വീകാര്യ രൂപങ്ങൾ പട്ടികപ്പെടുത്തുന്നു; മൂന്നാമത്തേത് കണ്ടുപിടിക്കുന്നതിന് മുമ്പ് അത് പരിശോധിക്കുക.

സെർവറിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഫയൽ പരീക്ഷിക്കുക. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 പ്രവർത്തിപ്പിക്കുമ്പോൾ ഫയൽ തുറന്നോ എന്നും പിന്നീട് ക്രെഡൻഷ്യലുകൾ സ്വീകരിച്ചോ എന്നും പ്രിന്റ് ചെയ്യുന്നു, അടുത്തതായി ഏത് പാളി മാറ്റണം എന്ന് അത് പറയുന്നു.

സ്ട്രീമുകൾ, stdin, അവ സൃഷ്ടിക്കുന്ന പിശകുകൾ

പാസ്വേഡ് പൈപ്പിലേക്ക് കൊടുക്കുന്നത് മിക്കവരും ആദ്യം ശ്രമിക്കുന്ന കാര്യവും ഏറ്റവും കൂടുതൽ അത്ഭുതങ്ങളുള്ള പാതയുമാണ്. പ്രോസസ് പകരംവയ്പ്പ് പ്രവർത്തിക്കുന്നത് ക്ലയന്റിന് വായിക്കാവുന്ന ഡിസ്ക്രിപ്റ്റർ മാത്രം വേണ്ടതിനാലാണ്: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin കൈമാറുന്നത് ക്ലയന്റ് ചോദിക്കുന്ന നിമിഷത്തിൽ stdin ഇപ്പോഴും തുറന്നതും വായിക്കാവുന്നതുമായിരിക്കുമ്പോൾ മാത്രം പ്രവർത്തിക്കുന്നു, അത് ഇതിനകം ഉപയോഗിച്ച പൈപ്പ്ലൈനിൽ ശരിയല്ല.

ERROR: could not read Auth username from stdin-ന് രണ്ട് വ്യത്യസ്ത കാരണങ്ങളുണ്ട്. ചില 2.3.x ക്ലയന്റുകളിൽ സന്ദേശം stdin കൈകാര്യം ചെയ്യുന്നതിലെ ഒരു വീഴ്ചയിൽ നിന്നാണ് വന്നത്, അത് പിന്നീടുള്ള 2.3 റിലീസുകൾ പരിഹരിച്ചു, അതിനാൽ അത്ര പഴയ ക്ലയന്റ് അപ്ഗ്രേഡ് ചെയ്താൽ മാത്രമേ മെച്ചപ്പെടൂ. നിലവിലെ ക്ലയന്റിൽ അതേ പദപ്രയോഗം അർത്ഥമാക്കുന്നത് ക്ലയന്റ് കൺസോൾ ഇൻപുട്ട് ആവശ്യപ്പെട്ടു എന്നും stdin ഒരു ടെർമിനൽ ആയിരുന്നില്ല എന്നുമാണ് - കൃത്യമായി systemd യൂണിറ്റ്, cron ജോലി, അല്ലെങ്കിൽ -t ഇല്ലാതെ ആരംഭിച്ച കണ്ടെയ്നർ എന്നിവയിലെ സ്ഥിതി.

auth-nocache തകർന്ന പാസ്വേഡ് പോലെ തോന്നിക്കുന്ന മൂന്നാം ലൂപ്പ് ചേർക്കുന്നു. ഉപയോഗത്തിന് ശേഷം ക്രെഡൻഷ്യലുകൾ മെമ്മറിയിൽ നിന്ന് വലിച്ചെറിയുന്നു, അതിനാൽ നെറ്റ്വർക്ക് മാറ്റം ഉണ്ടാക്കിയ വീണ്ടും കണക്ഷന് വീണ്ടും പ്ലേ ചെയ്യാൻ ഒന്നുമില്ല, പ്രോംപ്റ്റ് തിരികെ വരുന്നു. ഇത് രൂപകൽപ്പന അനുസരിച്ച് പ്രവർത്തിക്കുന്ന ഡയറക്ടീവാണ്. auth-nocache ക്ലയന്റ് മെമ്മറിയിൽ സൂക്ഷിക്കുന്നത് മാറ്റുന്നു, സെർവർ അല്ലെങ്കിൽ ഐഡന്റിറ്റി ദാതാവ് അക്കൗണ്ടിനെക്കുറിച്ച് ചിന്തിക്കുന്നതല്ല, അതിനാൽ മുഴുവൻ പരിഹാരവും അതേ ഫയൽ വീണ്ടും നൽകുക എന്നതാണ്, റീസ്റ്റാർട്ടിൽ വീണ്ടും വായിക്കുന്നു - നിയന്ത്രിത കണക്ഷനിൽ ആ വിതരണം അംഗീകൃത രഹസ്യ സംഭരണിയിൽ നിന്ന് വരണം, സ്ക്രിപ്റ്റിലെ പാസ്വേഡിൽ നിന്നല്ല.

പ്രോംപ്റ്റിന് മറ്റൊരു പ്രോസസിന്റെ ഉടമസ്ഥതയുള്ളപ്പോൾ മാനേജ്മെന്റ് ഇന്റർഫേസ്

ടണൽ ഇതിനകം മേൽനോട്ടം ചെയ്യുന്ന കൺട്രോളറിന് അതിന്റെ ചോദ്യങ്ങൾക്കും ഉത്തരം നൽകാം. ക്ലയന്റ് --management 127.0.0.1 7505-നൊപ്പം ആരംഭിക്കുക, സ്റ്റാറ്റസ് വരികൾ വായിക്കുക, >PASSWORD:Need 'Auth' username/password ശ്രദ്ധിക്കുക. കൺട്രോളർ വെവ്വേറെ കമാൻഡ് വരികളിൽ username "Auth" alice-ന് ശേഷം password "Auth" ... നൽകി ഉത്തരം നൽകുന്നു. 'Auth' ടോക്കൺ അഭ്യർത്ഥനയിലെ ഐഡന്റിഫയർ ആവർത്തിക്കുന്നു, അത് പൊരുത്തപ്പെടണം, അല്ലാത്തപക്ഷം ഉത്തരം അവഗണിക്കപ്പെടുകയും ക്ലയന്റ് കാത്തിരിക്കുകയും ചെയ്യുന്നു.

വില എന്നത് ഇപ്പോൾ നിങ്ങളുടെ കൈവശമുള്ള ഒരു സ്റ്റേറ്റ് മെഷീനാണ്: കണക്ഷൻ ക്രമം, ക്ലയന്റ് റീസ്റ്റാർട്ടുകൾ, ഹോസ്റ്റിലെ മറ്റ് ഉപയോക്താക്കൾ എത്താൻ പാടില്ലാത്ത ഒരു പ്രാദേശിക സോക്കറ്റ്. നിങ്ങൾ വാങ്ങുന്നത് റൺടൈമിൽ നൽകുന്ന ക്രെഡൻഷ്യലാണ്, ഡിസ്കിൽ ഫയലും തൂങ്ങിക്കിടക്കാൻ കഴിയുന്ന പ്രോംപ്റ്റും ഇല്ല. നിങ്ങളുടെ സ്റ്റാക്കിൽ മറ്റൊന്നും ഇതിനകം ഈ പ്രോട്ടോക്കോൾ സംസാരിക്കുന്നില്ലെങ്കിൽ, ഈ പാത പരിപാലിക്കേണ്ട ഒരു ഘടകം ചേർക്കുന്നു.

ക്രെഡൻഷ്യൽ പ്രശ്നം പോലെ തോന്നിക്കുന്ന പരാജയങ്ങൾ

ഒരിക്കലും പൂർത്തിയാകാത്ത TLS ഹാൻഡ്ഷേക്ക്, അല്ലെങ്കിൽ VERIFY ERROR: depth=0, error=certificate signature failure, വിശ്വാസ പ്രശ്നമാണ്, ഏതെങ്കിലും ഉപയോക്തൃനാമം വായിക്കുന്നതിന് മുമ്പ് സംഭവിക്കുന്നു. UDP ശ്രോതാവിലേക്ക് ലക്ഷ്യമിട്ട proto tcp ക്ലയന്റും അതേ സ്ഥലത്ത് പരാജയപ്പെടുന്നു: പാക്കറ്റുകൾ ഒരിക്കലും പ്രാമാണീകരണ ഘട്ടത്തിൽ എത്തുന്നില്ല, അതിനാൽ എല്ലാ പാസ്വേഡും അസോസിയേഷൻ കാരണം തെറ്റായി തോന്നുന്നു. ക്രെഡൻഷ്യൽ അയയ്ക്കുന്നതിന് മുമ്പ് സർട്ടിഫിക്കറ്റ് പരിശോധന ഓണായി നിർത്തുക; പരിചിതമായ ഒരു പ്രോംപ്റ്റ് പാസ്വേഡ് ആർക്ക് ലഭിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ക്രെഡൻഷ്യലിൽ തൊടുന്നതിന് മുമ്പ് സർട്ടിഫിക്കറ്റ് ശൃംഖല, പൊതുനാമം, ഗതാഗതം എന്നിവ പരിശോധിക്കുക.

പ്രൊഫൈൽ കൂട്ടിച്ചേർക്കുന്ന സ്ക്രിപ്റ്റിലെ shell പിശകുകളാണ് മറ്റൊരു തെറ്റായ സൂചന. [ ! -f "$file" ]-നുള്ളിൽ ഒരു സ്പേസ് ഇല്ലെങ്കിൽ command not found ഉണ്ടാകുന്നു, സ്ക്രിപ്റ്റ് നേരത്തെ നിലയ്ക്കുന്നു, പ്രൊഫൈൽ ഒരിക്കലും പുനർനിർമ്മിക്കപ്പെടുന്നില്ല, ക്ലയന്റ് മുമ്പത്തേതുമായി ആരംഭിക്കുന്നു. ആ പിശക് shell-ന്റേതാണ്, പ്രാമാണീകരണത്തിന്റേതല്ല, പാസ്വേഡ് എത്ര തവണ വീണ്ടും ടൈപ്പ് ചെയ്താലും അത് മായ്ക്കില്ല.

ഈ പ്രവാഹത്തിലെ ഓരോ പ്രോംപ്റ്റും ഈ ക്രെഡൻഷ്യലല്ല. സ്വകാര്യ കീ പാസ്ഫ്രേസ്, HTTP പ്രോക്സി ലോഗിൻ, സേവനത്തിന്റെ പാസ്വേഡ് എന്നിവ വിവിധ ഘട്ടങ്ങളിൽ ആവശ്യപ്പെടുന്ന മൂന്ന് വ്യത്യസ്ത രഹസ്യങ്ങളാണ്, കീ പാസ്ഫ്രേസ് സാധാരണയായി auth-user-pass-ന് പകരം ക്ലയന്റോ ഏജന്റോ കൈകാര്യം ചെയ്യുന്നു. TLS സെഷൻ നിലവിൽ വരുന്നതിന് മുമ്പ് പ്രോംപ്റ്റ് പ്രത്യക്ഷപ്പെട്ടാൽ, നിങ്ങൾ തെറ്റായ ചോദ്യത്തിന് ഉത്തരം നൽകുകയാണ്, അക്കൗണ്ട് റീസെറ്റ് സഹായിക്കില്ല. തെറ്റായ പ്രോംപ്റ്റ് ഒഴിവാക്കിയ ശേഷം, ബാക്കിയുള്ള പരിശോധനകൾ ഏറ്റവും പ്രാരംഭ പാളിയിൽ നിന്ന് ആരംഭിക്കുന്നു:

• അവസാന ക്രെഡൻഷ്യൽ വരിയല്ല, ആദ്യ പ്രോട്ടോക്കോൾ പിശക് വായിക്കുക: TLS, പിന്നെ പ്രാമാണീകരണം, പിന്നെ push.
• ഫയൽ രണ്ട് വരികളാണെന്നും ക്യാരേജ് റിട്ടേണുകൾ ഇല്ലെന്നും കേവല പാതയാൽ റഫറൻസ് ചെയ്യുന്നുവെന്നും ഉറപ്പാക്കുക.
• പ്രൊഫൈലും കമാൻഡ് ലൈനും ഡയറക്ടീവിനെക്കുറിച്ച് വിയോജിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കുക.
• "ക്രെഡൻഷ്യലുകൾ സ്വീകരിച്ചു" എന്നത് "ട്രാഫിക് ഒഴുകുന്നു" എന്നതിൽ നിന്ന് വേർതിരിക്കുക - റൂട്ടിംഗും DNS-ഉം പിന്നീടുള്ള പാളിയാണ്.

ക്ലയന്റ് push ഘട്ടത്തിൽ എത്തുമ്പോൾ, ക്രെഡൻഷ്യലുകൾ നോക്കുന്നത് നിർത്തി സെർവർ അയച്ച റൂട്ടുകളും DNS സെർവറുകളും വായിക്കാൻ തുടങ്ങുക. അതാണ് അടുത്ത പ്രശ്നം, നിങ്ങൾ ഇപ്പോൾ പരിഹരിച്ച പാസ്വേഡുമായി അതിന് യാതൊരു ബന്ധവുമില്ല.