AWS Client VPN DNS: subnet അല്ല, VPC resolver ഉപയോഗിക്കുക

endpoint 10.0.8.0/24-ൽ ആണ്, അതിനാൽ resolver 10.0.8.2 ആയിരിക്കണം. ഇതാണ് ഞാൻ ഏറ്റവും കൂടുതൽ കേൾക്കുന്ന ന്യായവാദം, അത് രണ്ടുതവണ തെറ്റാണ്. Route 53 Resolver പ്രൈമറി VPC IPv4 ശ്രേണിയിൽ പ്ലസ് രണ്ടിൽ ഉത്തരം നൽകുന്നു, അത് 10.0.0.0/16 ന്റെ VPC-യ്ക്ക് 10.0.0.2 ആണ്, endpoint ഏത് subnet ഉപയോഗിച്ചാലും. രണ്ടാമത്തെ പിശക് കൂടുതൽ നിശ്ശബ്ദമാണ്: endpoint-ൽ ശരിയായ വിലാസം ഇടുന്നത് client-ന്റെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അതിനോട് എപ്പോഴെങ്കിലും എന്തെങ്കിലും ചോദിക്കും എന്ന് അർത്ഥമാക്കുന്നില്ല. രണ്ട് പിശകുകളും ഒരേ ലക്ഷണം നൽകുന്നു: പേര് റെസല്യൂഷൻ ചില client-കളിൽ പ്രവർത്തിക്കുന്നു, മറ്റുള്ളവയിൽ പരാജയപ്പെടുന്നു.

കെട്ടുകഥ subnet അസോസിയേഷനിൽ തുടങ്ങുന്നു

അസോസിയേഷൻ client കണക്ഷനുകൾക്കുള്ള ഇലാസ്റ്റിക് നെറ്റ്വർക്ക് ഇന്റർഫേസുകൾ എവിടെയാണ് എന്നതിനെക്കുറിച്ചാണ്, ഏത് resolver വിലാസം നിലവിലുണ്ട് എന്നതിനെക്കുറിച്ചല്ല. endpoint-ന്റെ subnet-കൾ client-കൾക്ക് VPC-യ്ക്കുള്ളിൽ വിലാസം നൽകുന്നു, അവയിൽ ഓരോന്നും സ്വന്തം resolver വഹിക്കുന്നില്ല.

ആ രണ്ട് ആശയങ്ങൾ വേർതിരിച്ചാൽ, ഗണിതം രഹസ്യമായിരിക്കുന്നത് നിലയ്ക്കുന്നു, പ്രശ്നപരിഹാരം client-ലേക്ക് നീങ്ങുന്നു, ഈ കേസുകളിൽ ഭൂരിഭാഗവും യഥാർത്ഥത്തിൽ അവിടെയാണ് അവസാനിക്കുന്നത്.

പ്രൈമറി VPC ശ്രേണിയിൽ നിന്ന് വിലാസം കണക്കാക്കുക

VPC-യുടെ പ്രൈമറി IPv4 CIDR എടുത്ത് നെറ്റ്വർക്ക് വിലാസത്തിലേക്ക് രണ്ട് ചേർക്കുക. 10.0.0.0/16 10.0.0.2 നൽകുന്നു, 172.31.0.0/16 172.31.0.2 നൽകുന്നു, ദ്വിതീയ ശ്രേണിയുള്ള VPC resolver-നെ പ്രൈമറിയിൽ തന്നെ നിർത്തുന്നു. ആ VPC-യ്ക്കുള്ളിലെ 10.0.8.0/24 subnet അതിനെ നീക്കുന്നില്ല. endpoint-ൽ തൊടുന്നതിന് മുൻപ് VPC ID-യുടെ അടുത്ത് വിലാസം എഴുതുക, കാരണം ഈ സംഖ്യ VPC-യുടെ സ്വത്താണ്, കണക്ഷന്റേതല്ല.

VPC link-local വിലാസം 169.254.169.253-ലും ഉത്തരം നൽകുന്നു. ഈ വിലാസം VPC-യ്ക്കുള്ളിൽ നിന്ന് എത്താം, പക്ഷേ ടണലിന്റെ മറുവശത്തുള്ള ലാപ്ടോപ്പിന് ഇത് പൊതുവായി റൂട്ട് ചെയ്യപ്പെടുന്ന ലക്ഷ്യമല്ല.

അതിനാൽ രണ്ട് സാധുവായ resolver വിലാസങ്ങളുണ്ട്, അവയിൽ ഒന്നും subnet പ്ലസ് രണ്ട് അല്ല.

endpoint ക്രമീകരണം എന്ത് ചെയ്യുന്നു, എന്ത് ചെയ്യുന്നില്ല

Client VPN endpoint-ൽ DNS സെർവർ ഫീൽഡുകളുണ്ട്, കൺസോൾ VPC resolver ഓപ്ഷൻ നൽകുന്നിടത്ത് അതേ ആശയം നിറയ്ക്കുന്നു. അവ സെറ്റ് ചെയ്യുന്നത് കണക്ഷൻ സ്ഥാപിക്കുന്ന സമയത്ത് സേവനം client-കൾക്ക് എന്ത് നൽകുന്നു എന്നത് മാറ്റുന്നു. മാനേജ് ചെയ്യാത്ത OpenVPN client ആ മൂല്യവുമായി എന്ത് ചെയ്യുന്നു എന്നത് ഇത് മാറ്റുന്നില്ല, കാരണം client അത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ പ്രയോഗിക്കണം. «എന്റെ Mac-ൽ പ്രവർത്തിക്കുന്നു പക്ഷേ Linux ബോക്സിൽ ഇല്ല» എന്നത് ഈ വിടവിൽ നിന്നാണ് വരുന്നത്.

Linux-ൽ resolver സംയോജനം കണക്ഷൻ മാനേജറുടെ ഉടമസ്ഥതയിലാണ്, ഉപയോക്താവിന്റേതല്ല. /etc/resolv.conf കൈകൊണ്ട് എഡിറ്റ് ചെയ്യുന്നത് വിലാസം ഒരു സെഷന് പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, പിന്നെ വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ അപ്രത്യക്ഷമാകുന്നു — അതുകൊണ്ടാണ് ശരിയാക്കിയ പല കേസുകളും പിറ്റേന്ന് രാവിലെ തിരികെ വരുന്നത്.

കണക്ട് ചെയ്ത ശേഷം client-ൽ സജീവ resolver പരിശോധിക്കുക, endpoint-ന്റെ കോൺഫിഗറേഷൻ പേജല്ല.

split tunneling ശരിയായ resolver-നെ തോൽപ്പിക്കാം

split tunneling-ൽ ടണലിലേക്ക് തള്ളിയ റൂട്ടുകൾ മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ. resolver വിലാസം ഒരു റൂട്ടും കൊണ്ട് മൂടിയിട്ടില്ലെങ്കിൽ, ക്വറി ലോക്കൽ ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു, നിങ്ങളുടെ വീട്ടിലെ റൂട്ടർ ഉത്തരം നൽകുന്നു. endpoint-ലെ വിലാസം ഇപ്പോഴും ശരിയാണ്, തിരച്ചിൽ ഇപ്പോഴും പരാജയപ്പെടുന്നു. resolver-ന് റൂട്ട് ചേർക്കുക, പിന്നെ വീണ്ടും പരീക്ഷിക്കുക.

ഓവർലാപ്പ് ചെയ്യുന്ന ലോക്കൽ ശ്രേണികൾ അതേ ഫലം കൂടുതൽ അസ്വസ്ഥമായ രീതിയിൽ നൽകുന്നു: ക്വറിക്ക് ഉത്തരം കിട്ടുന്നു, പക്ഷേ തെറ്റായ സെർവറിൽ നിന്ന്.

Amazon DNS വിലാസത്തിനായി security groups തുറക്കരുത്

തിരച്ചിലുകൾ സമയം കഴിയുമ്പോൾ പ്രവണത resolver വിലാസത്തിലേക്ക് UDP 53 അനുവദിക്കുന്ന നിയമം ചേർക്കുക എന്നതാണ്. security groups-ഉം നെറ്റ്വർക്ക് ACL-കളും Amazon DNS ട്രാഫിക്കിനെ ഇഷ്ടാനുസൃത DNS ഇൻസ്റ്റൻസിലേക്കുള്ള ട്രാഫിക് പോലെ ഫിൽട്ടർ ചെയ്യുന്നില്ല എന്ന് AWS രേഖപ്പെടുത്തുന്നു. ആ നിയമങ്ങൾ തുറക്കുന്നത് VPC resolver-ന് ഒന്നും മാറ്റുന്നില്ല, കാരണമില്ലാതെ അതിർത്തി വിശാലമാക്കുന്നു. നിങ്ങൾ തന്നെ നടത്തുന്ന resolver മറ്റൊരു കേസാണ്, അതിന് സ്വന്തം നിയമങ്ങൾ ശരിക്കും വേണം.

നിങ്ങളുടെ ഡിസൈനിൽ രണ്ടും ഉണ്ടെങ്കിൽ, ഏതെങ്കിലും നിയമം എഡിറ്റ് ചെയ്യുന്നതിന് മുൻപ് client യഥാർത്ഥത്തിൽ ഏതിനെ ലക്ഷ്യമിടുന്നു എന്ന് പരിശോധിക്കുക.

പാത പരിശോധിക്കുക, പിന്നെ മറ്റെന്തെങ്കിലും അളക്കുക

ഒരു പൊതു പേര് റെസോൾവ് ചെയ്യുക, VPC-യുമായി അസോസിയേറ്റ് ചെയ്ത സ്വകാര്യ ഹോസ്റ്റഡ് സോണിൽ രജിസ്റ്റർ ചെയ്ത സ്വകാര്യ പേര് റെസോൾവ് ചെയ്യുക, രണ്ടിനുമിടയിൽ client-ന്റെ സജീവ resolver വായിക്കുക. ഈ ക്രമം «resolver വിലാസം തെറ്റാണ്» എന്നതിനെ «സോൺ അസോസിയേറ്റ് ചെയ്തിട്ടില്ല», «client ക്രമീകരണം അവഗണിച്ചു» എന്നിവയിൽ നിന്ന് വേർതിരിക്കുന്നു. ഓരോന്നിനും വ്യത്യസ്ത പരിഹാരം, ഒന്നും throughput പ്രശ്നമല്ല.

വിജയകരമായ തിരച്ചിൽ തുടർച്ചയായ കൈമാറ്റ വേഗതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ഈ രണ്ട് സംഭാഷണങ്ങളും വേർതിരിച്ച് വയ്ക്കുക.