ടണൽ ഉയരുന്നതോടെ UFW VPN-ന്റെ DNS സെർവർ ഉപേക്ഷിക്കുന്നു
UFW-യുടെ ഡിഫോൾട്ട് നിരാകരണ നയം ടണൽ ഇന്റർഫേസിനെയും ഉൾക്കൊള്ളുന്നു. ട്രാഫിക് ദിശ അനുസരിച്ച് ക്രമീകരിച്ച്, tun0-ൽ പുഷ് ചെയ്ത resolver-ന് അനുമതി നൽകി, പിന്നീട് പുറത്തെ വഴി തുറക്കുക.
VPN ബന്ധിപ്പിക്കുന്ന നിമിഷം തന്നെ പേരുകൾ പരിഹരിക്കുന്നത് നിലയ്ക്കുന്നു, അതേസമയം പൊതു വിലാസത്തിലേക്കുള്ള ping ഇപ്പോഴും മറുപടി നൽകുന്നു, ഫയർവാൾ നിലയിൽ തെറ്റായി തോന്നുന്ന ഒന്നും കാണുന്നില്ല. നയത്തിൽ ഒന്നും മാറിയിട്ടില്ല; മാറിയത് ഒരു പുതിയ ഇന്റർഫേസ് വന്നതാണ്, ഡിഫോൾട്ട് നിരാകരണം ആദ്യ പാക്കറ്റ് മുതൽ അതിനെ ഉൾക്കൊള്ളുന്നു. UFW ദിശയും ഇന്റർഫേസും അനുസരിച്ചാണ് തീരുമാനിക്കുന്നത്, അതിനാൽ വയർലെസ് ലിങ്കിനായി എഴുതിയ നിയമം ടണലിൽ നിന്ന് പുറത്തുപോകുന്ന ട്രാഫിക്കിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. പരിഹാരം ഒരു നിശ്ചിത ക്രമത്തിൽ പ്രയോഗിക്കുന്ന കുറച്ച് ഇടുങ്ങിയ നിയമങ്ങളാണ്.
ടണൽ ഉയർന്നതിനു ശേഷം മാത്രമാണ് ലക്ഷണം പ്രത്യക്ഷപ്പെടുന്നത്
ഡിഫോൾട്ട് നിരാകരണ നയം പറഞ്ഞത് കൃത്യമായി ചെയ്യുന്നു: പൊരുത്തപ്പെടുന്ന നിയമമില്ലാത്തതെല്ലാം, നിലവിലുള്ള ഓരോ ഇന്റർഫേസിലും നിരാകരിക്കപ്പെടുന്നു. നിയമങ്ങൾ എഴുതിയപ്പോൾ ടണൽ ഉണ്ടായിരുന്നില്ല, അതിനാൽ അവയിൽ ഒന്നിനും അതിനെ പിടിക്കാനാവില്ല, എപ്പോഴുമുണ്ടായിരുന്ന നിരാകരണം ഇപ്പോൾ പേര് പരിഹരിക്കലിന് ബാധകമാണ്. അക്ഷരാർഥ വിലാസത്തിലേക്കുള്ള നേരിട്ടുള്ള ട്രാഫിക്, വിശാലമായ അനുമതി അതിനെ ഉൾക്കൊള്ളുമ്പോൾ ഇപ്പോഴും പ്രവർത്തിച്ചേക്കാം, അതുകൊണ്ടാണ് പൊതു resolver-ലേക്കുള്ള ping വിജയിക്കുമ്പോൾ പേര് തിരയൽ പരാജയപ്പെടുന്നത്. വിടവ് എന്നത് നയം ഒരിക്കലും കണ്ടിട്ടില്ലാത്ത ഒരു ഇന്റർഫേസിനുള്ള നിയമമാണ്.
പരാജയം വൃത്തിയായി തിരികെ മാറുന്നതിനും ഇത് കാരണമാണ്: ടണൽ താഴ്ത്തൂ, പേരുകൾ വീണ്ടും പരിഹരിക്കപ്പെടും, കാരണം ചോദ്യം നിയമങ്ങളുള്ള ഒരു ഇന്റർഫേസിലേക്ക് മടങ്ങുന്നു. ടണൽ ഉയർന്നിരിക്കുമ്പോൾ മാത്രം പരാജയപ്പെടുന്ന നയം DNS പ്രശ്നമല്ല, resolver തന്നെ ട്യൂൺ ചെയ്യുന്നതാണ് ഇവിടെ ഏറ്റവും സമയം പാഴാക്കുന്നത്. resolver കോൺഫിഗറേഷൻ വായിക്കുന്നതിന് മുൻപ് ഇന്റർഫേസ് പട്ടിക വായിക്കുക.
മൂന്ന് ദിശകൾ, മൂന്ന് വ്യത്യസ്ത നിയമക്കൂട്ടങ്ങൾ
ഒരു സെഷൻ ഒന്നിലധികം ദിശകളിൽ നിയമങ്ങളെ സ്പർശിക്കുന്നു, ടണൽ അവയിൽ മിക്കതിനും രണ്ടാമത്തെ ഇന്റർഫേസ് ചേർക്കുന്നു. ട്രാഫിക് ആദ്യം ദിശയും ഇന്റർഫേസും അനുസരിച്ച് ക്രമീകരിച്ചാൽ ബാക്കിയുള്ളത് യാന്ത്രികമാകും, കാരണം താഴെയുള്ള ഓരോ വരിക്കും അതിന്റെ സ്ഥാനത്ത് അതിന്റേതായ നിയമം വേണം. ഉദാഹരണങ്ങൾ tun0 ഉം 10.8.0.0/24 പൂളും ഉപയോഗിക്കുന്നു, അതിനാൽ പേരുകളും ശ്രേണികളും ക്ലയന്റിന്റെ സ്വന്തം ഔട്ട്പുട്ടിൽ നിന്നുള്ളവ കൊണ്ട് മാറ്റുക.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
രണ്ട് വരികൾ പലപ്പോഴും കൂട്ടിക്കുഴയ്ക്കുന്നു, കാരണം രണ്ടും ടണലിനെ പരാമർശിക്കുന്നു. resolver-ന്റെ നിയമം ക്ലയന്റ് ടണലിലേക്ക് അയക്കുന്ന ട്രാഫിക്കിന് അനുമതി നൽകുന്നു, എന്നാൽ SSH-ന്റെ നിയമം സെർവർ അവിടെ നിന്ന് സ്വീകരിക്കുന്ന ട്രാഫിക്കിന് അനുമതി നൽകുന്നു; അവ വ്യത്യസ്ത യന്ത്രങ്ങളിൽ കഴിയുന്നു, സ്വതന്ത്രമായി പരാജയപ്പെടുന്നു. ഏറ്റവും കൂടുതൽ മറക്കപ്പെടുന്ന വരി രണ്ടാമത്തേതാണ്, കാരണം സെർവറിന്റെ പൊതു വിലാസത്തിലേക്കുള്ള ക്ലയന്റിന്റെ ട്രാഫിക്കിന് അനുമതി ലഭിക്കുന്നതുവരെ ക്ലയന്റിന് ടണൽ നിർമ്മിക്കാനേ കഴിയില്ല. മുകളിൽ നിന്ന് താഴേക്ക് പ്രവർത്തിക്കുക, ഓരോ പരാജയത്തിനും ഒരു സാധ്യതയുള്ള കാരണമുണ്ട്.
പുഷ് ചെയ്ത resolver-ന് സ്വന്തം നിയമം വേണം
ടണൽ DNS വഹിക്കുന്നുണ്ടോ എന്നത് സെർവർ എന്ത് അയക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. resolver ഓപ്ഷൻ പുഷ് ചെയ്യുന്ന സെർവർ ക്ലയന്റിന്റെ കോൺഫിഗറേഷനിൽ ഒരു സ്വകാര്യ വിലാസം ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ആ വിലാസം ടണലിലൂടെ മാത്രമേ റൂട്ട് ചെയ്യാനാകൂ. സെർവർ ഒന്നും പുഷ് ചെയ്യുന്നില്ലെങ്കിൽ, ക്ലയന്റ് മുൻപേയുള്ള resolver നിലനിർത്തുന്നു, താഴെയുള്ള നിയമങ്ങൾക്ക് അനുവദിക്കാൻ ഒന്നുമില്ല. എന്തെങ്കിലും എഴുതുന്നതിന് മുൻപ് പുഷ് ചെയ്ത അവസ്ഥയും നിലവിലെ ചോദ്യഫലവും പരിശോധിക്കുക:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedസ്റ്റാറ്റസ് ഔട്ട്പുട്ട് ഉപയോഗിക്കുന്ന resolver-നെയും അത് ബന്ധിച്ചിരിക്കുന്ന ലിങ്കിനെയും പേരിടുന്നു, അതിന് പിന്നിലുള്ള റൂട്ട് തിരയൽ ഏത് ഇന്റർഫേസ് ആ വിലാസത്തിലേക്ക് ചോദ്യം കൊണ്ടുപോകുമെന്ന് കാണിക്കുന്നു. resolver മറ്റൊരു ലിങ്കിലാണെങ്കിൽ, പ്രശ്നം ഫയർവാളിന് മുൻപേയാണ്, ഒരു നിയമവും സഹായിക്കില്ല. രണ്ടും ടണലിൽ യോജിക്കുന്നുവെങ്കിൽ, രണ്ട് നിയമങ്ങൾ വേണം, കാരണം ഭൂരിഭാഗം ചോദ്യങ്ങളും UDP വഹിക്കുന്നു, മറുപടി മുറിഞ്ഞാൽ TCP ഏറ്റെടുക്കുന്നു. രണ്ട് മൂല്യങ്ങളും രേഖപ്പെടുത്തുക, കാരണം നിയമങ്ങൾ പേരിടുന്നത് അവയെയാണ്:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'ഉള്ളിലെ വഴിക്ക് മുൻപ് പുറത്തെ വഴി തുറക്കുക
ടണൽ നിലവിൽ വരുന്നതിന് മുൻപ് ക്ലയന്റ് സെർവറിന്റെ പൊതു വിലാസത്തിൽ എത്തണം, അതിനാൽ അതിനുള്ള നിയമം ഭൗതിക ലിങ്കിലാണ്, ആദ്യം അതിന്റെ സ്ഥാനത്ത് ഉണ്ടായിരിക്കണം. resolver-ന് അനുമതി നൽകി സെർവർ മറക്കുന്ന നയം ക്ലയന്റിനെ ടണൽ നിർമ്മിക്കാനേ കഴിയാത്ത അവസ്ഥയിൽ വിടുന്നു, ആ ലക്ഷണം സാധാരണയായി kill switch-ന്റെ മേൽ ചുമത്തപ്പെടുന്നു. പിന്നീട് യഥാർഥത്തിൽ ടണലിലൂടെ വേണ്ടിയിരുന്ന സേവനങ്ങൾക്ക് അനുമതി നൽകുക, ഒരു സമയത്ത് ഒരു ഇടുങ്ങിയ നിയമം, ഇന്റർഫേസ് മുഴുവനായി തുറക്കുന്നതിന് പകരം. ഇടുങ്ങിയ നിയമങ്ങളാണ് നിരാകരണത്തിന് അതിന്റെ സ്ഥാനത്ത് തുടരാനാകുന്നതിന്റെ കാരണം.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'പരീക്ഷിക്കുമ്പോൾ ക്രമം പ്രധാനമാണ്, കാരണം ടണൽ ഉയരാൻ ഒട്ടാകെ അനുവാദം നൽകുന്നത് ആദ്യ നിയമമാണ്. അത് ചേർത്ത്, ബന്ധിപ്പിച്ച്, സേവന നിയമം ചേർക്കുന്നതിന് മുൻപ് ടണൽ ഉയർന്നിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക, കാരണം രണ്ടും ഒരുമിച്ച് ചെയ്താൽ പരാജയം ഏത് പകുതിയാണ് തെറ്റ് എന്ന് ഒന്നും പറയില്ല. മുകളിലെ ഡോക്യുമെന്റേഷൻ വിലാസത്തിന് പകരം ക്ലയന്റ് ഉപയോഗിക്കാൻ കോൺഫിഗർ ചെയ്ത എൻഡ്പോയിന്റ് ഇടുക.
ബോധപൂർവം വിച്ഛേദിച്ച് ക്ലയന്റ് ഭാഗം പൂർത്തിയാക്കുക. നിരാകരണം ബോധപൂർവം ഒഴിവാക്കിയ ട്രാഫിക്കിനെ ഇപ്പോഴും നിരാകരിക്കണം, കാരണം ടണൽ ഉയർന്നിരിക്കുമ്പോൾ മറുപടി നൽകുന്ന resolver സംശയിക്കുമ്പോൾ നിരാകരിക്കുന്ന നയത്തിന്റെ പകുതി മാത്രമാണ് ഉൾക്കൊള്ളുന്നത്.
ബന്ധിപ്പിക്കുന്ന ക്ലയന്റ് ഇപ്പോഴും സ്വീകരിക്കപ്പെട്ടിട്ടില്ല
സെർവറിന് പരിഗണിക്കാനുള്ള സ്വന്തം ദിശയുണ്ട്, ഹാൻഡ്ഷേക്ക് പൂർത്തിയാക്കുന്ന ക്ലയന്റിന് സെർവർ അതിനെ സ്വീകരിക്കുന്നതുവരെ സെർവറിൽ പ്രവർത്തിക്കുന്ന ഒന്നിലും എത്താനാവില്ല. പൊതു listener-ന്റെ നിയമം ടണൽ നിലവിലുണ്ടാകാൻ മാത്രമാണ് അനുവദിക്കുന്നത്; അത് ടണലിന്റെ ട്രാഫിക് അകത്തേക്ക് കടത്തിവിടുന്നില്ല. സെർവറിൽ അത് രണ്ട് നിയമങ്ങളും കൂടാതെ സേവനം യഥാർഥത്തിൽ കേൾക്കുന്നുണ്ടെന്നുള്ള ഒരു പരിശോധനയുമാണ്:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'നിയമത്തിലെ പൂൾ സെർവർ അനുവദിക്കുന്ന ശ്രേണിക്ക് തുല്യമായിരിക്കണം, ടണൽ നമ്പർ സെർവർ സൃഷ്ടിച്ചതിന് യോജിക്കണം, കാരണം മറ്റൊരു ഇന്റർഫേസിനുള്ള നിയമം നിയമമില്ലായ്മയിൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല. limit ഭരണ പോർട്ടിന് ബോധപൂർവമാണ്, കാരണം അത് ആവർത്തിച്ചുള്ള കണക്ഷനുകൾ പരിധിയില്ലാതെ സ്വീകരിക്കുന്നതിന് പകരം പരിമിതപ്പെടുത്തുന്നു. listener പരിശോധന അടച്ച പോർട്ടിനെ വലിച്ചെറിഞ്ഞ പാക്കറ്റിൽ നിന്ന് വേർതിരിക്കുന്നു, അവ ക്ലയന്റിൽ നിന്ന് ഒരുപോലെ കാണപ്പെടുന്നു. അക്കമിട്ട നിയമങ്ങളും മുഴുവൻ ചിത്രമല്ല: UFW-ന്റെ before നിയമങ്ങളും കൈകൊണ്ട് എഴുതിയ ഏത് nftables വരിയും നേരത്തെ ഒത്തുപോകുന്നു, പട്ടിക അനുവദിക്കുന്നതായി തോന്നുന്ന പാക്കറ്റും ഇപ്പോഴും നിരാകരിച്ചേക്കാം.