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

ચાર પગલાં, અને પહેલું બાર નહીં પણ લોગ વાંચવાનું છે.

98% કાઉન્ટર ખરેખર શું જણાવે છે

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

Fortinet એ આ લક્ષણને ક્લાયન્ટ-બાજુના એક જ કારણ સામે દસ્તાવેજ કર્યું છે: ક્લાયન્ટ જે એડેપ્ટર વાપરે છે તેના પર IPv6 સક્ષમ હોવું. આ એડેપ્ટર સેટિંગને પરીક્ષણ કરવાની પહેલી વસ્તુ બનાવે છે, દરેક SSL-VPN અટકાવ માટે સાર્વત્રિક સમજૂતી નહીં.

પગલું 1: બાર પહેલાં લોગ વાંચો

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

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

પગલું 2: IPv6 ફેરફારને એક એડેપ્ટર સુધી મર્યાદિત કરો

ફેરફાર એડેપ્ટરનો છે, મશીનનો નહીં. Windows એડેપ્ટર ગુણધર્મોમાં તેનો અર્થ ચોક્કસ ઇન્ટરફેસ પર Internet Protocol Version 6 (TCP/IPv6) દૂર કરવું, અને શેલમાંથી તે છે Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. ફરી કનેક્ટ કરતા પહેલાં Get-NetAdapterBinding -ComponentID ms_tcpip6 વડે સ્થિતિની ખાતરી કરો. પછી ફરી કનેક્ટ કરો અને જુઓ કે બાર ત્યાં અટકવાને બદલે 98% વટાવે છે કે નહીં.

પહેલાં અવકાશ નક્કી કરો, પછી પરીક્ષણ કરો. IPv6 ને વૈશ્વિક રીતે બંધ કરવું પ્રશ્નની જરૂર કરતાં મોટો ફેરફાર છે અને તે સેવાઓને અસર કરે છે જેને તમે સ્પર્શ કરવા માંગતા ન હતા.

પગલું 3: અટકાવ શું છુપાવી રહ્યો હતો તે ચકાસો

જે ટનલ કનેક્ટ થાય છે તે કામ કરતી ટનલ નથી. ક્લાયન્ટે ફાળવેલું સરનામું, પ્રોફાઇલે ઇન્સ્ટોલ કરેલા રૂટ અને એક આંતરિક હોસ્ટ માટે નામ-નિરાકરણ તપાસો: Resolve-DnsName files.corp.example. જે ક્લાયન્ટ કનેક્ટ થાય છે અને કંઈ નિરાકરણ કરતો નથી તેમાં DNS સમસ્યા છે, અને તેને એ જ ખામી પાછી આવી હોવાનું ખોટું વાંચવું સહેલું છે.

એક આંતરિક સંસાધન નામથી અને એક જાહેર ગંતવ્ય પરીક્ષણ કરો, જેથી તૂટેલી સ્પ્લિટ ટનલને સુધારેલો ક્લાયન્ટ ન સમજવામાં આવે.

પગલું 4: સુધારાને પુનરાવર્તનયોગ્ય બનાવો

જો સેટિંગ ફ્લીટ સુધી પહોંચવું હોય, તો તેને દરેક લેપટોપ પર પુનરાવર્તિત થતા જાતે કરવાના પગલાને બદલે ડિપ્લોયમેન્ટ પેકેજમાં કે એડેપ્ટર કન્ફિગરેશનમાં મૂકો. ટિકિટમાં નોંધો કે 98% અટકાવ નેટવર્ક ઇન્ટરફેસ પરના IPv6 સાથે જોડાયેલો હતો, અને હોસ્ટ પર બીજું શું IPv6 પર આધારિત હતું તે નોંધો, કોઈ તેને અસંબંધિત કંઈક સુધારવા ફરી સક્ષમ કરે તે પહેલાં.

જે સુધારો ફક્ત એક ઇજનેરની યાદમાં અસ્તિત્વ ધરાવે છે તે આગલા ક્વાર્ટરમાં પાછો આવતો સુધારો છે.

જો IPv6 બંધ હોવા છતાં બાર હજી 98% પર અટકે છે, તો વેન્ડરની નોંધ હવે તેની સમજૂતી આપતી નથી અને લોગ તમારો આગલો પુરાવો છે. લક્ષણની સારવાર બંધ કરો અને તબક્કા-કાઉન્ટર પર પાછા જાઓ.

સંબંધિત લેખો