IPv6 ટેકો ધરાવતું પ્રોક્સી લિસનર જૂના PAC નિયમને IPv6-જાણકાર બનાવતું નથી. લિસનર સુધી પહોંચવું અને લક્ષ્યને યોગ્ય રીતે વર્ગીકૃત કરવું અલગ જરૂરિયાતો છે.

નિયમ ઇનપુટશું તપાસવું
dnsResolve, myIpAddress, isInNet જૂના ઉદાહરણોમાંIPv4 સરનામું/માસ્કની ધારણાઓ. કોલોનથી વિભાજિત ડેટા પર ખોટો મેળ અસમર્થિત ઇનપુટ સૂચવી શકે છે, નેટવર્કની બહારનું લક્ષ્ય નહીં.
dnsResolveEx અથવા isInNetExક્લાયન્ટનો ટેકો, જરૂરી પ્રવેશ બિંદુ અને દસ્તાવેજીકૃત રિટર્ન ફોર્મેટ.

Microsoft આ IPv6-જાણકાર એક્સ્ટેન્શન નું દસ્તાવેજીકરણ કરે છે. દરેક બ્રાઉઝર અથવા WinHTTP ગ્રાહકને પોતાની ટેકા-ચકાસણીની જરૂર છે; એક કાર્યરત ક્લાયન્ટ બધે સુસંગતતા સ્થાપિત કરી શકતો નથી.

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

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

સંબંધિત લેખો