DS-Lite આવતા IPv4 હોસ્ટિંગને બ્લોક કરે છે, જતા VPNને નહીં

અનુવાદ સ્થિતિ કનેક્શન શરૂ કરતી બાજુને અનુસરે છે. B4 અને AFTR દ્વારા જતી વિનંતીને અનુસરો, પછી જુઓ કે હોસ્ટિંગ કેમ નિષ્ફળ જાય છે.

DS-Lite એ ગ્રાહકને ફક્ત IPv6 વહન કરતા એક્સેસ નેટવર્ક પર IPv4 કનેક્ટિવિટી આપવાનો રસ્તો છે. ઘરના રાઉટર પાસે પોતાનું સમર્પિત જાહેર IPv4 સરનામું નથી, અને આ એક હકીકત લોકોને ખાતરી આપે છે કે તે કનેક્શનથી IPv4 VPN કામ કરી શકતું નથી. જતી દિશામાં તે સામાન્ય રીતે સારું કામ કરે છે. પ્રદાતા કનેક્શનનું અનુવાદ કરે છે, અને દૂરનું છેડું સામાન્ય IPv4 ક્લાયન્ટ જુએ છે. જે તૂટે છે તે વિરુદ્ધ દિશા છે: એવી વસ્તુનું હોસ્ટિંગ જે માંગ્યા વગરનું આવતું IPv4 ધારે છે. ફરક એ છે કે કઈ બાજુ વાતચીત શરૂ કરે છે.

કઈ બાજુ કનેક્શન શરૂ કરે છે

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

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

જતી વિનંતીને અનુસરો

આર્કિટેક્ચર RFC 6333 બંને છેડાને નામ આપે છે. ગ્રાહક બાજુનું ઘટક B4 છે, જે IPv4ને IPv6માં એન્કેપ્સ્યુલેટ કરે છે. પ્રદાતા બાજુનું ઘટક AFTR છે, જે સરનામાનું અનુવાદ કરે છે અને પેકેટને IPv4 તરીકે આગળ મોકલે છે.

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

VPN સર્વરને પ્રદાતાના અનુવાદિત સરનામેથી સામાન્ય IPv4 કનેક્શન મળે છે. તેને DS-Lite મોડ, ખાસ પોર્ટ કે ગ્રાહકનું એક્સેસ નેટવર્ક ફક્ત IPv6 છે તેવી કોઈ જાણની જરૂર નથી. લોકો આ ભાગ ચૂકી જાય છે: દૂરનું છેડું તે જાણી શકતું નથી.

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

આવતું હોસ્ટિંગ જ કેમ નિષ્ફળ જતો કિસ્સો છે

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

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

અહીં જ ઓપરેટર-સ્તરનું અનુવાદ એક જાહેર સરનામાથી અલગ પડે છે: સાચું સ્થાનિક ફોરવર્ડ પણ એવા સરનામા પર પડી શકે છે જે ઘણા ગ્રાહકો વહેંચે છે.

એક્સેસ પ્લાન બદલતા પહેલા નિદાન કરો

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

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

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

પ્રદાતાના ફેરફારો કાળજીપૂર્વક વાંચો

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

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

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

સંબંધિત લેખો