ડાઉન સ્ક્રિપ્ટ કે ફાયરવોલ નિયમ: લીક કોણ અટકાવે છે?
ડિસ્કનેક્ટ વખતે ઇન્ટરફેસ નીચે ઉતારવા એ કઠોર છે અને ઘણી વાર વિશેષાધિકાર વિના ચાલે છે. તેને એવા ફાયરવોલ નિયમ સાથે સરખાવો જે પતન પછી ટકી રહે છે અને અંતર બંધ કરે છે.
બે ડિઝાઇન એક જ વાતનું વચન આપે છે: જ્યારે ટનલ પડે છે, કંઈ પણ ખુલ્લું બહાર જતું નથી. એક ટિયરડાઉન વખતે સ્ક્રિપ્ટ ચલાવે છે અને ઇન્ટરફેસ કાપી નાખે છે. બીજું ફાયરવોલ નિયમ અમલમાં રાખે છે અને 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 કોઈ ચકાસી શકતું નથી તે અફવા છે.