કિલ સ્વિચ ફક્ત IPv4 બ્લોક કરે છે: IPv6 હજી કેમ બહાર જાય છે

ટનલ પડી જાય છે, કિલ સ્વિચ જણાવે છે કે તેણે કાર્ય કર્યું, અને ડાઉનલોડ ચાલુ રહે છે. IPv4 નિયમોમાં કંઈ તૂટ્યું નથી. એપ ફક્ત એવા માર્ગ પર ખસી ગઈ જેના માટે એ નિયમો ક્યારેય લખાયા નહોતા.

ડ્યુઅલ-સ્ટેક ઉપકરણોમાં બહાર જવાના બે સ્વતંત્ર માર્ગો હોય છે. તેમાંથી એક પરનું બ્લોક અડધું બ્લોક છે.

બે નિયમ સમૂહો, બે ડિફોલ્ટ

Linux પર, iptables અને ip6tables અલગ નીતિઓ સાથેનાં અલગ કોષ્ટકો છે. IPv4 કોષ્ટકની INPUT અને OUTPUT ચેઇનને DROP પર મૂકવાથી IPv6 કોષ્ટકમાં કંઈ બદલાતું નથી, જ્યાં ડિફોલ્ટ સામાન્ય રીતે ACCEPT હોય છે. એ જ વિભાજન nftables માં પણ છે, જ્યાં તમે એક કુટુંબની તપાસ કરી શકો છો અને જાણી શકો છો કે તેમાંથી ફક્ત એક જ તમારા નિયમો ધરાવે છે. આ અસમપ્રમતા સામાન્ય છે, અને આખી સમસ્યા એ જ છે.

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

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

ઇન્ટરફેસ રૂપરેખાંકન તમને શું કહે છે

wg-quick નું મેન્યુઅલ પૃષ્ઠ તેની ઉદાહરણ રૂપરેખાંકનમાં IPv6 નિયમો સમાવે છે, અને કારણ બરાબર આ અંતર છે. ઉદાહરણ સજાવટ નથી. તે એટલા માટે અસ્તિત્વમાં છે કારણ કે ફક્ત IPv4 નિયમો બીજા કુટુંબને ખુલ્લું રાખશે.

ઉદાહરણનો અડધો ભાગ કોપી કરવાથી નીતિનો અડધો ભાગ બને છે. આ લીકનું સૌથી સામાન્ય મૂળ છે. એક બ્લોગ પોસ્ટે લંબાઈ માટે ઉદાહરણ ટૂંકાવ્યું. પછી ટૂંકાવેલી આવૃત્તિ એ ટેમ્પલેટ બની જે દરેકે ફરી વાપરી.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

જો બીજો આદેશ પરવાનગી આપતી નીતિ છાપે છે જ્યારે પહેલો DROP છાપે છે, તો તમે ક્લાઇન્ટને સ્પર્શ કર્યા વિના જવાબ શોધી લીધો છે. એ અસમપ્રમતા જ ખામી છે.

એક શોધ જ આખી વાર્તા કેમ નથી

એક નામ એકસાથે A રેકોર્ડ અને AAAA રેકોર્ડ બંને પરત કરી શકે છે, અને બધી એપ્સ એક જ રીતે પસંદ કરતી નથી. નેટવર્ક IPv6 આપે ત્યારે બ્રાઉઝર તેને પસંદ કરી શકે છે અને નિષ્ફળતા પર પાછું જઈ શકે છે, જ્યારે પૃષ્ઠભૂમિ સિંક અથવા અપડેટર પોતાનું રિઝોલ્વર અને પોતાની પસંદગી વાપરે છે. તેથી IPv4 પરની એક સફળ કસોટી એક માર્ગ સાબિત કરે છે, નીતિ નહીં.

નેટવર્ક સંક્રમણો પણ જવાબ બદલે છે. બીજા Wi-Fi નેટવર્કમાં જવું, ઊંઘમાંથી જાગવું અથવા મોબાઇલ પર જવું ઉપકરણને નવો IPv6 પ્રીફિક્સ આપી શકે છે, અને ઓફિસ LAN પર પૂરતી લાગતી નીતિ તેને આવરી ન પણ શકે.

ટનલ બંધ હોય તે સ્થિતિની કસોટી કરો

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

બંને કુટુંબોએ બંધ થઈને નિષ્ફળ જવું જોઈએ. જો IPv4 વિનંતીનો સમય પૂરો થાય અને IPv6 વિનંતી સ્ટેટસ કોડ પરત કરે, તો નીતિ અપૂર્ણ છે, અને ટનલની ફરી કસોટી કરવાથી તે બદલાશે નહીં.

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