OpenWrt പോളിസി റൂട്ടിംഗ്: പ്രാദേശിക DNS പിടിക്കുന്ന ചെയിൻ

LAN-ലെ ക്ലയന്റുകൾ ടണൽ വഴി പരിഹരിക്കുന്നു, റൗട്ടറിന്റെ സ്വന്തം ലുക്കപ്പുകൾ നിശബ്ദമായി അങ്ങനെ ചെയ്യുന്നില്ല. പാക്കേജ് അപ്ഡേറ്റുകൾ, സമയ സമന്വയം, ഡൈനാമിക് DNS എന്നിവയെല്ലാം സാധാരണ അപ്ലിങ്കിലൂടെ പുറത്തുപോകുന്നു, എന്നാൽ ഓരോ ഫോർവേഡ് ചെയ്ത ക്വറിയും VPN എടുക്കുന്നു, ഇന്റർഫേസിൽ രണ്ട് വ്യത്യസ്ത പാതകൾ ഉണ്ടെന്ന് സൂചിപ്പിക്കുന്ന ഒന്നുമില്ല. വിശദീകരണം പോളിസിയിലെ ബഗ് അല്ല, മറിച്ച് ഏത് ഹുക്ക് പാക്കറ്റ് കാണുന്നു എന്ന ചോദ്യമാണ്. രണ്ട് ഫ്ലോ, ഒരു റിസോൾവർ വിലാസം, അവയിൽ ഒന്ന് മാത്രം റൗട്ടർ കടക്കുന്നു. അവയെ വേർതിരിക്കുന്നതാണ് മുഴുവൻ പരിഹാരം.

രണ്ട് ഫ്ലോ, ഒരു റിസോൾവർ വിലാസം

ആദ്യ ഫ്ലോ ആളുകൾ സങ്കൽപ്പിക്കുന്നതാണ്. ഒരു ക്ലയന്റ് റൗട്ടറിന്റെ റിസോൾവറിനോട് ചോദിക്കുന്നു, റിസോൾവർ മുകളിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു, ആ ഫോർവേഡ് ചെയ്ത പാക്കറ്റ് പുറത്തുപോകുമ്പോൾ റൗട്ടർ കടക്കുന്നു. ആ പാക്കറ്റ് ഫോർവേഡ് ചെയ്ത ട്രാഫിക് നിരീക്ഷിക്കുന്ന ഏതിനും ദൃശ്യമാണ്.

രണ്ടാം ഫ്ലോ എവിടെനിന്നും ഒരിക്കലും എത്തുന്നില്ല. റൗട്ടർ അത് സൃഷ്ടിക്കുന്നു, അതിനാൽ ഇൻബൗണ്ട് പാക്കറ്റും പൊരുത്തപ്പെടുത്തേണ്ട ഫോർവേഡിംഗ് ഘട്ടവുമില്ല.

രണ്ടും ഒരേ റിസോൾവർ വിലാസം ലക്ഷ്യമാക്കാം, അതുകൊണ്ടുതന്നെ വ്യത്യാസം വിട്ടുകളയാൻ എളുപ്പമാണ്. ഒരേ ലക്ഷ്യസ്ഥാനം, വ്യത്യസ്ത ഉത്ഭവം, വ്യത്യസ്ത ചെയിൻ. ഉത്ഭവം കണ്ടുകഴിഞ്ഞാൽ ബാക്കി രോഗനിർണയം പിന്തുടരുന്നു.

ഫോർവേഡ് ചെയ്തതും പ്രാദേശികമായി സൃഷ്ടിച്ചതുമായ പാക്കറ്റുകൾ വ്യത്യസ്തമായി പ്രവേശിക്കുന്നു

ഫോർവേഡ് ചെയ്ത ട്രാഫിക് മറ്റൊരു ഇന്റർഫേസിൽ നിന്ന് എത്തുമ്പോൾ വിലയിരുത്തുന്നു. പോളിസി റൂട്ടിംഗ് പാക്കേജുകൾ അതിനെ prerouting ചെയിനായി വെളിപ്പെടുത്തുന്നു, അവിടെ സ്ഥാപിച്ച നിയമം റൗട്ടർ കടക്കുന്ന ഓരോ പാക്കറ്റും കാണുന്നു. അതുകൊണ്ടാണ് ക്ലയന്റ് ലുക്കപ്പുകൾ പോളിസി വിവരിക്കുന്നതുപോലെ പ്രവർത്തിക്കുന്നത്, അതുകൊണ്ടാണ് റൗട്ടർ അത് അവഗണിക്കുന്നത്. നിയമം തെറ്റല്ല, റൗട്ടർ ഒരിക്കലും എത്താത്ത ഒരു ഹുക്കിൽ ഘടിപ്പിച്ചിരിക്കുന്നു എന്നുമാത്രം. അത് നീക്കുക, അതേ പൊരുത്തം പ്രവർത്തിക്കാൻ തുടങ്ങും.

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

ഇത് പാക്കറ്റുകൾ എവിടെ ജനിക്കുന്നു എന്നതിന്റെ സ്വഭാവമാണ്, ഏതെങ്കിലും നിർദ്ദിഷ്ട പാക്കേജിന്റേതല്ല. ഒരു ചെയിനിനായി എഴുതിയ നിയമത്തിന് മറ്റൊന്നിനെക്കുറിച്ച് അഭിപ്രായമില്ല. ഏത് നിയമ ട്യൂണിംഗും അത് മാറ്റുന്നില്ല.

ഔട്ട്പുട്ട് ചെയിൻ തിരഞ്ഞെടുക്കുക, തുടർന്ന് പൊരുത്തം ചുരുക്കുക

പരിഹാരം അതേ ഉദ്ദേശ്യം ഔട്ട്പുട്ട് ചെയിനിലും ഘടിപ്പിക്കുകയോ, റൗട്ടറിന്റെ സ്വന്തം ക്വറികൾ പ്രധാനമെങ്കിൽ നിയമം അങ്ങോട്ട് നീക്കുകയോ ചെയ്യുകയാണ്. പോളിസി റൂട്ടിംഗ് പാക്കേജിൽ നിർമ്മിച്ച OpenWrt ക്രമീകരണത്തിൽ ഇതിനർത്ഥം നിയമത്തിന്റെ ചെയിൻ ക്രമീകരണത്തിൽ prerouting-ന് പകരം output തിരഞ്ഞെടുക്കുക എന്നാണ്. രണ്ട് ജനസംഖ്യകൾക്കും കവറേജ് ആവശ്യമെങ്കിൽ രണ്ട് നിയമങ്ങളും നിലനിർത്തുക.

തുടർന്ന് നിയമം എന്തിനോട് പൊരുത്തപ്പെടുന്നു എന്ന് ചുരുക്കുക. റിസോൾവർ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പോർട്ടിലെ ലക്ഷ്യ റിസോൾവർ വിലാസങ്ങൾ, റൗട്ടർ സൃഷ്ടിക്കുന്നതെല്ലാം ടണലിലേക്ക് അയക്കുന്നതിനേക്കാൾ വളരെ ചെറിയ തീരുമാനമാണ്.

രണ്ട് ചെയിനുകളും ഉൾക്കൊള്ളുന്ന ഒന്ന് എഴുതാൻ ശ്രമിക്കുന്നതിനുപകരം രണ്ട് നിയമങ്ങളും വ്യക്തമായി നിലനിർത്തുക. വേറിട്ട നിയമങ്ങൾ വായിക്കാൻ എളുപ്പമാണ്, ഡീബഗ് ചെയ്യുമ്പോൾ ക്ലയന്റ് ട്രാഫിക്കിനെ ശല്യപ്പെടുത്താതെ റൗട്ടറിന്റെ പാത നിഷ്ക്രിയമാക്കാൻ അവ അനുവദിക്കുന്നു. കൗണ്ടറുകളെ ഓരോന്നായി അർത്ഥവത്താക്കുകയും ചെയ്യുന്നു.

ടണലിന്റെ സ്വന്തം ഗതാഗതം നിയമത്തിന് പുറത്ത് നിർത്തുക

ടണലിന്റെ പുറം കണക്ഷനും റൗട്ടർ സൃഷ്ടിക്കുന്നു. പ്രാദേശികമായി സൃഷ്ടിച്ച എല്ലാ ട്രാഫിക്കും ടണലിലേക്ക് അയക്കുന്ന നിയമം ടണലിനെ അതിലൂടെത്തന്നെ റൂട്ട് ചെയ്യും, അത് ഒട്ടും ഉയരുകയില്ല.

മാനേജ്മെന്റ് ആക്സസ് രണ്ടാം ഇരയാണ്. റൗട്ടറിൽ നിന്ന് ഉത്ഭവിക്കുന്ന അഡ്മിനിസ്ട്രേറ്റീവ് സെഷനുകളോ അവയോടുള്ള മറുപടികളോ വളരെ വിശാലമായ പ്രാദേശിക നിയമത്താൽ ടണലിലേക്ക് വലിച്ചിടപ്പെടുകയും LAN-ൽ നിന്ന് എത്തിച്ചേരാനാകാത്തതാകുകയും ചെയ്യാം.

ടണലിന്റെ അന്തിമ പോയിന്റ് പൊരുത്തത്തിൽ നിന്ന് ഒഴിവാക്കുക, നിയമം റിസോൾവർ വിലാസങ്ങളിൽ പരിമിതപ്പെടുത്തുക. അത് DNS ആവശ്യത്തിന് മതിയാകും, അതിനെക്കുറിച്ച് ചിന്തിക്കാൻ മതിയായ ചെറുതുമാണ്.

ഒരു ജനസംഖ്യയല്ല, രണ്ടും പരീക്ഷിക്കുക

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

ഫലങ്ങളെ രണ്ട് കണ്ടെത്തലുകളായി കാണുക. ടണൽ വഴി പരിഹരിക്കുന്ന ക്ലയന്റ് റൗട്ടറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ശരിയായി പരിഹരിക്കുന്ന റൗട്ടർ മറ്റൊരു ലിസണറിലെ ക്ലയന്റിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. മാറ്റ രേഖയിൽ അവ വേറിട്ട വരികളായി എഴുതുക.

പോർട്ടും പരിശോധിക്കുക: ലക്ഷ്യ പോർട്ട് 53-നോട് പൊരുത്തപ്പെടുന്ന നിയമം 853-ൽ DNS over TLS അല്ലെങ്കിൽ HTTPS അന്തിമ പോയിന്റ് വഴി എത്തുന്ന റിസോൾവറിനെ വിട്ടുകളയുന്നു. കോൺഫിഗർ ചെയ്ത upstream യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഗതാഗതവുമായി പൊരുത്തപ്പെടുത്തുക, ചോർച്ച ശരിയായ കാരണത്താൽ അടയുന്നു.