dnsmasq-ൽ OpenVPN ക്ലയന്റ് നാമങ്ങൾ: സ്ക്രിപ്റ്റോ സ്ഥിര എൻട്രികളോ?
ക്ലയന്റ് വിലാസങ്ങൾ മാറുന്നു, സേവന നാമങ്ങൾ മാറുന്നില്ല. VPN സെഷനിൽ നിന്ന് ക്ലയന്റ് നാമങ്ങൾ സൃഷ്ടിക്കുക, drop-in ഫയലിൽ സേവന നാമങ്ങൾ ഉറപ്പിക്കുക, പിന്നീട് ക്ലയന്റുകളെ അത് ഉപയോഗിപ്പിക്കുക.
ഏതാണ്ട് എല്ലാ ചെറിയ OpenVPN ഗേറ്റ്വേയിലും രണ്ട് നാമ പ്രശ്നങ്ങൾ ഉയരുന്നു. ബന്ധിപ്പിച്ച ലാപ്ടോപ്പിൽ അതിന്റെ സർട്ടിഫിക്കറ്റിലെ നാമം ഉപയോഗിച്ച് എത്താൻ കഴിയില്ല, ടണലിന് പിന്നിലെ സേവനങ്ങൾക്ക് നാമങ്ങളേ ഇല്ല. ഒരു പ്രശ്നം പോലെ തോന്നുമെങ്കിലും വിപരീത പരിഹാരമാണ് വേണ്ടത്, കാരണം ഒരു വിലാസം ഓരോ സെഷനിലും മാറുന്നു, മറ്റൊന്ന് മാറുന്നില്ല. എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ് ഏത് തരം നാമമാണ് ചേർക്കുന്നതെന്ന് തീരുമാനിക്കുക.
ഗേറ്റ്വേ അനുസരിച്ചല്ല, നാമം അനുസരിച്ച് തീരുമാനിക്കുക
പരിശോധന ലളിതമാണ്: ക്ലയന്റ് വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ ഈ വിലാസം മാറുന്നുണ്ടോ? ഉണ്ടെങ്കിൽ നാമം VPN സെഷനിൽ നിന്ന് സൃഷ്ടിക്കണം. ഇല്ലെങ്കിൽ അത് നിങ്ങൾക്ക് വായിച്ച് പരിശോധിക്കാവുന്ന ഒരു സ്ഥിര എൻട്രിയിൽ പെടുന്നു.
| Name kind | Source of truth | Where it lives |
|---|---|---|
| Connected client | The address OpenVPN just assigned | Generated hosts file, rewritten per session |
| Service behind the tunnel | A fixed address you chose | Static address= drop-in |
| Anything with a certificate name | The certificate, not the pool | Either, but the name must match the certificate |
രണ്ടും കലർത്തുന്നതാണ് സാധാരണ പരാജയം. സൃഷ്ടിച്ച ഫയലിൽ ഉറപ്പിച്ച സേവനം സ്ക്രിപ്റ്റ് ആദ്യമായി അത് വീണ്ടും എഴുതുമ്പോൾ അപ്രത്യക്ഷമാകുന്നു, സ്ഥിര എൻട്രിയിൽ എഴുതിയ ക്ലയന്റ് ആ വിലാസം അവസാനം കൈവശം വച്ചവനെ ചൂണ്ടുന്നു. രണ്ട് പിഴവുകളും നാമം തെറ്റായ യന്ത്രത്തിലേക്ക് പരിഹരിക്കുന്നതുവരെ അദൃശ്യമായിരിക്കും. അപ്പോഴേക്കും ഡീബഗ് ചെയ്യുന്നയാൾ DNS കേടായി എന്നാണ് കരുതുന്നത്, ഫയലല്ല.
ചലനാത്മക പാത: learn-address ഉം പൂളും
OpenVPN അനുവദനം അറിയുന്നു, അതിനാൽ അത് പറയട്ടെ. ഈ സെർവർ ഓപ്ഷനുകൾ അനുവദനം ദീർഘകാലവും സ്ക്രിപ്റ്റ് ചെയ്യാവുന്നതുമാക്കുന്നു:
client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.shlearn-address ഒരു വിലാസം ചേർക്കുകയോ പുതുക്കുകയോ ഇല്ലാതാക്കുകയോ ചെയ്യുമ്പോഴെല്ലാം നിങ്ങളുടെ സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നു, ഓപ്പറേഷനും വിലാസവും പൊതു നാമവും കൈമാറുന്നു. ഏറ്റവും ചെറിയ സ്ക്രിപ്റ്റ് ഓരോ ക്ലയന്റിനും ഒരു വരി ചേർക്കുകയും ഇല്ലാതാക്കുമ്പോൾ അത് നീക്കുകയും ചെയ്യുന്നു:
#!/bin/sh
HOSTS=/etc/openvpn/hosts.lan
case "$1" in
add|update) echo "$2 $3" >> "$HOSTS" ;;
delete) sed -i "/^$2 /d" "$HOSTS" ;;
esac
kill -HUP $(cat /var/run/dnsmasq.pid)
tun ഉപകരണത്തിൽ രണ്ടാമത്തെ ആർഗ്യുമെന്റ് ക്ലയന്റിന്റെ ടണൽ വിലാസമാണ്, അതിനാൽ വരി നേരിട്ട് ഉപയോഗിക്കാം. tap ഉപകരണത്തിൽ OpenVPN പകരം ക്ലയന്റിന്റെ MAC വിലാസം കൈമാറുന്നു, കാരണം tap സെഗ്മെന്റിന് IPv4 അല്ലാത്ത പ്രോട്ടോക്കോളുകളും വഹിക്കാം, അപ്പോൾ എന്തെങ്കിലും എഴുതുന്നതിന് മുമ്പ് പൂൾ ഫയലിൽ പൊതു നാമം ഉപയോഗിച്ച് വിലാസം കണ്ടെത്തണം.
സൃഷ്ടിച്ച ഫയൽ എന്താണെന്ന് വ്യക്തമാക്കുക: ഇപ്പോൾ ആരാണ് ബന്ധിപ്പിച്ചിരിക്കുന്നത് എന്നതിന്റെ സ്നാപ്ഷോട്ട്. വിച്ഛേദിക്കുമ്പോൾ നാമങ്ങൾ അപ്രത്യക്ഷമാകുന്നു, ഇത് നെറ്റ്വർക്കുകൾക്കിടയിൽ സഞ്ചരിക്കുന്ന ലാപ്ടോപ്പുകൾക്ക് കൃത്യമായി നിങ്ങൾ ആഗ്രഹിക്കുന്നതും രാത്രി മുഴുവൻ ഓണായിരിക്കുന്ന സെർവറിന് കൃത്യമായി നിങ്ങൾ ആഗ്രഹിക്കാത്തതുമാണ്.
സ്ഥിര പാത: address= ഉം ഡൊമെയിൻ വിപുലീകരണവും
സിസ്റ്റത്തിന്റെ hosts ഫയലിന് പകരം dnsmasq സൃഷ്ടിച്ച ഫയലിലേക്ക് തിരിച്ചുവിടുക, ചെറിയ നാമങ്ങൾ പൂർണ്ണ യോഗ്യതയുള്ള നാമങ്ങളായി വികസിക്കാൻ അതിന് ഒരു ഡൊമെയിൻ നൽകുക:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfacesdomain സെറ്റ് ചെയ്യുമ്പോൾ, 10.8.0.6 alice പോലുള്ള ഒരു വരി alice നും alice.corp.example നും ഉത്തരം നൽകുന്നു. listen-address ടണൽ ഗേറ്റ്വേയിലും loopback-ലും മാത്രം ഒതുക്കുക, കാരണം LAN ഇന്റർഫേസിൽ അബദ്ധത്തിൽ പ്രസിദ്ധീകരിച്ച റിസോൾവർ നൽകാൻ ഉദ്ദേശിക്കാത്ത ഒരു സേവനമാണ്.
പൂളിൽ നിന്ന് ഒരിക്കലും വരാത്ത സേവനങ്ങൾക്ക് സ്വന്തം എൻട്രികൾ ലഭിക്കും. പാക്കേജ് അപ്ഗ്രേഡിന് അവ മേലെഴുതാൻ കഴിയാതിരിക്കാൻ വിതരണത്തിന്റെ കോൺഫിഗറേഷൻ ഡയറക്ടറിയിൽ പ്രത്യേക drop-in ഫയലിൽ അവ ഇടുക:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5റിസോൾവർ കൈമാറുക, അല്ലെങ്കിൽ ഒന്നും സംഭവിക്കില്ല
ആരും ചോദിക്കാത്ത റിസോൾവർ ഒന്നും മാറ്റുന്നില്ല. സെർവർ അത് പ്രഖ്യാപിക്കണം:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"Windows ക്ലയന്റുകൾ രണ്ട് ഓപ്ഷനുകളും സ്വയം പ്രയോഗിക്കുന്നു. മിക്ക Linux ക്ലയന്റുകളും പ്രയോഗിക്കുന്നില്ല: അവയ്ക്ക് പിന്തുണയുള്ള റിസോൾവർ സംയോജനം ആവശ്യമാണ്, ഉദാഹരണത്തിന് വിതരണത്തിന്റെ update-resolv-conf ഹുക്ക് അല്ലെങ്കിൽ NetworkManager-ന്റെ DNS കൈകാര്യം ചെയ്യൽ, അല്ലെങ്കിൽ സ്വമേധയാ സജ്ജമാക്കിയ സെർച്ച് ഡൊമെയിനും നെയിംസെർവറും. push പാലിച്ചു എന്ന് കരുതുന്നതിന് പകരം ക്ലയന്റിന്റെ യഥാർത്ഥ റിസോൾവർ പരിശോധിക്കുക, കാരണം അവഗണിച്ച push ഉത്തരം നൽകാത്ത സെർവറിനെപ്പോലെ തന്നെ കാണപ്പെടുന്നു.
മൂന്ന് പാളികളിൽ പരിശോധിക്കുക
ആദ്യം സെർവറിനോട് നേരിട്ട് ചോദിക്കുക, പിന്നെ ഒരു ക്ലയന്റിനോട്, പിന്നെ അപ്ലിക്കേഷനോട്:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.exampleനേരിട്ടുള്ള ചോദ്യങ്ങൾ ഉത്തരം നൽകുകയും അപ്ലിക്കേഷൻ നൽകാതിരിക്കുകയും ചെയ്താൽ, കുറ്റം സോണിലല്ല, ക്ലയന്റിലേക്കുള്ള കൈമാറ്റത്തിലാണ്. നാമം പരിഹരിക്കപ്പെടുകയും ബന്ധം ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്താൽ, നാമം കൊള്ളാം, അടുത്ത് നോക്കേണ്ടത് റൂട്ട് അല്ലെങ്കിൽ ഫയർവാൾ ആണ്.
രണ്ട് വിഭാഗങ്ങളും കോൺഫിഗറേഷന് അരികിൽ എഴുതിവയ്ക്കുക: ഏത് നാമങ്ങൾ സൃഷ്ടിക്കപ്പെടുന്നു, ഏതാണ് ഉറപ്പിച്ചത്, ഓരോന്നും ഏത് സർട്ടിഫിക്കറ്റുമായി യോജിക്കണം. അടുത്തതായി ഒരു സെർവർ ചേർക്കുന്ന ആൾ ആദ്യം കണ്ട മാതൃക പകർത്തും.