જૂની Squid ગોઠવણીમાં dns_v4_first on છે. અપગ્રેડ પછી તે લીટી હવે અપેક્ષિત IPv4 પ્રાધાન્ય આપતી નથી. તેની વધુ નકલો ઉમેરવાથી જૂનું વર્તન પાછું નહીં આવે.

ગોઠવણી સંદર્ભ આ નિર્દેશને Squid 5 થી 7 માં અનુપલબ્ધ તરીકે સૂચવે છે. Squid ની સરનામા પસંદગી તેના Happy Eyeballs કાર્ય સાથે બદલાઈ; જૂની પ્રાધાન્ય સલાહ તે આવૃત્તિના સંદર્ભમાં વાંચવી જોઈએ.

પ્રાધાન્ય અને ફરજિયાતતા બે અલગ વિનંતીઓ છે

પહેલા નક્કી કરો કે તમને શું જોઈએ. બંને પરિવારો ઉપલબ્ધ હોય ત્યારે કાર્યક્ષમ IPv4 માર્ગને પ્રાધાન્ય આપવું? તૂટેલી IPv6 કનેક્ટિવિટી દૂર કરવી? કોઈ ચોક્કસ એક્ઝિટ ફક્ત IPv4 વાપરે તેની ખાતરી કરવી? આ એક જ નીતિ નથી. ગંતવ્ય-પરિવાર પ્રતિબંધો પણ ક્લાયન્ટ-સ્રોત ACL થી અલગ રહેવા જોઈએ.

એક પરિવારનો ઍક્સેસ બંધ કરવાથી કેટલીક સાઇટ્સ અગમ્ય બની શકે. DNS જવાબો બદલવાથી પ્રોક્સી માટે ઉપલબ્ધ ઉમેદવારો બદલાય છે. ધીમો કે તૂટેલો માર્ગ સુધારવો નેટવર્ક ખામીનો ઉકેલ છે. આમાંથી કોઈને પણ દૂર કરેલા નિર્દેશની સાર્વત્રિક બદલી લીટી તરીકે વર્ણવવું જોઈએ નહીં.

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

સ્રોત-સરનામાના નિયમની બીજી ભૂમિકા છે: તે કનેક્શન માટે સુસંગત સ્રોત પસંદ કરે છે, ગંતવ્યનું સમર્થન ઊભું કરતું નથી. IPv4 સ્રોત ફક્ત-IPv6 ગંતવ્યને IPv4 એન્ડપોઇન્ટ બનાવતું નથી.

સ્થાપિત આવૃત્તિનું દસ્તાવેજીકરણ અને સંપૂર્ણ ફોરવર્ડિંગ માર્ગ તપાસો. જો સમસ્યા અવિશ્વસનીય IPv6 કનેક્શન હોય, તો તે નિદાન જાળવી રાખો, તેને ઢાંકી દેતું મૌન વૈશ્વિક પરિવર્તન ન કરો. કાર્યક્ષમ પ્રાધાન્ય માર્ગ અને કડક એક-પરિવાર એક્ઝિટને અલગ ગોઠવણીઓ જોઈએ.

સંબંધિત લેખો