ഗേറ്റ്വേയിൽ OpenVPN DNS: dnsmasq ഒപ്പം ഫയർവാളിന്റെ പരിധി

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

ശ്രോതാവ് രണ്ട് ദിശകളുള്ള ഒരു പ്രാദേശിക സേവനമാണ്

അകത്തേക്ക്, ക്ലയന്റ് ഗേറ്റ്വേയുടെ ടണൽ വിലാസത്തിലേക്ക് പോർട്ട് 53-ൽ ഒരു ക്വറി അയയ്ക്കുന്നു. പുറത്തേക്ക്, ഡീമൺ ആ ക്വറി അതിന്റെ കോൺഫിഗർ ചെയ്ത അപ്സ്ട്രീമിലേക്ക് കൈമാറുന്നു. രണ്ട് പകുതികളും പ്രവർത്തിക്കണം, അവ വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു.

ക്ലയന്റ് റിപ്പോർട്ട് ചെയ്യുന്ന ടൈംഔട്ടും ഗേറ്റ്വേയിൽ കാണുന്ന ടൈംഔട്ടും ഒരേ തകരാറല്ല.

ടണൽ വിലാസം ബന്ധിപ്പിക്കുക, എല്ലാ വിലാസവുമല്ല

ഈ ജോലിക്കായി പ്രത്യേകമുള്ള ഒരു dnsmasq ഇൻസ്റ്റൻസിന് വ്യക്തമായ ശ്രവണ വിലാസം, ആരംഭത്തിനുശേഷം ടണൽ പ്രത്യക്ഷപ്പെടുന്നത് സഹിക്കുന്ന ഒരു ബൈൻഡ് മോഡ്, ഒരു വ്യക്തമായ അപ്സ്ട്രീം എന്നിവ വേണം. ഞാൻ ഉപയോഗിക്കുന്ന ഏറ്റവും ചെറിയ പതിപ്പ് ഇതാണ്:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic വ്യക്തിഗത വിലാസങ്ങൾ ബന്ധിപ്പിക്കുകയും tun0 പിന്നീട് പ്രത്യക്ഷപ്പെടുമ്പോൾ കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു, VPN സേവനം പുനരാരംഭിക്കുന്ന ഹോസ്റ്റിൽ ഇത് പ്രധാനമാണ്. loopback ലിസ്റ്റ് ചെയ്യുന്നത് പൊതു ശ്രോതാവ് ചേർക്കാതെ പ്രാദേശിക ഉപകരണങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നു. no-resolv ഹോസ്റ്റിന്റെ റിസോൾവർ കോൺഫിഗറേഷനിൽനിന്ന് അപ്സ്ട്രീമുകൾ പാരമ്പര്യമായി സ്വീകരിക്കുന്നതിൽനിന്ന് ഡീമണെ തടയുന്നു, no-hosts ഈ ഇൻസ്റ്റൻസ് ഗേറ്റ്വേയുടെ hosts ഫയൽ പ്രസിദ്ധീകരിക്കുന്നത് തടയുന്നു. ഈ ഓപ്ഷനുകളിൽ ഒന്നും ആർക്കും സേവനം ക്വറി ചെയ്യാനുള്ള അനുമതി നൽകുന്നില്ല.

രണ്ടാമത്തെ ഡീമൺ ആരംഭിക്കുന്നതിന് മുമ്പ് പോർട്ട് 53-ൽ ഇതിനകം ഉള്ള ശ്രോതാവ് ഉണ്ടോ എന്ന് പരിശോധിക്കുക, തെറ്റായ ഡയറക്ടറിയിലെ അലഞ്ഞുതിരിയുന്ന ഫയലിനുപകരം വിതരണത്തിന്റെ കോൺഫിഗറേഷൻ ഉടമയെ ഉപയോഗിക്കുക.

DNS ഇൻപുട്ട് അനുവദിക്കുക, ടണൽ ട്രാൻസിറ്റല്ല

ഇത് പ്രവർത്തിപ്പിക്കുന്ന ഫയർവാൾ നിയമങ്ങൾ ടണൽ ഇന്റർഫേസ്, ക്ലയന്റ് പൂൾ, ഗേറ്റ്വേ വിലാസം, പോർട്ട് 53 എന്നിവയിൽ പരിമിതപ്പെടുത്തിയ പ്രാദേശിക-ഇൻപുട്ട് നിയമങ്ങളാണ്. ഓരോ പ്രോട്ടോക്കോളിനും ഒന്നുവീതം രണ്ട് നിയമങ്ങൾ മതി:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP-ക്കൊപ്പം TCP-യിലൂടെയും പ്രവർത്തിക്കുന്നു, അതിനാൽ UDP മാത്രമുള്ള നിയമം വലിയ ഉത്തരങ്ങൾ ഇടയ്ക്കിടെ എന്നു തോന്നുന്ന രീതിയിൽ പരാജയപ്പെടാൻ വിടുന്നു. ഇവ ufw route അനുമതികളല്ല, അവ tun0 -ൽ വിശാലമായ അനുമതിയാകരുത്. ക്രമം ഉള്ളടക്കത്തോളം പ്രധാനമാണ്: tun0 -ൽനിന്ന് എല്ലാ ഇൻപുട്ടും ഉപേക്ഷിക്കുന്ന മുൻ നിയമം ഇപ്പോഴും വിജയിക്കുന്നു, അന്തിമ ഡ്രോപ്പിന് താഴെ അനുമതി ചേർക്കുന്നത് ഒന്നും സൃഷ്ടിക്കുന്നില്ല.

ഗേറ്റ്വേ DNS ഇപ്പോൾ ഡിസൈനിന്റെ ഭാഗമാണെങ്കിൽ, ആ മുൻ നയം ബോധപൂർവം പരിശോധിച്ച് കാരണം രേഖപ്പെടുത്തുക.

അപ്സ്ട്രീം പകുതി വേറിട്ട ഒരു പാതയാണ്

ക്വറികൾ ഗേറ്റ്വേയിൽനിന്ന് അതിന്റെ സ്വന്തം വിലാസത്തിൽനിന്ന് അപ്സ്ട്രീം റിസോൾവറിലേക്ക് പുറപ്പെടുന്നു, അതിനാൽ ഗേറ്റ്വേയുടെ റൂട്ടും ആ റിസോൾവറിലേക്കുള്ള ഔട്ട്പുട്ട് നയവും ഈ കൈമാറ്റം അനുവദിക്കണം. ഇത് ക്ലയന്റുകളെ ശ്രോതാവിലെത്തിക്കുന്ന നിയമത്തിൽനിന്ന് വ്യത്യസ്തമാണ്, വ്യത്യസ്ത ലക്ഷണത്തോടെ പരാജയപ്പെടുന്നു.

ഉത്തരങ്ങൾ പ്രവർത്തിക്കാൻ പരിധിയില്ലാത്ത ടണൽ ഔട്ട്പുട്ട് ചേർക്കരുത്; ട്രാക്ക് ചെയ്യുന്ന ഉത്തരങ്ങൾക്ക് അത് ആവശ്യമില്ല.

ഓപ്ഷൻ പുഷ് ചെയ്യുക, പിന്നീട് ഹാൻഡോഫ് പരിശോധിക്കുക

പുഷ് ചെയ്ത ഓപ്ഷൻ ഉപയോഗിച്ച് സർവറിന് റിസോൾവർ ക്ലയന്റുകളെ അറിയിക്കാം. അത് ഒരു ഓപ്ഷനാണ്, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അനുസരിക്കേണ്ട നിർദ്ദേശമല്ല:

push "dhcp-option DNS 10.90.0.1"

കമാൻഡ് ലൈൻ Linux ക്ലയന്റിന് അതിന്റെ കണക്ഷൻ മാനേജറുടെ റിസോൾവർ സംയോജനം ആവശ്യമായേക്കാം, മാനേജ് ചെയ്യുന്ന ഉപകരണത്തിന് പുതുക്കിയ മാനേജ്മെന്റ് പ്രൊഫൈൽ ആവശ്യമായേക്കാം. കണക്ട് ചെയ്തതിനുശേഷം ക്ലയന്റിലെ സജീവ റിസോൾവർ സ്ഥിരീകരിക്കുക, പുഷ് പ്രയോഗിച്ചു എന്ന് അനുമാനിക്കുന്നതിനുപകരം. രണ്ട് സംവിധാനങ്ങൾ ഒരേസമയം DNS സജ്ജമാക്കാൻ ശ്രമിക്കുമ്പോൾ, ഇടയ്ക്കിടെ മാറുന്ന റെസല്യൂഷൻ പോലെ തോന്നുന്ന ഒരു മത്സരം ഉണ്ടാകുന്നു.

ക്ലയന്റിന്റെ റിസോൾവർ കോൺഫിഗറേഷന് ഒരു ഉടമ മാത്രമായിരിക്കുക എന്നതാണ് ലക്ഷ്യം, പുഷ് സാധാരണയായി ആ ഉടമയാകുന്നത് ക്ലയന്റ് പ്ലാറ്റ്ഫോം സമ്മതിക്കുമ്പോൾ മാത്രമാണ്.

നിങ്ങൾ യഥാർത്ഥത്തിൽ നിർമ്മിച്ചത് പരിശോധിക്കുക

ഒരു സ്വകാര്യ പൂർണ്ണ യോഗ്യതയുള്ള പേരും ഒരു അനുവദനീയമായ ബാഹ്യ പേരും നേരിട്ട് ടണൽ വിലാസത്തിനെതിരെ, UDP-യിലും TCP-യിലും ക്വറി ചെയ്യുക. തുടർന്ന് അപ്ലിക്കേഷന്റെ സാധാരണ ലുക്കപ്പ് പാതയിലൂടെ ആവർത്തിക്കുക.

നേരിട്ടുള്ള ക്വറികൾ പ്രവർത്തിക്കുകയും അപ്ലിക്കേഷൻ ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്താൽ, തകരാർ സർവറിലല്ല, ഹാൻഡോഫിലാണ്:

• ക്ലയന്റ് പുഷ് ചെയ്ത ഓപ്ഷൻ ഒരിക്കലും പ്രയോഗിച്ചില്ല.
• പിന്നീട് മറ്റൊരു റിസോൾവർ സജ്ജമാക്കി, അത് മത്സരത്തിൽ വിജയിച്ചു.
• അപ്ലിക്കേഷൻ അതിന്റെ സ്വന്തം റിസോൾവർ ലൈബ്രറി അല്ലെങ്കിൽ കാഷെ ചെയ്ത ഉത്തരം ഉപയോഗിക്കുന്നു.

അംഗീകൃത VPN പാതയ്ക്ക് പുറത്തുള്ള ഒരു ഉറവിടത്തിന് ശ്രോതാവ് ഉപയോഗിക്കാൻ കഴിയില്ല എന്ന് സ്ഥിരീകരിച്ച് അവസാനിപ്പിക്കുക. വിജയകരമായ റെസല്യൂഷൻ തിരികെ നൽകിയ വിലാസത്തിന് അധികാരം നൽകുന്നില്ല, അതിനാൽ ഈ രണ്ട് ചോദ്യങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുക.