સમાધાનિત હોસ્ટ પર કિલ સ્વિચ શું આવરી લે છે તે કેવી રીતે ચકાસવું

કિલ સ્વિચ ચાલુ કરો, ટનલ સર્વર ઑફલાઇન કરો અને મશીન હજી શું કરે છે તે જુઓ। આ પરીક્ષણ ચલાવવા યોગ્ય છે, કારણ કે તે ફાયરવોલ શું લાગુ કરે છે અને તમે શું ધાર્યું હતું તે અલગ કરે છે, અને પરિણામો મોટાભાગના ઉત્પાદન પૃષ્ઠો સૂચવે તે કરતાં સાંકડાં છે। કિલ સ્વિચ નેટવર્ક માર્ગો નિયંત્રિત કરે છે; તે ઉપકરણ પર પહેલેથી ચાલતા સોફ્ટવેરને નિયંત્રિત કરતું નથી। હું આ ક્રમ દરેક એવા મશીન પર ચલાવું છું જ્યાં ક્લાયન્ટ દાવો કરે છે કે તે fail-closed છે, અને તે લગભગ દસ મિનિટ લે છે।

સર્વરથી નહીં, ક્લાયન્ટથી શરૂ કરો

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

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

પ્રથમ પગલું: જે માર્ગોને તે આવરી લે છે તેવું તમે માનો છો તેના પર બ્લોકની પુષ્ટિ કરો

ટનલને ક્લાયન્ટ પર નહીં, દૂરના છેડે નીચે ઉતારો, જેથી ક્લાયન્ટ હજી માને કે તે જોડાયેલું હોવું જોઈએ। પછી વ્યક્તિ ખરેખર જે અજમાવશે તે અજમાવો:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

તમે એવો ક્લાયન્ટ ઇચ્છો છો જે ઝડપથી અને સ્વચ્છ રીતે નિષ્ફળ જાય, એવો નહીં જે બ્રાઉઝરની સમયમર્યાદા સુધી લટકે। લટકવું સામાન્ય રીતે એનો અર્થ છે કે પેકેટોને અસ્વીકાર વગરના નિયમ દ્વારા શાંતિથી પડતા મૂકવામાં આવે છે, જે સ્વીકાર્ય છે, પણ તે એનો પણ અર્થ હોઈ શકે કે ક્લાયન્ટે મૃત ઇન્ટરફેસ તરફ નિર્દેશિત જૂનો ડિફૉલ્ટ માર્ગ છોડી દીધો છે। ટનલ બંધ હોય ત્યારે રૂટિંગ કોષ્ટક વાંચો: હજી ટનલ ઉપકરણ તરફ નિર્દેશિત ડિફૉલ્ટ માર્ગ અને ફક્ત નવા આઉટબાઉન્ડ જોડાણોને અવરોધતો ફાયરવોલ નિયમ બે અલગ સ્થિતિઓ છે, અને તેમાંથી ફક્ત એક જ fail-closed છે।

ક્લાયન્ટના allow-LAN વિકલ્પ ચાલુ અને બંધ સાથે એ જ આદેશોનું પુનરાવર્તન કરો। એ જ ટૉગલ સૌથી વધુ આશ્ચર્યનું સ્થાન છે, કારણ કે તે એવો માર્ગ ફરી ખોલે છે જે બાકીની નીતિ બંધ કરવા માટે લખાયેલી હતી।

બીજું પગલું: DNS અને IPv6ને અલગ માર્ગો તરીકે ચકાસો

નામ વિભાજન એ એવી ખાલી જગ્યા છે જે મોટાભાગના અમલીકરણોમાં ટકી રહે છે, કારણ કે ક્વેરી સિસ્ટમ રિઝોલ્વર સિવાય બીજા કંઈક દ્વારા બહાર જઈ શકે છે। એવા સાધનથી પૂછો જે તમારી રિઝોલ્વર ગોઠવણીને અવગણે, અને ત્યાં જ v6 બાજુ ચકાસો:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

ટનલ બંધ હોય ત્યારે બંને નામ ક્વેરી માટે ખાલી જવાબો એ જ પરિણામ છે જે તમે ઇચ્છો છો। જો બીજી ક્વેરી જવાબ આપે, તો હાર્ડકોડ કરેલું રિઝોલ્વર સરનામું પહોંચી શકાય તેવું છે અને ટનલ મશીનમાંથી બહાર જવાનો એકમાત્ર માર્ગ નથી। જો ફક્ત v6 વિનંતી સફળ થાય, તો નીતિ IPv4 આવરી લે છે અને IPv6ને અવગણે છે, જે બીજા સરનામા કુટુંબમાં એ જ લીક છે।

બ્રાઉઝરો બહારથી આ વાંચવું મુશ્કેલ બનાવે છે, કારણ કે DNS over HTTPS માટે ગોઠવાયેલું બ્રાઉઝર HTTPS વિનંતી દ્વારા ક્વેરી ઉકેલે છે: ક્વેરી ત્યાં સુધી જ અવરોધાયેલી છે જેટલો તે છેડા સુધીનો પોર્ટ 443 અવરોધાયેલો છે। જે હોસ્ટ પર નીતિ સ્થાનિક સબનેટની મંજૂરી આપે છે, ત્યાં એ વિનંતી હજી પણ LAN પરના રિઝોલ્વર સુધી પહોંચી શકે છે।

ત્રીજું પગલું: નેટવર્ક એક્સપોઝરને એન્ડપોઇન્ટ એક્સપોઝરથી અલગ કરો

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

એ જ વાત એવા મોનિટરિંગ સોફ્ટવેર માટે પણ લાગુ પડે છે જે નોકરીદાતાએ જાણી જોઈને સ્થાપિત કર્યું છે। માર્ગો અવરોધવાથી તે દૂર થતું નથી, અને નવું VPN સર્વર ખરીદવું એ ઉપાય નથી, કારણ કે એક્સપોઝર ટનલની ઉપર છે।

ક્લાઉડ ખાતામાં અપલોડ કરતું ક્લિપબોર્ડ મેનેજર આ મુદ્દો તીવ્રતાથી દર્શાવે છે। ટ્રાફિક એન્ક્રિપ્ટ થયેલો છે, લક્ષ્ય માન્ય છે, અને કિલ સ્વિચ આખો સમય સ્વસ્થ સ્થિતિ જણાવે છે।

ચોથું પગલું: તમારું પરીક્ષણ જે દાવાને ટેકો આપે છે તે લખો

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

બે સમસ્યાઓ અલગ રાખો અને દરેકને તેનું પોતાનું નિયંત્રણ આપો:

• કિલ સ્વિચ: નિર્ધારિત નિષ્ફળતાની આવશ્યકતા, જે દરેક ક્લાયન્ટ અપગ્રેડ પછી પુનરાવર્તિત આઉટેજ પરીક્ષણ દ્વારા ચકાસાય છે।
• ઉપકરણ વિશ્વાસ: સમર્થિત અપડેટ્સ, વિશ્વસનીય સ્રોત તરફથી એન્ડપોઇન્ટ સંરક્ષણ, અસ્પષ્ટ પરવાનગીઓ અને પ્રમાણીકરણ વિનંતીઓની સમીક્ષા।
• ઘટના: છેતરપિંડીની શંકા હોય ત્યારે પ્લેટફોર્મ અથવા સંસ્થાની પ્રક્રિયાનું પાલન કરો; નવું સર્વર સફાઈનું પગલું નથી।
• જાહેરાત: મદદ માગતી વખતે ખાનગી કી કે સંપૂર્ણ ડાયગ્નોસ્ટિક આર્કાઇવ પેસ્ટ કરશો નહીં, કારણ કે લોગ અને સ્ક્રીનશૉટ જોડાણ જેવા જ રહસ્યો ધરાવે છે।

આગલા અપડેટ પછી ક્રમ ફરી ચલાવો, કારણ કે કિલ સ્વિચ એ ગોઠવણી છે જે આવૃત્તિઓ સાથે ખસે છે। પરીક્ષણ એ જ એકમાત્ર પુરાવો છે કે તમે જે વર્તન પર આધાર રાખો છો તે હજી પણ એ જ વર્તન છે જે તમને મળે છે।