WireGuard DNS DNAT: മറുപടി പാത പ്രവർത്തനക്ഷമമായി നിലനിർത്തുക

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

WireGuard ക്ലയന്റിന്റെ DNS ചോദ്യം മറ്റൊരു റിസോൾവറിലേക്ക് അയക്കുന്നത് ഒരു നിയമം പോലെ തോന്നുമെങ്കിലും മൂന്ന് തീരുമാനങ്ങളായി പ്രവർത്തിക്കുന്നു. ലക്ഷ്യസ്ഥാനം മാറ്റിയെഴുതണം, പാക്കറ്റ് കൈമാറണം, ഗേറ്റ്‌വേ സൃഷ്ടിച്ച വിവർത്തനാവസ്ഥയിലൂടെ മറുപടി തിരികെയുള്ള വഴി കണ്ടെത്തണം. മൂന്നാമത്തേത് ഒഴിവാക്കിയാൽ ചോദ്യം വൃത്തിയായി പുറത്തുപോകും, എന്നാൽ ക്ലയന്റ് എന്നെന്നും കാത്തിരിക്കും.

10.77.0.0/24-ലുള്ള അംഗീകൃത ക്ലയന്റുകൾ wg0 വഴി വന്ന്, പ്രഖ്യാപിത വിലാസം 10.77.0.1 ചോദിച്ച്, 203.0.113.53-ൽ ഒരു റിസോൾവർ ആവശ്യമായ ഉദാഹരണം എടുക്കുക. അപ്സ്ട്രീം വിലാസം ഡോക്യുമെന്റേഷനുള്ള പ്ലേസ്‌ഹോൾഡർ ആണ്, പ്രവർത്തിക്കുന്ന സേവനമല്ല.

ചോദ്യം റീഡയറക്‌ട് ചെയ്യുന്നത് അതിന്റെ ലക്ഷ്യസ്ഥാനം മാത്രം മാറ്റുന്നു

PREROUTING-ലെ ലക്ഷ്യ-NAT നിയമം റൂട്ടിംഗ് തീരുമാനത്തിന് മുമ്പ് വിലാസം മാറ്റിയെഴുതുന്നു, അതിനാൽ പാക്കറ്റ് പിന്നീട് പഴയതിന് പകരം പുതിയ ലക്ഷ്യസ്ഥാനത്തേക്ക് റൂട്ട് ചെയ്യപ്പെടുന്നു. ക്ലയന്റിന്റെ ഉറവിട വിലാസം ആ പ്രവർത്തനത്താൽ തൊട്ടുപോകുന്നില്ല. അതുകൊണ്ടാണ് പൂർണ്ണമായി തോന്നുന്ന ഒരു നിയമവും നിശ്ശബ്ദത ഉണ്ടാക്കാൻ കഴിയുന്നത്: അഭ്യർത്ഥന ഇപ്പോൾ ക്ലയന്റിന്റെ സ്വകാര്യ ശ്രേണിയെക്കുറിച്ച് ഒരിക്കലും കേട്ടിട്ടില്ലാത്ത ഒരു റിസോൾവറിലേക്ക് പോകുന്നു. ഗേറ്റ്‌വേ ഒരു ഫീൽഡ് വിവർത്തനം ചെയ്തു, രണ്ടാമത്തെ പ്രശ്നം പാരമ്പര്യമായി കിട്ടി.

രണ്ട് DNS ഗതാഗതത്തിനും പൊരുത്തപ്പെടുന്ന നിയമങ്ങൾ വേണം, കാരണം മറുപടി മുറിച്ചാൽ ക്ലയന്റ് TCP-യിലേക്ക് മടങ്ങുന്നു.

ചുവടെയുള്ള നിയമങ്ങൾ ഒരു ഇൻകമിംഗ് ഇന്റർഫേസ്, ഒരു ക്ലയന്റ് ശ്രേണി, ഒരു യഥാർത്ഥ ലക്ഷ്യ വിലാസം എന്നിവ തിരഞ്ഞെടുക്കുന്നു. ഗേറ്റ്‌വേയിൽ മറ്റൊന്നും ബാധിക്കപ്പെടുന്നില്ല, ഗേറ്റ്‌വേയുടെ സ്വന്തം ചോദ്യം ഒട്ടും പൊരുത്തപ്പെടുന്നില്ല.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

മറുപടി പാത ഒരു വേറിട്ട തീരുമാനമാണ്

രണ്ട് ക്രമീകരണങ്ങൾ മറുപടി തിരികെ വരാൻ അനുവദിക്കുന്നു, ഒന്ന് നേരത്തേ തിരഞ്ഞെടുത്താൽ ഒരു ഡീബഗ്ഗിംഗ് സെഷൻ ലാഭിക്കും. ഒന്നുകിൽ അപ്സ്ട്രീം റിസോൾവറിന് ഈ ഗേറ്റ്‌വേ വഴി 10.77.0.0/24-ലേക്ക് തിരികെയുള്ള റൂട്ട് ഉണ്ട്, അല്ലെങ്കിൽ ഗേറ്റ്‌വേ പുറത്തേക്കുള്ള വഴിയിൽ ഉറവിടം വിവർത്തനം ചെയ്യുന്നു, അങ്ങനെ മറുപടി അപ്സ്ട്രീമിന് ഇതിനകം അറിയാവുന്ന ഒരു വിലാസത്തിൽ എത്തുന്നു. രണ്ടും പ്രവർത്തിക്കുന്നു; അപ്സ്ട്രീമിനുമേലുള്ള നിങ്ങളുടെ നിയന്ത്രണവുമായി പൊരുത്തപ്പെടുന്നത് ഒന്ന് മാത്രം.

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

ആ വിവർത്തനം റീഡയറക്‌ഷനോളം തന്നെ ചുരുക്കി നിർത്തുക, അല്ലെങ്കിൽ നിയമം അതുമായി യാദൃച്ഛികമായി പൊരുത്തപ്പെടുന്ന എന്തിനും പൊതുവായ NAT ആയിത്തീരും:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

ജോലി തോന്നുന്നതിനേക്കാൾ ഇടുങ്ങിയ നിയമങ്ങൾ എഴുതുക

ഫോർവേഡിംഗ് അനുമതിയും അതേ പരിധിയിൽ പെടുന്നു. യന്ത്രത്തിലെ ഓരോ DNAT കണക്ഷനും സ്വീകരിക്കുന്നതിന് പകരം ക്ലയന്റിൽ നിന്ന് റിസോൾവറിലേക്കുള്ള പ്രവാഹവും conntrack ഇതിനകം തിരിച്ചറിയുന്ന മടക്ക ട്രാഫിക്കും അനുവദിക്കുക. സർവവ്യാപിയായ അനുമതി DNS-മായി ബന്ധമില്ലാത്ത പോർട്ട് ഫോർവേഡിംഗിനും അനുമതി നൽകുന്നു.

ഗേറ്റ്‌വേയുടെ സ്വന്തം റിസോൾവർ വേറൊരു കോഡ് പാതയാണ്. പ്രാദേശികമായി പുറപ്പെടുവിക്കുന്ന ചോദ്യം OUTPUT വഴി പോകുന്നു, അതിനാൽ ഗേറ്റ്‌വേ ഷെല്ലിൽ നിന്നുള്ള പരിശോധന PREROUTING നിയമമോ ഫോർവേഡിംഗ് നയമോ അഭ്യസിക്കുന്നില്ല. അതുകൊണ്ടാണ് പ്രാദേശിക പരിശോധന വിജയിക്കുമ്പോൾ എല്ലാ ക്ലയന്റുകളും പരാജയപ്പെടുന്നത്, വിപരീതവും അത്രതന്നെ സാധാരണമാണ്.

ഇവിടെ ഒന്നും പോർട്ട് 443-ലെ HTTPS-ന് മുകളിലുള്ള DNS-ഉം പോർട്ട് 853-ലെ TLS-ന് മുകളിലുള്ള DNS-ഉം ഉൾക്കൊള്ളുന്നില്ല, IPv6-ഉം ഉൾക്കൊള്ളുന്നില്ല. IPv6 റിസോൾവർ കോൺഫിഗർ ചെയ്ത ക്ലയന്റ് മുഴുവൻ ക്രമീകരണവും സന്തോഷത്തോടെ അവഗണിക്കും.

പുതിയ ചോദ്യം എന്ത് തെളിയിക്കുന്നു

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

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

എന്തെങ്കിലും റീഡയറക്‌ട് ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പേരുകൾ റിസോൾവറിന് അറിയാമെന്ന് ഉറപ്പാക്കുക. പൊതു പേരുകൾക്ക് മറുപടി നൽകുന്നതും എന്നാൽ നിങ്ങളുടെ സ്വകാര്യ മേഖലയ്ക്ക് നൽകാത്തതുമായ പകരം പ്രവർത്തിക്കുന്ന ഒരു തിരയലിനെ തകർന്ന ടണൽ പോലെ തോന്നിക്കുന്ന NXDOMAIN ആക്കി മാറ്റുന്നു. ക്ലയന്റ് പാത ഉൾപ്പെടുന്നതിന് മുമ്പ് ഗേറ്റ്‌വേയിൽ നിന്ന് നേരിട്ട് റിസോൾവർ പരിശോധിക്കുക. കൂടാതെ iptables വിപുലീകരണങ്ങളുടെ റഫറൻസ് ഈ നിയമങ്ങൾ ആശ്രയിക്കുന്ന DNAT, masquerade അർത്ഥശാസ്ത്രം രേഖപ്പെടുത്തുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ