ഡൗൺ സ്ക്രിപ്റ്റോ ഫയർവാൾ നിയമമോ: ചോർച്ച തടയുന്നത് ഏതാണ്?
വിച്ഛേദനത്തിൽ ഇന്റർഫേസുകൾ താഴ്ത്തുന്നത് പരുക്കനാണ്, പലപ്പോഴും അനുമതികളില്ലാതെ പ്രവർത്തിക്കുന്നു. വീഴ്ചയെ അതിജീവിച്ച് വിടവ് അടയ്ക്കുന്ന ഫയർവാൾ നിയമവുമായി അതിനെ താരതമ്യം ചെയ്യുക.
രണ്ട് രൂപകൽപ്പനകളും ഒരേ കാര്യം വാഗ്ദാനം ചെയ്യുന്നു: ടണൽ വീഴുമ്പോൾ, ഒന്നും തുറന്ന രൂപത്തിൽ പുറത്തേക്ക് പോകുന്നില്ല. ഒന്ന് ടിയർഡൗൺ സമയത്ത് സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിച്ച് ഇന്റർഫേസുകൾ മുറിക്കുന്നു. മറ്റൊന്ന് ഫയർവാൾ നിയമം പ്രാബല്യത്തിൽ വയ്ക്കുകയും VPN ക്ലയന്റിൽ നിന്ന് ഒന്നും ആവശ്യപ്പെടുകയും ചെയ്യുന്നില്ല. ആർക്കാണ് പ്രവർത്തിക്കാനുള്ള അനുമതി, വിടവിനിടയിൽ എന്ത് സംഭവിക്കുന്നു, പിന്നീട് യന്ത്രം എങ്ങനെ വീണ്ടും ഓൺലൈനിലെത്തുന്നു എന്നിവയിൽ അവ വ്യത്യസ്തമാണ്. ഈ മൂന്ന് പോയിന്റുകളിൽ താരതമ്യം ചെയ്യുന്നത് ഏതാണ് കടുപ്പമെന്ന് തർക്കിക്കുന്നതിനേക്കാൾ ഉപകാരപ്രദമാണ്.
ഒരേ ജോലി, രണ്ട് സംവിധാനങ്ങൾ
പ്രൊഫൈൽ സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കാൻ അനുവദിച്ചാൽ, ടണൽ ഉയരുമ്പോഴും ടിയർഡൗൺ ചെയ്യുമ്പോഴും ക്ലയന്റിന് ഹുക്കുകൾ പ്രവർത്തിപ്പിക്കാം. ആ ഹുക്ക് ക്ലയന്റിന്റെ ജീവിതചക്രത്തിനുള്ളിൽ, കണക്ഷൻ അടയുന്ന അതേ നിമിഷത്തിൽ പ്രവർത്തിക്കുന്നു. ഫയർവാൾ നിയമമാകട്ടെ സിസ്റ്റത്തിന്റേതാണ്, ക്ലയന്റ് പ്രവർത്തിക്കുന്നുണ്ടോ, തകർന്നോ, കൊല്ലപ്പെട്ടോ എന്ന് അത് ശ്രദ്ധിക്കുന്നില്ല.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
ആ പട്ടികയാണ് മുഴുവൻ വാദം. സ്വച്ഛമായ അടയ്ക്കലിൽ മാത്രം പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റ് നിങ്ങൾക്ക് ഏറ്റവും കുറഞ്ഞ ആശങ്കയുണ്ടായിരുന്ന കേസ് ഉൾക്കൊള്ളുന്നു; പ്രധാന കേസ് ക്രാഷോ നെറ്റ്വർക്കിന്റെ അപ്രത്യക്ഷതയോ ആണ്, രണ്ടും വൃത്തിയായ ടിയർഡൗൺ നൽകുന്നില്ല.
ടിയർഡൗൺ ഹുക്കിന് എന്ത് ചെയ്യാം, എന്ത് ചെയ്യാനാവില്ല
രേഖപ്പെടുത്തിയ മാതൃക നെറ്റ്വർക്ക് ഇന്റർഫേസുകളിലൂടെ കടന്ന് loopback ഒഴികെ എല്ലാം താഴ്ത്തുന്നു. ഭൗതിക ഉപകരണം താഴെയായാൽ ടണലിന് പുറത്തേക്ക് ഒന്നും രക്ഷപ്പെടാനാവില്ല, അതാണ് കൃത്യം ഉദ്ദേശ്യം.
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneഇത് പ്രാദേശിക നെറ്റ്വർക്കും യന്ത്രം ഹോസ്റ്റ് ചെയ്യുന്ന ഏത് സേവനവും പ്രശ്നം പരിഹരിക്കാൻ നിങ്ങൾ ഉപയോഗിക്കുന്ന പാതയും താഴ്ത്തുന്നു. ലാപ്ടോപ്പിൽ വയർലെസ് ഉപകരണത്തിന് പിന്നീട് കൈകൊണ്ട് മാറ്റം വേണ്ടിവരാറുണ്ട്, അതിനാൽ ചെറിയ തടസ്സം ഒരു അറ്റകുറ്റപ്പണി സെഷനാകുന്നു. അതിലും മോശം, ഹുക്കിന് ഇവയൊന്നും ചെയ്യാൻ അനുമതി ഇല്ലായിരിക്കാം: ക്ലയന്റ് അനുമതികൾ ഉപേക്ഷിക്കുമ്പോൾ, ടിയർഡൗൺ സ്ക്രിപ്റ്റ് അനുമതിയില്ലാത്ത അക്കൗണ്ടിൽ പ്രവർത്തിക്കുന്നു, ഓരോ ഇന്റർഫേസ് മാറ്റവും അനുമതി പിശകോടെ പരാജയപ്പെടുന്നു, ആ പിശക് ആരും ലോഗ് വായിക്കാത്ത അതേ നിമിഷത്തിൽ എഴുതപ്പെടുന്നു.
ഹുക്കിൽ വിശ്വസിക്കുന്നതിന് മുൻപ് ക്ലയന്റ് എങ്ങനെ ആരംഭിക്കുന്നു എന്ന് പരിശോധിക്കുക. root ആയി കൈകൊണ്ട് പ്രവർത്തിപ്പിക്കുമ്പോൾ പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റ്, ബൂട്ടിൽ ആരംഭിക്കുന്ന സേവനത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.
ഫയർവാൾ നിയമം വ്യത്യസ്തമായി ചെയ്യുന്നത്
ടണൽ ട്രാഫിക്ക് മാത്രം അനുവദിക്കുന്ന നിയമം ക്ലയന്റ് പ്രോസസ് പോയാലും പ്രവർത്തിക്കുന്നു, കാരണം കേർണൽ ആ പ്രോസസിനെ ആശ്രയിക്കുന്നില്ല. നിയമം കൂടുതൽ ഇടുങ്ങിയതുമാണ്: ഒത്തുപോകുന്ന ഫ്ലോകൾ മാത്രം തടയുന്നു, loopback, പ്രാദേശിക സബ്നെറ്റ്, വീണ്ടെടുപ്പ് പാത എന്നിവ വെറുതെ വിടുന്നു, അതുകൊണ്ട് യന്ത്രത്തെ കുടുക്കുന്നില്ല.
വില എന്നത്, ഹോസ്റ്റ് ഫയർവാളിന്റെ ഉടമസ്ഥനാണ് നിയമം എഴുതി പരിപാലിക്കേണ്ടത്, അത് ക്ലയന്റ് യഥാർത്ഥത്തിൽ സൃഷ്ടിക്കുന്ന ടണൽ ഉപകരണത്തിന്റെ പേര് പറയണം. അർത്ഥം നിയമവും പ്രൊഫൈലും ഒരുമിച്ച് പരിപാലിക്കണം; പേരുമാറ്റിയ ഇന്റർഫേസ് എല്ലാം തടയുകയും ഒന്നും വിശദീകരിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഫയർവാൾ അവശേഷിപ്പിക്കുന്നു.
ഏത് സംവിധാനവും മറ്റൊന്നിനെ അനാവശ്യമാക്കുന്നില്ല. തിരുത്തിയതിന് ശേഷം ഒരിക്കലും വീണ്ടും ലോഡ് ചെയ്യാത്ത ഫയർവാൾ നിയമം ഒരിക്കലും പ്രവർത്തിക്കാത്ത സ്ക്രിപ്റ്റിനോളം കൽപിതമാണ്.
വിടവുണ്ടോ എന്ന് persist-tun തീരുമാനിക്കുന്നു
ടണൽ ഉപകരണം വിച്ഛേദനം അതിജീവിച്ചാൽ അതിലേക്ക് പോകുന്ന റൂട്ടുകളും അതിജീവിക്കുന്നു. അപ്പോൾ ട്രാഫിക് വീണ്ടും വഴിതിരിച്ചുവിടുന്നതിനുപകരം ഉപേക്ഷിക്കപ്പെടുന്നു, അതിനാൽ സ്ഥിരസ്ഥിതി റൂട്ട് ഭൗതിക ഗേറ്റ്വേയിലേക്ക് തിരികെ വീഴുന്നില്ല. ഏതെങ്കിലും ഫയർവാൾ നിയമം ഇടപെടുന്നതിന് മുൻപ് തന്നെ ചോർച്ച അസംഭവ്യമാക്കുന്നത് ഈ സ്വഭാവമാണ്.
ഈ ക്രമീകരണമില്ലാതെ ഉപകരണവും അതിനൊപ്പം റൂട്ടുകളും നീക്കം ചെയ്യപ്പെടുന്നു, സ്ഥിരസ്ഥിതി റൂട്ട് വീണ്ടും ഭൗതിക ഗേറ്റ്വേയിലേക്ക് വിരൽ ചൂണ്ടാം. അത് സംഭവിക്കുമോയെന്ന് പ്ലാറ്റ്ഫോമിനെയും ക്ലയന്റിനെയും ആശ്രയിച്ചിരിക്കുന്നു, അതുകൊണ്ടാണ് അവസ്ഥ ഊഹിക്കാതെ നിരീക്ഷിക്കേണ്ടത്. ക്രമീകരണത്തെ kill switch ന്റെ ഭാഗമായി കാണുക, പ്രകടന ഓപ്ഷനായി അല്ല.
വീണ്ടും ബന്ധിപ്പിക്കാനുള്ള പാത ജീവനോടെ നിർത്തി, പിന്നെ നാല് അവസ്ഥകൾ പരീക്ഷിക്കുക
കടുത്ത തടയൽ ക്ലയന്റിനെ വീണ്ടും ബന്ധിപ്പിക്കുന്നതിൽ നിന്നും തടയാം, കാരണം ബാക്കിയെല്ലാം നിഷേധിക്കപ്പെടുമ്പോഴും ക്ലയന്റിന് ഭൗതിക ഗേറ്റ്വേ വഴി സെർവറിലേക്ക് ഒരു റൂട്ട് ആവശ്യമാണ്. ടണൽ ഉയരുന്നതിന് മുൻപ് ആ ഒരു വിലാസത്തിന് ഹോസ്റ്റ് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുക, ആദ്യം പേര് നിർണ്ണയിക്കുക, കാരണം അത് ആവശ്യമാകുമ്പോഴേക്കും DNS തടയപ്പെട്ടിരിക്കാം.
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0പിന്നെ ലേബലല്ല, അവസ്ഥകൾ പരിശോധിക്കുക. നാല് നിമിഷങ്ങൾ ബോധപൂർവം അനുഭവിക്കുക: ടണലില്ലാത്ത തണുത്ത തുടക്കം, ആരോഗ്യകരമായ സെഷൻ, ആരും ആവശ്യപ്പെടാത്ത വീഴ്ച, വീണ്ടെടുത്തതിന് ശേഷമുള്ള സെഷൻ. ഓരോ നിമിഷവും സ്ഥിരസ്ഥിതി റൂട്ട് വായിച്ച്, പുറത്തേക്കുള്ള വിലാസം കാണാവുന്ന ഒരു അഭ്യർത്ഥന നടത്തുക. ടണൽ താഴെയുള്ളപ്പോൾ കീഴടങ്ങുന്ന ആപ്ലിക്കേഷൻ മെയിൽ ക്ലയന്റിനെയോ അപ്ഡേറ്ററിനെയോ കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ അവസാന പരിശോധന ഒരു പശ്ചാത്തല ആപ്ലിക്കേഷനോടൊപ്പം ആവർത്തിക്കുക. നിയമം, ഇന്റർഫേസ് പേരുകൾ, വീണ്ടെടുപ്പ് ഘട്ടങ്ങൾ എന്നിവ എഴുതി വയ്ക്കുക, കാരണം ആർക്കും പരിശോധിക്കാനാവാത്ത kill switch ഒരു കിംവദന്തിയാണ്.