Pritunl-ന്റെ സ്വകാര്യ DNS പരാജയപ്പെടുന്നോ? ഇടുങ്ങിയ ഒരു resolver റൂട്ട് ചേർക്കുക

സ്വകാര്യ നാമങ്ങൾ കോർപ്പറേറ്റ് നെറ്റ്വർക്കിൽ എല്ലാവർക്കും പരിഹരിക്കപ്പെടുന്നു, VPN-ൽ എല്ലാവർക്കും സമയം കഴിയുന്നു. Resolver ഗേറ്റ്വേയ്ക്ക് ഉത്തരം നൽകുന്നു, അങ്ങോട്ടുള്ള റൂട്ട് നിലവിലുണ്ട്, എന്നിട്ടും ക്വറിക്ക് ഒരിക്കലും ഉത്തരം ലഭിക്കുന്നില്ല. കുറവായിരിക്കുന്നത് മറ്റൊരു പൊതു resolver അല്ല അല്ലെങ്കിൽ വിശാലമായ റൂട്ടല്ല: സ്വകാര്യ DNS സർവറിന് ഉത്തരം നൽകാൻ തയ്യാറുള്ള ഉറവിട വിലാസമാണ്.

നിങ്ങളുടെ ക്ലയന്റ് പൂൾ resolver നിരസിക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക

പരാജയം ലഭ്യതയല്ല, ഉറവിടത്തെക്കുറിച്ചാണെന്ന് തെളിയിച്ചുകൊണ്ട് തുടങ്ങുക. കണക്ട് ചെയ്ത ക്ലയന്റിൽ നിന്ന് സ്വകാര്യ resolver-നോട് നേരിട്ട് ക്വറി ചെയ്ത്, അഭ്യർത്ഥന സമയം കഴിയുന്നുണ്ടോ നിരസനമായി മടങ്ങുന്നുണ്ടോ എന്ന് നിരീക്ഷിക്കുക. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 സമയം കഴിയുമ്പോൾ ഗേറ്റ്വേയിൽ നിന്നുള്ള അതേ ക്വറി വിജയിക്കുന്നത് resolver-ലെ ഒരു ആക്സസ് നയത്തെ സൂചിപ്പിക്കുന്നു. SERVFAIL ഉത്തരം തികച്ചും വേറെയൊരിടത്തേക്ക്, സാധാരണയായി സോണിലേക്കോ മുകളിലെ ഫോർവേർഡറിലേക്കോ സൂചിപ്പിക്കുന്നു.

പരീക്ഷിക്കുന്നതിന് മുമ്പ് ക്ലയന്റിന്റെ വിലാസം രേഖപ്പെടുത്തുക. ക്ലയന്റിലെ ip -4 addr show tun0, അല്ലെങ്കിൽ കൺസോളിൽ കാണിച്ചിരിക്കുന്ന ലീസ്, resolver ഏത് പൂൾ കാണുന്നുവെന്ന് പറയുന്നു.

പിന്നീട് പാത നിലവിലുണ്ടോയെന്ന് സ്ഥിരീകരിക്കുക. Resolver-ന്റെ വിലാസം ടണലിലേക്ക് അയക്കുന്ന റൂട്ട് ഒരു മുൻവ്യവസ്ഥയാണ്, പരിഹാരമല്ല; പാക്കറ്റുകൾ ഒരിക്കലും എത്തിയില്ലെങ്കിൽ ഉറവിട നയം പരിശോധിക്കപ്പെടുന്നില്ല. ക്ലയന്റിൽ ip route get 10.40.0.53 ഉപയോഗിച്ച് അത് പരിശോധിക്കുക.

എല്ലാം വിവർത്തനം ചെയ്യുന്നതിനുപകരം ഒരു ഹോസ്റ്റ് റൂട്ട് ചേർക്കുക

Pritunl-ന്റെ സ്വകാര്യ DNS മാർഗ്ഗനിർദ്ദേശം ഇടുങ്ങിയ പരിഹാരം വിവരിക്കുന്നു: resolver വിലാസത്തിനായി NAT സജീവമായ /32 റൂട്ട്, ആ വിലാസം ക്ലയന്റുകളുടെ DNS സർവറായി തിരഞ്ഞെടുത്ത്. DNS ട്രാഫിക്കിന് മാത്രമാണ് റൂട്ട് resolver കാണുന്ന ഉറവിടത്തെ മാറ്റുന്നത്. ആപ്ലിക്കേഷൻ ട്രാഫിക് അതിനായി നിങ്ങൾ തിരഞ്ഞെടുത്ത ഉറവിട-സംരക്ഷണ രൂപകൽപ്പന നിലനിർത്തുന്നു.

നിലവിലുള്ള റൂട്ടുകൾ ഓവർലാപ്പിനായി പരിശോധിച്ച ശേഷം, സർവറിന്റെ പിന്തുണയുള്ള റൂട്ട് ഉടമയിലൂടെ അത് കോൺഫിഗർ ചെയ്യുക. മുകളിലെ ഉദാഹരണത്തിൽ ലക്ഷ്യം NAT സജീവമായ 10.40.0.53/32 ആണ്, ക്ലയന്റ് പൂൾ 10.90.0.0/24 ആയി തുടരുന്നു. ഒരു സേവനം ശരിയാക്കാൻ മുഴുവൻ സ്വകാര്യ ശ്രേണിയും വിവർത്തനം ചെയ്യരുത്, കാരണം ക്ലയന്റിന്റെ യഥാർത്ഥ വിലാസത്തെ ആശ്രയിക്കുന്ന ഓരോ ഡൗൺസ്ട്രീം നയവും പകരം ഗേറ്റ്വേ കാണാൻ തുടങ്ങും. പരീക്ഷണ തിരയലിനിടയിൽ resolver-ന്റെ ക്വറി ലോഗ് നിരീക്ഷിച്ച് അത് യഥാർത്ഥത്തിൽ സ്വീകരിക്കുന്ന വിലാസം സ്ഥിരീകരിക്കുക. ഒരു ഹോസ്റ്റ് റൂട്ട് മാത്രം വിവർത്തനത്തെയോ അനുമതിയെയോ കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

UDP-യിലും TCP-യിലും വിവർത്തനം ചെയ്ത ഉറവിടം resolver ഇപ്പോഴും അനുവദിക്കണം, അതിന്റെ ഉത്തരങ്ങൾക്ക് മടങ്ങാൻ കഴിയണം. ഉറവിടം മാറ്റുന്നത് കാണാത്ത ഒരു സോണോ റെക്കോർഡോ സൃഷ്ടിക്കാൻ കഴിയില്ല.

ക്വറി സർവർ അയക്കുന്നുണ്ടോ ക്ലയന്റ് അയക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുക

VPN Client DNS Mapping-മായി ബന്ധിപ്പിച്ച ഒരു DNS-പ്രോക്സി ക്രമീകരണവും Pritunl രേഖപ്പെടുത്തുന്നു, അവിടെ സർവർ ക്ലയന്റുകൾക്കുവേണ്ടി മുകളിലെ ക്വറികൾ ഫോർവേഡ് ചെയ്യുന്നു. ആ മാതൃകയിൽ മുകളിലെ ഉറവിടം സർവറിന്റെ സ്വന്തം നെറ്റ്വർക്ക് സന്ദർഭത്തിനുള്ളതാണ്, ക്ലയന്റ് ഭാഗത്തെ ഒഴിവ് തെറ്റായ പരിഹാരമാണ്.

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

പൊതു വെബ് പേജല്ല, സ്വകാര്യ തിരയൽ പരീക്ഷിക്കുക

മാറ്റം പ്രയോഗിച്ച് വീണ്ടും കണക്ട് ചെയ്ത ശേഷം, ക്ലയന്റിന്റെ ഫലപ്രദമായ resolver കോൺഫിഗറേഷൻ പരിശോധിക്കുക, തുടർന്ന് സ്വകാര്യ സോണിൽ മാത്രം നിലവിലുണ്ടെന്ന് നിങ്ങൾക്കറിയാവുന്ന ഒരു നാമം പരിഹരിക്കുക. വ്യക്തമായ സർവറില്ലാതെ dig intranet.example.net ക്ലയന്റ് യഥാർത്ഥത്തിൽ എന്താണ് ഉപയോഗിക്കുന്നതെന്ന് കാണിക്കുന്നു. തുടർന്ന് ആ തിരയൽ മടക്കി നൽകിയ വിലാസത്തിലേക്ക് അഭ്യർത്ഥന അയക്കുക, കാരണം പരിഹരിക്കലും സേവന ആക്സസും വെവ്വേറെ ഘട്ടങ്ങളാണ്. DNS-over-HTTPS വഴി പൊതു സൈറ്റുകൾ ലോഡ് ചെയ്യുന്ന ബ്രൗസർ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ സ്വകാര്യ resolver പാതയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. പൊതു ദ്വിതീയ resolver-ഉം ആന്തരിക സോണിന് അധികാരമല്ല.

resolver വിലാസം, /32 റൂട്ട്, ക്ലയന്റ് DNS ക്രമീകരണം എന്നിവ ഒരുമിച്ച് സർവർ കുറിപ്പുകളിൽ രേഖപ്പെടുത്തുക. ആ കോൺഫിഗറേഷന്റെ പകുതി മാത്രം പുനഃസ്ഥാപിച്ചാൽ യഥാർത്ഥ പരാജയം ആവർത്തിക്കുന്നു.

അവസാനമായി, DNS വിജയിച്ചതിന് ശേഷവും ടണൽ ആപ്ലിക്കേഷൻ ലക്ഷ്യത്തിലേക്ക് റൂട്ട് ചെയ്യുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക. റൂട്ട്, സേവന ആക്സസ്, പ്രാമാണീകരണം എന്നിവ നാമ പരിഹരണത്തിൽ നിന്ന് സ്വതന്ത്രമായി തുടരുന്നു, പ്രവർത്തിക്കുന്ന തിരയൽ ത്രൂപുട്ടിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. സ്വകാര്യ പേജ് മന്ദഗതിയിലാണെങ്കിലും പരിഹരിക്കപ്പെടുന്നുവെങ്കിൽ, resolver തന്റെ ജോലി ചെയ്തു, പ്രശ്നം പാതയിലേക്ക് നീങ്ങി.