OpenVPN റൂട്ട് നിർദ്ദേശത്തിൽ വൈൽഡ്കാർഡ് എന്തുകൊണ്ട് പ്രവർത്തിക്കാനാകില്ല

ഉദ്ദേശ്യം യുക്തിസഹമാണ്: ഒരു കമ്പനി ഡൊമെയ്നിലേക്കുള്ള എല്ലാം ടണലിലൂടെ അയച്ച് ബാക്കിയുള്ളത് വിടുക. തിരുത്തുന്ന നിർദ്ദേശം റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, റൂട്ടിന് പൊരുത്തപ്പെടുത്താൻ ഹോസ്റ്റ്നെയിം എന്ന ആശയമില്ല. അതിൽ വൈൽഡ്കാർഡ് എഴുതാനുള്ള ഓരോ ശ്രമവും പാഴ്സ് പിശകോ, അതിലും മോശം, പേര് ഒരു വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെട്ടതിനാൽ ഇന്ന് യാദൃശ്ചികമായി പ്രവർത്തിക്കുന്ന ഒരു റൂട്ടോ നൽകുന്നു. രണ്ട് വ്യത്യസ്ത സംവിധാനങ്ങളോട് പരസ്പരം ജോലി ചെയ്യാൻ ആവശ്യപ്പെടുന്നു.

റൂട്ട് എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു, എന്ത് ഒരിക്കലും വായിക്കുന്നുമില്ല

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

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

അതിനാൽ ഒരു പേരിൽ നിന്ന് നിർമ്മിച്ച റൂട്ട് ഒരു സ്നാപ്പ്ഷോട്ടാണ്, നിയമമല്ല. ടണൽ ആരംഭിച്ച നിമിഷത്തിൽ ആ പേര് എന്തിലേക്ക് പരിഹരിക്കപ്പെട്ടുവോ അത് അത് ഉൾക്കൊള്ളുന്നു, മാറുന്ന ഹോസ്റ്റുകളുടെ കുടുംബത്തിന് നിങ്ങൾ ആഗ്രഹിക്കാത്ത സ്വഭാവം അതു തന്നെയാണ്. നാളെ മാറുന്ന ഒരു റെക്കോർഡ് റൂട്ടിനെ ഇന്നലെയിലേക്ക് ചൂണ്ടിക്കാണിച്ച് വിടുന്നു.

ലക്ഷ്യം യഥാർത്ഥത്തിൽ ഒരു പ്രിഫിക്സ് ആകുമ്പോൾ

ലക്ഷ്യം അറിയപ്പെടുന്ന ഒരു സ്വകാര്യ നെറ്റ്വർക്ക് ആണെങ്കിൽ, പ്രിഫിക്സ് എഴുതുക. ഡോക്യുമെന്റേഷൻ സ്പേസിൽ നിന്നുള്ള ഒരു ഉദാഹരണത്തിന്, ഒരു ഹോസ്റ്റും ഒരു സബ്നെറ്റും ഇങ്ങനെ കാണപ്പെടുന്നു:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

രണ്ട് എൻട്രികളും വിലാസങ്ങളും മാസ്ക്കുകളും പേരിടുന്നു, രണ്ടും DNS മാറ്റങ്ങളെ അതിജീവിക്കുന്നു കാരണം അവയിൽ ഒന്നും ഒരു പേരിനെ ആശ്രയിക്കുന്നില്ല. അതാണ് മുഴുവൻ നേട്ടം: റൂട്ട് ഒരിക്കൽ സംഭവിച്ച ഒരു തിരയലിനെക്കുറിച്ചല്ല, ടോപ്പോളജിയെക്കുറിച്ചുള്ള ഒരു പ്രസ്താവനയാണ്.

ഒരു DNS ഉത്തരത്തിൽ നിന്ന് വലിയ പ്രിഫിക്സ് അനുമാനിക്കരുത്. ഒരു വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെടുന്ന ഒരു ഹോസ്റ്റ്നെയിം അതിന് പിന്നിലെ നെറ്റ്വർക്കിന്റെ വലിപ്പത്തെക്കുറിച്ച് നിങ്ങളോട് ഒന്നും പറയുന്നില്ല, അനുമാനിച്ച പ്രിഫിക്സാണ് ടണൽ ആരും അതിലൂടെ അയയ്ക്കാൻ ഉദ്ദേശിക്കാത്ത ട്രാഫിക് പിടിക്കാൻ ഇടയാക്കുന്നത്. തിരയലിൽ നിന്ന് അനുമാനിക്കുന്നതിനുപകരം നെറ്റ്വർക്ക് ഉടമയോട് യഥാർത്ഥ പ്രിഫിക്സ് ചോദിക്കുക.

ജോലിയുടെ യൂണിറ്റ് ഒരു ഹോസ്റ്റ്നെയിം ആകുമ്പോൾ

ഡൊമെയ്നനുസരിച്ച് തിരഞ്ഞെടുക്കാൻ ഡൊമെയ്ൻ വായിക്കുന്ന എന്തെങ്കിലും ആവശ്യമാണ്, അതായത് ഒരു അപ്ലിക്കേഷൻ ലെയർ ഘടകം. സാധാരണ ഉത്തരം ടണലിന്റെ മറുവശത്ത് കഴിയുന്ന ഒരു HTTP പ്രോക്സിയാണ്, ഏത് അഭ്യർത്ഥനകൾ അതിന് അയയ്ക്കണം എന്ന് ക്ലയന്റ് തിരഞ്ഞെടുക്കുന്നു.

ഒരു പ്രോക്സി കോൺഫിഗറേഷൻ ഫയലിന് ആ തിരഞ്ഞെടുപ്പ് പ്രകടിപ്പിക്കാം. ചുവടെയുള്ള ഉദാഹരണ നിയമങ്ങൾ ഒരു ഡൊമെയ്നും അതിന്റെ സബ്ഡൊമെയ്നുകളും പ്രോക്സിയിലേക്കും ബാക്കിയെല്ലാം നേരിട്ടും അയയ്ക്കുന്നു:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

കൃത്യമായ പേരിന്റെ താരതമ്യം ഡൊമെയ്നിനെത്തന്നെ ഉൾക്കൊള്ളുന്നു, സഫിക്സ് താരതമ്യം അതിന്റെ മക്കളെ ഉൾക്കൊള്ളുന്നു പക്ഷേ സമാന അക്ഷരങ്ങളിൽ അവസാനിക്കുന്ന ഒരു പേരുമായി പൊരുത്തപ്പെടുന്നില്ല. രണ്ടും ആവശ്യമാണ്, ഒന്ന് ഒഴിവാക്കിയാൽ ശരിയെന്ന് തോന്നുന്നതും എന്നാൽ കൊടുമുടിയെയോ വ്യാജനെയോ ഒഴിവാക്കുന്നതുമായ ഒരു നിയമം ഉണ്ടാകുന്നു.

ഈ നിയമങ്ങൾ ഒരു പ്രോക്സിയെ തിരഞ്ഞെടുക്കുന്നു; അവ അത് സൃഷ്ടിക്കുന്നില്ല, ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ ഒരു റൂട്ടും മാറ്റുന്നുമില്ല. പ്രോക്സി വിലാസത്തിന് ഇപ്പോഴും ടണലിലൂടെ സ്വന്തം വഴി വേണം, നേരിട്ടുള്ളതായി അടയാളപ്പെടുത്തിയ അഭ്യർത്ഥനകൾ യന്ത്രത്തിന് ഇതിനകം ഉള്ള റൂട്ടിംഗ് നയം പിന്തുടരുന്നു.

പ്രോക്സി ഓപ്ഷൻ ഉൾക്കൊള്ളാത്തത്

ബ്രൗസറിന്റെ പ്രോക്സി കോൺഫിഗറേഷൻ അവഗണിക്കുന്ന പ്രോഗ്രാമുകൾക്ക് ഇതിൽ നിന്ന് യാതൊന്നും ബാധകമാകില്ല. കമാൻഡ് ലൈൻ ടൂളുകൾ, അപ്ഡേറ്ററുകൾ, സ്വന്തം നെറ്റ്വർക്ക് സ്റ്റാക്കുള്ള അപ്ലിക്കേഷനുകൾ എന്നിവ PAC ഫയലല്ല, റൂട്ട് ടേബിളാണ് എടുക്കുന്നത്, അതിനാൽ ആ കേസുകൾക്ക് പിന്തുണയുള്ള ഓരോ അപ്ലിക്കേഷനുമുള്ള സംവിധാനം അല്ലെങ്കിൽ മറ്റൊരു രൂപകൽപ്പന ആവശ്യമാണ്. ബ്രൗസർ നിയമം വർക്ക്ഫ്ലോയെ ഉൾക്കൊള്ളുന്നുവെന്ന് വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് പ്രധാന ക്ലയന്റുകൾ ലിസ്റ്റ് ചെയ്യുക.

നേരിട്ട് തിരികെ പോകുന്നതും ഒരു രക്ഷപ്പെടൽ വഴിയല്ല. യന്ത്രത്തിന്റെ റൂട്ടിംഗ് നയം ഇതിനകം എല്ലാം ടണലിലേക്ക് അയയ്ക്കുന്നുണ്ടെങ്കിൽ, നേരിട്ടുള്ളതായി അടയാളപ്പെടുത്തിയ അഭ്യർത്ഥന അതിനുള്ളിൽ തന്നെ നിൽക്കുന്നു, കാരണം പ്രോക്സി തിരഞ്ഞെടുപ്പും റൂട്ട് ടേബിളും വ്യത്യസ്ത ലെയറുകളിൽ എടുക്കുന്ന വ്യത്യസ്ത തീരുമാനങ്ങളാണ്.

പേരുകൾ പരിഹരിക്കുന്നത് മൂന്നാമത്തെ വേറിട്ട ചോദ്യമാണ്. ഏത് അഭ്യർത്ഥനകൾ പ്രോക്സിയിലേക്ക് പോകണം എന്ന് തിരഞ്ഞെടുക്കുന്നത് അവയ്ക്ക് ഏത് റിസോൾവർ ഉത്തരം നൽകുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, രണ്ടിനെയും ഒരു ക്രമീകരണമായി കാണുന്നത് പുറത്തുനിന്ന് ആരെങ്കിലും പരിശോധിക്കുന്നതുവരെ കാണാത്ത ലീക്കുകൾ സൃഷ്ടിക്കുന്നു. ഓരോ ക്വറിക്കും എവിടെ ഉത്തരം നൽകുന്നു എന്ന് തീരുമാനിച്ച് ആ തീരുമാനം പ്രോക്സി നിയമത്തിന് സമീപം എഴുതുക. ടണൽ ഉയർന്നതിനാൽ മാറുന്ന റിസോൾവർ ഉത്തരം നിശബ്ദമായി മാറ്റും.

രണ്ട് പാതകളും പരിശോധിക്കുക, സന്തോഷകരമായത് മാത്രമല്ല

പൊരുത്തപ്പെടേണ്ട ഒരു ഹോസ്റ്റ്നെയിം, പൊരുത്തപ്പെടരുതാത്ത ഒരു ഹോസ്റ്റ്നെയിം, ഡൊമെയ്നിന്റെ കൊടുമുടി എന്നിവ പരിശോധിക്കുക, കാരണം സഫിക്സ് മാത്രമുള്ള നിയമം ഏറ്റവും കൂടുതൽ നഷ്ടപ്പെടുത്തുന്ന കേസ് കൊടുമുടിയാണ്. തുടർന്ന് പേജ് ലോഡ് ചെയ്തോ എന്നതിൽ നിന്ന് അനുമാനിക്കുന്നതിനുപകരം ഓരോ അഭ്യർത്ഥനയും യഥാർത്ഥത്തിൽ ഏത് പാതയിലൂടെ പോയി എന്ന് സ്ഥിരീകരിക്കുക.

അവസാനമായി, പരാജയ ശാഖ പരിശോധിക്കുക. എത്തിച്ചേരാൻ കഴിയാത്ത ഒരു പ്രോക്സി നിങ്ങൾ മുൻകൂട്ടി തീരുമാനിച്ച രീതിയിൽ പരാജയപ്പെടണം, നിശബ്ദമായി നേരിട്ടുള്ള കണക്ഷനിലേക്ക് മടങ്ങരുത്. നെറ്റ്വർക്ക് ഓപ്ഷനുകളുടെ റഫറൻസ് റൂട്ട് പാരാമീറ്ററുകൾ കൃത്യമായി രേഖപ്പെടുത്തുന്നു; ഈ രൂപകൽപ്പനയുടെ ഡൊമെയ്ൻ പകുതി അതിന് പുറത്താണ്.