શું VPN કિલ સ્વિચ રીબૂટ પછી ટકી રહે છે? કેવી રીતે ચકાસવું

રીબૂટ કરવું એ લોકો કિલ સ્વિચનું પરીક્ષણ કરવાની સૌથી સામાન્ય રીત છે, અને તે જ પરીક્ષણ સૌથી વધુ ખોટું બોલે છે. ક્લાઇન્ટમાંનું ચેકબોક્સ એક પસંદગી છે; મહત્વનું એ છે કે નેટવર્ક સ્ટેક ઉપર આવે તે ક્ષણ અને ટનલ ખરેખર સ્થપાય તે ક્ષણ વચ્ચે કંઈક બ્લોક લાગુ કરે છે કે નહીં. વિન્ડોઝ પર તે કંઈક સામાન્ય રીતે Windows Filtering Platform માં એક ફિલ્ટર હોય છે, લિનક્સ પર એક યુનિટ દ્વારા લોડ કરાયેલ નિયમસમૂહ, મેકઓએસ પર pf એન્કર, એન્ડ્રોઇડ પર સિસ્ટમની પોતાની ઑલવેઝ-ઓન અને લૉકડાઉન ફ્લેગ. આ ગોઠવણો રીબૂટ દરમિયાન ખૂબ જ અલગ રીતે વર્તે છે, અને ફક્ત પ્લેટફોર્મ-સ્તરની ગોઠવણો જ કોઈ સાઇન ઇન કરે તે પહેલાં તેમના સ્થાને હોય છે.

રીબૂટ ત્રણ અલગ પ્રશ્નો પૂછે છે

પ્રશ્નને વિભાજિત કરો. પ્રથમ, શું નીતિ ડિસ્ક પર એવા સ્વરૂપમાં છે જેને બૂટ વખતે કંઈક વાંચે છે? બીજું, શું તે વાચક કોઈપણ ટ્રાફિક બહાર જાય તે પહેલાં ચાલે છે? ત્રીજું, શું નીતિ તમને મહત્વની ટ્રાફિકને આવરી લે છે, એટલે કે દરેક પ્રક્રિયા, બંને સરનામાં કુટુંબ અને DNS. પ્રથમને હા અને બીજાને ના એ બરાબર એ જ નિષ્ફળતા ઉત્પન્ન કરે છે જેને લોકો એવા કિલ સ્વિચ તરીકે જણાવે છે જે રીબૂટ પછી ટકતું નથી: શરૂઆતમાં થોડી સેકન્ડ માટે ટ્રાફિક છટકી જાય છે, અને કોઈ શોધવા ન જાય ત્યાં સુધી કોઈ ધ્યાન આપતું નથી.

સ્તરોને અલગ રાખો. સાચવેલ ફાયરવોલ નિયમસમૂહ, બૂટ પર શરૂ થતી સેવા અને ક્લાઇન્ટ પસંદગી એ ત્રણ અલગ વસ્તુઓ છે જેમનું ત્રણ અલગ આયુષ્ય છે. પસંદગી રીબૂટ ટકી રહે છે કારણ કે તે કન્ફિગ ફાઇલમાંનું મૂલ્ય છે. નિયમો જ એકમાત્ર વસ્તુ છે જે પેકેટને બ્લોક કરે છે, અને તેઓ જે કર્નલ રાખતું હતું તેની સાથે અદૃશ્ય થઈ જાય છે.

બ્લોક પુનઃસ્થાપિત કરતી વસ્તુ શોધો

લિનક્સ પર netfilter નિયમો કર્નલમાં રહે છે. તમે ગોઠવણ ન કરી હોય તો બૂટ વખતે કંઈ પણ તેમને પાછા લખતું નથી: iptables-save વત્તા netfilter-persistent, nftables.service લોડ કરે છે /etc/nftables.conf, અથવા તમારી પોતાની સ્ક્રિપ્ટ ચલાવતું systemd યુનિટ. શું સક્ષમ છે તે તપાસો, તમે શું ગોઠવ્યું હતું તે યાદ કરવાને બદલે.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

બૂટના થોડી સેકન્ડ પછી ખાલી નિયમસમૂહ એ શીર્ષકના પ્રશ્નનો જવાબ છે. વિન્ડોઝ પર ક્લાઇન્ટ સેવાને પૂછો કે તે કેવી રીતે શરૂ થાય છે, પછી ટનલ નીચે હોય ત્યારે પ્લેટફોર્મ ફિલ્ટરની સ્થિતિ ડમ્પ કરો.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

બીજો આદેશ wfpstate.xml વર્તમાન ડિરેક્ટરીમાં લખે છે. ક્લાઇન્ટ જોડાય તે પહેલાં પહેલેથી અસ્તિત્વમાં હોય એવા બ્લોક ક્રિયાવાળા ફિલ્ટર શોધો. Base Filtering Engine બૂટની શરૂઆતમાં જ શરૂ થાય છે અને કાયમી ફ્લેગ સાથે ઉમેરાયેલા ફિલ્ટર પુનઃસ્થાપિત કરે છે, તેથી કેટલાક કિલ સ્વિચ કોઈ ક્લાઇન્ટ વિન્ડો અસ્તિત્વમાં આવે તે પહેલાં ટ્રાફિક બ્લોક કરે છે અને કેટલાક નહીં. મેકઓએસ પર sudo pfctl -s info જણાવે છે કે pf સક્ષમ છે કે નહીં, sudo pfctl -s rules બતાવે છે કે શું લોડ થયું છે, અને VPN ક્લાઇન્ટ સામાન્ય રીતે તેમના નિયમોને મુખ્ય નિયમસમૂહને બદલે એન્કર સાથે જોડે છે. જે નિયમ utun3 નામ ધરાવે છે તે આગલા બૂટ પછી બીજા ઇન્ટરફેસ તરફ ઇશારો કરી શકે છે, કારણ કે તે નંબર રનટાઇમમાં અપાય છે.

નેટવર્ક ઉપર આવવા અને ટનલ ઉપર આવવા વચ્ચેના અંતર પર નજર રાખો

ખતરનાક અંતરાલ આખું રીબૂટ નથી, તે અંતર છે. ઇન્ટરફેસને એક ક્ષણે લીઝ અને ડિફૉલ્ટ રૂટ મળે છે, VPN સેવા બીજી ક્ષણે શરૂ થાય છે, અને ટનલ વધુ મોડું પ્રમાણીકરણ કરે છે, કેટલીકવાર વપરાશકર્તા સાઇન ઇન કરે અને ક્રેડેન્શિયલ એજન્ટ ચાલે તે પછી જ. જો બ્લોક સૌથી છેલ્લે લાગુ થાય, તો અંતરમાંનું બધું ખુલ્લું બહાર જાય છે.

systemd યજમાનો પર, અનુમાન કરવાને બદલે ક્રમ વાંચો. VPN અને ફાયરવોલ યુનિટ પર systemctl cat ચલાવો અને After= અથવા Before= ને network-pre.target અને network-online.target સામે જુઓ. network-online.target પછી ક્રમાંકિત ફાયરવોલ યુનિટ ઇન્ટરફેસ સામે હારી જાય છે; જે network-pre.target દ્વારા માંગવામાં આવે છે અને તેની પહેલાં ક્રમાંકિત છે તે જીતે છે. વિન્ડોઝ પર સમાન પ્રશ્નો સેવાનો સ્ટાર્ટ પ્રકાર અને તેની નિર્ભરતાઓ છે, કારણ કે Manual પર સેટ કરેલી સેવા બૂટ-સમયની પ્રક્રિયાને બ્લોક કરી શકતી નથી. જો તમારી આવશ્યકતામાં સાઇન-ઇન પહેલાંનો ટ્રાફિક સમાવિષ્ટ હોય, તો ફક્ત ઉપકરણ-સ્તરની ગોઠવણ જ તેને સંતોષે છે: Always On VPN ઉપકરણ ટનલ મશીન પ્રમાણપત્ર સાથે પ્રમાણીકરણ કરે છે અને વપરાશકર્તા લૉગ ઇન કરે તે પહેલાં જોડાય છે, અને Microsoft ઉપકરણ ટનલની રૂપરેખા દસ્તાવેજ કરે છે વપરાશકર્તા ટનલથી અલગ. એન્ડ્રોઇડ બીજો માર્ગ લે છે, ઑલવેઝ-ઓન VPN લાગુ કરે છે અને તેના વિના જોડાણોને એપ્લિકેશન પ્રક્રિયામાંથી નહીં પણ સિસ્ટમમાંથી બ્લોક કરે છે.

પરીક્ષણ ચલાવો, પછી બે સમયરેખાઓ સરખાવો

રીબૂટ કરો એવા ગંતવ્ય સાથે જે લીક થાય તો કંઈ ખર્ચ ન કરે, અને અંતર પછી નહીં પણ અંતર દરમિયાન સ્થિતિ કેપ્ચર કરો. સૌથી સ્વચ્છ પદ્ધતિ બૂટ-સમય પ્રોબ છે: oneshot યુનિટ અથવા શેડ્યૂલ કરેલ કાર્ય જે પ્લેટફોર્મ પરવાનગી આપે તેટલું વહેલું શરૂ થાય છે, ડિફૉલ્ટ રૂટ અને ફાયરવોલ સ્થિતિ નોંધે છે, ટૂંકા ટાઇમઆઉટ સાથે એક વિનંતીનો પ્રયાસ કરે છે અને સ્થાનિક ફાઇલમાં એક લીટી ઉમેરે છે. તે રેકોર્ડને journalctl -b -u અથવા સિસ્ટમ લોગમાંથી VPN સેવાના શરૂ થવાના સમય સાથે સરખાવો.

પછી સામાન્ય પરીક્ષણ ચલાવો: ટનલ ઉપર, જોડાણ કાપો, સીધો ટ્રાફિક બ્લોક થાય છે કે નહીં તે જુઓ, પુનઃસ્થાપિત કરો. બીજામાં પાસ થવું અને પ્રથમમાં નિષ્ફળ જવું એ સામાન્ય પરિણામ છે, અને તેનો અર્થ એ છે કે અમલ ક્લાઇન્ટ-બાજુ છે, જ્યારે ક્લાઇન્ટ જોડાય ત્યારે લાગુ થાય છે, બૂટ પર નહીં. મેં ઑડિટ કરેલા છેલ્લા મશીન પર, બ્લોક NetworkManager ડિસ્પેચર સ્ક્રિપ્ટમાંથી આવ્યો હતો: હાજર અને સાચો અને ઇન્ટરફેસ ઉપર આવે તે પહેલાંની સેકન્ડો માટે નકામો. બંને પરિણામો લખો, કારણ કે રીબૂટ ટકી રહેવું ત્યારે જ અર્થપૂર્ણ છે જ્યારે તમે કહો કે કયો સ્તર ટક્યો અને કઈ ક્ષણથી.

પાછા ફરવાનો માર્ગ તોડ્યા વિના અંતર બંધ કરો

જો બૂટ પર બ્લોક ખૂટે છે, તો બીજો ક્લાઇન્ટ નિયમ ઉમેરવાને બદલે અમલને એક સ્તર નીચે ખસેડો. નિયમસમૂહ સાચવો અને તેને નેટવર્ક વાપરી શકાય તે પહેલાં ક્રમાંકિત યુનિટમાંથી લોડ કરો, અને ખાતરી કરો કે તે યુનિટને એવા DNS લુકઅપ કે નેટવર્ક માઉન્ટની જરૂર નથી જેને તે રક્ષણ આપવાનું છે. વ્યાપ્તિ સમય જેટલી જ મહત્વની છે: વપરાશકર્તા ID અથવા cgroup સાથે મેળ ખાતા નિયમો દરેક સિસ્ટમ ડિમનને બ્લોકની બહાર રાખે છે, અને ફક્ત IPv4 સંભાળતો નિયમસમૂહ IPv6 અને DNS ને પહોંચવા યોગ્ય રાખે છે.

તમારા માટે પાછા ફરવાનો માર્ગ રાખો. જે મશીન બૂટ પર બધું બ્લોક કરે અને પછી પ્રમાણીકરણ કરી શકતું નથી તેની પાસે નેટવર્ક જ નથી, અને ઉપાય બ્લોક કાઢી નાખવો નહીં પણ ક્રેડેન્શિયલ કે ક્રમ સુધારવો છે. સ્થાનિક કન્સોલ માટે દસ્તાવેજીકૃત પ્રક્રિયા અને ટનલને ખરેખર જેની જરૂર છે તેના માટે સાંકડો, જાણી જોઈને કરેલો અપવાદ રાખો, જેમ કે સર્વરનું સરનામું અને ટનલ પહેલાં વપરાતું રિઝોલ્વર.

ગોઠવણ પર ભરોસો કરતા પહેલાં, ચાર વસ્તુઓ ક્રમમાં પુષ્ટિ કરો. નીતિ એવી જગ્યાએ સંગ્રહિત છે જ્યાંથી બૂટ વાંચે છે. તે વાચક ઇન્ટરફેસ વાપરી શકાય તે પહેલાં ચાલે છે. બ્લોક બંને સરનામાં કુટુંબ અને DNS આવરી લે છે. બ્લોક સક્રિય હોય ત્યારે પણ VPN પ્રમાણીકરણ કરી શકે છે. જ્યારે ચારેય પૂરા થાય, રીબૂટ કંઈ બદલતું નથી.