StrongSwan Mac എത്തിച്ചേരാൻ കഴിയാത്ത DNS വിലാസം അയയ്ക്കുന്നു

ആരെങ്കിലും ഒരു MacBook തുറക്കുന്നതുവരെ എല്ലാം പ്രവർത്തിക്കുന്നു. ടണൽ സ്ഥാപിക്കപ്പെടുന്നു, ആന്തരിക ഹോസ്റ്റുകൾ വിലാസം കൊണ്ട് ഉത്തരം നൽകുന്നു, എന്നാൽ പേര് റെസല്യൂഷൻ മരിക്കുന്നു. iPhone-ൽ അതേ പ്രൊഫൈൽ അതേ രീതിയിൽ പെരുമാറുന്നു, അതേസമയം Windows, Linux ക്ലയന്റുകൾ കുഴപ്പമില്ല. സാധാരണയായി അയയ്ക്കുന്ന DNS ആട്രിബ്യൂട്ടാണ് കുറ്റക്കാരൻ: സെർവർ തന്റെ സ്വന്തം പൊതു ഇന്റർഫേസ് വിലാസം വിതരണം ചെയ്യുന്നു, Apple-ന്റെ IKEv2 ക്ലയന്റ് ടണലിലൂടെ അങ്ങോട്ട് ക്വറികൾ അയയ്ക്കുന്നില്ല. റിസോൾവർ പൂളിനുള്ളിലേക്ക് മാറ്റുക, ക്ലയന്റിനെ തൊടാതെ തന്നെ ലക്ഷണം അപ്രത്യക്ഷമാകും.

ലക്ഷണം അയച്ച വിലാസത്തെ ചൂണ്ടുന്നു

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

പൊതു വിലാസമാണ് സാധാരണ തിരഞ്ഞെടുപ്പ്, കാരണം അഡ്മിനിസ്ട്രേറ്റർക്ക് ഇതിനകം അറിയാവുന്ന ഒരേയൊരു വിലാസം അതാണ്. ടണലിന്റെ സ്വന്തം പ്രിഫിക്സിന് പുറത്താണെന്ന് ഉറപ്പുള്ള ഒരേയൊരു വിലാസവുമാണ് അത്, ആ ഗുണമാണ് Apple ക്ലയന്റുകളെ തകർക്കുന്നത്.

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

ലീസ് ശ്രേണിയിൽ നിന്ന് റിസോൾവർ വെട്ടിയെടുക്കുക

റിസോൾവർ പൂളിന്റെ സ്വന്തം സബ്നെറ്റിലെ അംഗമാകുന്ന ഒരു വിലാസ പദ്ധതി ടണലിന് നൽകുക, തുടർന്ന് ആ വിലാസം റിസർവ് ചെയ്യുക, ഒരു ക്ലയന്റിനും ഒരിക്കലും ലീസ് നൽകാതിരിക്കാൻ. ഈ ഉദാഹരണത്തിൽ പൂൾ 10.180.7.0/24 ആണ്, സെർവർ 10.180.7.1 പിടിക്കുന്നു, ലീസുകൾ 10.180.7.2 മുതൽ തുടങ്ങുന്നു.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

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

ഇതിന് സെർവറിന് പുതിയ ഭൗതിക ഇന്റർഫേസ് ആവശ്യമില്ല. ലൂപ്പ്ബാക്ക് ഇന്റർഫേസിൽ 10.180.7.1 ചേർത്താൽ റിസോൾവറിന് ബൈൻഡ് ചെയ്ത് ഉത്തരം നൽകാൻ മതി, കാരണം ക്ലയന്റുകൾ ഇതിനകം നിലവിലുള്ള പൂൾ റൂട്ടിലൂടെ അങ്ങോട്ട് എത്തുന്നു. വിലാസം ലീസ് ശ്രേണിക്ക് പുറത്ത് സൂക്ഷിക്കുക, ഒരു ക്ലയന്റും അബദ്ധത്തിൽ അത് എടുക്കാതിരിക്കാൻ. പൂൾ ബാഹ്യ DHCP അല്ലെങ്കിൽ RADIUS സേവനം കൈകാര്യം ചെയ്യുന്നുവെങ്കിൽ, അവിടെയും വിലാസം റിസർവ് ചെയ്യുക, അല്ലെങ്കിൽ ആദ്യം ചോദിക്കുന്ന ക്ലയന്റ് അത് എടുക്കും.

റിസോൾവർ ബൈൻഡ് ചെയ്ത് പോർട്ട് 53 അടയ്ക്കുക

വിലാസം അനുവദിക്കുന്നതും അതിൽ കേൾക്കുന്നതും ഒന്നല്ല. LAN വിലാസത്തിൽ മാത്രം കേൾക്കുന്ന റിസോൾവർ പൂൾ വിലാസത്തിലേക്ക് അയച്ച ക്വറികൾ നിരസിക്കുകയോ അവഗണിക്കുകയോ ചെയ്യും, ക്ലയന്റ് റൂട്ടിംഗ് പരാജയം പോലെ തോന്നിക്കുന്ന ടൈംഔട്ട് കാണും.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

ഈ unbound ശകലം ടണൽ പൂളിൽ നിന്നുള്ള ക്വറികൾ സ്വീകരിച്ച് ബാക്കിയെല്ലാം നിരസിക്കുന്നു, മിക്ക കോർപ്പറേറ്റ് റിസോൾവറുകളും ആഗ്രഹിക്കുന്ന നയമാണത്. അതേ ഇൻസ്റ്റൻസ് LAN ക്ലയന്റുകൾക്കും ഉത്തരം നൽകുന്നുവെങ്കിൽ, ശ്രോതാവിനെ എല്ലാ ഉറവിടങ്ങളിലേക്കും വിപുലീകരിക്കുന്നതിന് പകരം LAN പ്രിഫിക്സ് വ്യക്തമായി ചേർക്കുക.

തുടർന്ന് ഫയർവാൾ നിയമങ്ങൾ റിസോൾവറിന്റെ സ്വന്തം ആക്സസ് നിയന്ത്രണവുമായി യോജിക്കണം. പൂളിൽ നിന്ന് പോർട്ട് 53 സ്വീകരിക്കുക, മറ്റെല്ലായിടത്തും അത് വലിച്ചെറിയുക, പക്ഷേ ആദ്യം ചെയിനിന്റെ ക്രമം പരിശോധിക്കുക.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

ക്ലയന്റ് യഥാർത്ഥത്തിൽ എന്താണ് ലഭിച്ചതെന്ന് പരിശോധിക്കുക

ആദ്യം സെർവറിന്റെ കാഴ്ചപ്പാട്, പിന്നെ ക്ലയന്റിന്റേത് പരിശോധിക്കുക, കാരണം രണ്ടും വിവരദായകമായി വ്യത്യാസപ്പെടുന്നു. പൂൾ ലിസ്റ്റ് ഏത് വിലാസമാണ് ലീസ് നൽകിയതെന്ന് കാണിക്കുന്നു, സെക്യൂരിറ്റി അസോസിയേഷനുകളുടെ ലിസ്റ്റ് കണക്ഷൻ പ്രതീക്ഷിച്ച ഐഡന്റിറ്റിയോടെ ഉയർന്നിട്ടുണ്ടോ എന്ന് കാണിക്കുന്നു.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

നേരിട്ടുള്ള ക്വറി, റിസോൾവർ പൂൾ വിലാസത്തിൽ അങ്ങോട്ട് എത്താൻ കഴിയുന്ന ഒരു ഹോസ്റ്റിൽ നിന്ന് ഉത്തരം നൽകുന്നു എന്ന് തെളിയിക്കുന്നു. Mac ആ സെർവർ തിരഞ്ഞെടുത്തു എന്ന് അത് തെളിയിക്കുന്നില്ല. macOS-ൽ scutil --dns സ്കോപ്പ് ചെയ്ത സേവനത്തിന് റിസോൾവറുകൾ ലിസ്റ്റ് ചെയ്യുന്നു, സംഗ്രഹ പാനലിനേക്കാൾ വിവരദായകമാണ്; Windows-ൽ Get-DnsClientServerAddress ടണൽ അഡാപ്റ്റർ അയച്ച മൂല്യം സ്വീകരിച്ചോ എന്ന് കാണിക്കുന്നു.

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