Windows 11 દરેક L2TP/IPsec તબક્કા માટે અલગ નંબર નોંધે છે, અને તે નંબર નિષ્ફળતાનું મૂલ્યાંકન કરવાને બદલે તબક્કો દર્શાવે છે. 789 PPP લિંક અસ્તિત્વમાં આવે તે પહેલા નિષ્ફળ જાય છે, 720 લિંક ઉપર આવતી વખતે નિષ્ફળ જાય છે, અને 691 લિંક ઉપર આવ્યા પછી અને ઓળખપત્રો નકારાયા પછી નિષ્ફળ જાય છે. ઉપયોગી નિર્ણય એ નથી કે કયો સુધારો સૌથી લોકપ્રિય છે; એ છે કે કોડ સાબિત કરે છે કે તમે કયા તબક્કે પહોંચ્યા છો. પહેલા તે વાંચો, પછી દરેક પ્રયાસે એક સ્તર બદલો જેથી આગળનો કોડ તમને હજી કંઈક કહે.

કોડને તબક્કા તરીકે વાંચો, ખામીઓની યાદી તરીકે નહીં

L2TP કનેક્શન નિશ્ચિત ક્રમમાં ત્રણ સીમાઓ પાર કરે છે. IKE UDP 500 પર સુરક્ષા સંગઠનોની વાટાઘાટ કરે છે, NAT ટ્રાવર્સલ તે ટ્રાફિકને UDP 4500 પર ખસેડે છે, અને ત્યાર પછી જ L2TP ટનલ PPP સત્ર વહન કરે છે જે વપરાશકર્તાને પ્રમાણિત કરે છે અને સરનામું સોંપે છે.

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

789: માર્ગ અને સ્થાનિક નીતિ વચ્ચે પસંદ કરો

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

ખાતરી કરો કે UDP 500 અને UDP 4500 સર્વર સુધી પહોંચે છે અને પૂર્વ-વહેંચાયેલ કી બાઇટ દીઠ બાઇટ મેળ ખાય છે, જેમાં અક્ષરનું કદ અને અંતિમ જગ્યાઓનો સમાવેશ થાય છે. જો સર્વર NAT પાછળ હોય, તો Windows ને દસ્તાવેજીકૃત રજિસ્ટ્રી મૂલ્યની પણ જરૂર પડી શકે. જ્યારે સર્વર NAT પાછળ હોય ત્યારે 1 અને જ્યારે બંને છેડા હોય ત્યારે 2 વાપરો, પછી પુનઃપ્રારંભ કરો કારણ કે નીતિ એજન્ટ શરૂઆતમાં મૂલ્ય વાંચે છે:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

ભારે એડેપ્ટર સમારકામ બીજી શાખાનું છે. Wi-Fi ઉપકરણ અને WAN મિનીપોર્ટ દૂર કરીને પછી હાર્ડવેર માટે ફરી સ્કેન કરવું ત્યારે વાજબી છે જ્યારે સ્થાનિક IPsec સ્ટેક પોતે નુકસાનગ્રસ્ત હોય અને અન્ય VPN પ્રકારો પણ એ જ રીતે નિષ્ફળ જાય. જ્યારે ફક્ત એક L2TP સર્વર નિષ્ફળ જાય અને અન્ય દરેક નેટવર્ક માર્ગ કામ કરે ત્યારે તે વ્યર્થ પ્રયાસ છે.

720: આ એડેપ્ટર અને સર્વર પૂલ વચ્ચે પસંદ કરો

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

નિર્ણય માટે અસર ત્રિજ્યા વાપરો. એક Windows મશીન નિષ્ફળ જવું ખરાબ WAN મિનીપોર્ટ, અટકેલી Remote Access સેવા અથવા ભ્રષ્ટ કનેક્શન પ્રોફાઇલ તરફ ઇશારો કરે છે. ઘણા ક્લાયન્ટ એક જ સમયે નિષ્ફળ જવું સર્વર તરફ ઇશારો કરે છે: ખાલી થયેલ સરનામા પૂલ, અટકેલી RRAS સેવા અથવા એવો પૂલ જે હવે ક્લાયન્ટ સબનેટ સાથે મેળ ખાતો નથી. બીજી બાજુ બદલતા પહેલા પેટર્ન જે બાજુ દર્શાવે છે તે સુધારો.

એક-ક્લાયન્ટ શાખામાં, WAN મિનીપોર્ટ એક વાર દૂર કરો અને હાર્ડવેર ફેરફારો સ્કેન કરો, પછી પુનઃપ્રારંભ કરો અને ફરી પ્રયાસ કરો. સર્વર શાખામાં, ક્લાયન્ટને બદલે પૂલ અને સેવાની સ્થિતિ તપાસો, કારણ કે કામ કરતું એડેપ્ટર ફરી ઇન્સ્ટોલ કરવાથી એવું સરનામું બની શકતું નથી જે સર્વર પાસે નથી.

691: ઓળખપત્ર અને અટકેલા સહાયક વચ્ચે પસંદ કરો

કોડ 691 પ્રમાણીકરણનો અસ્વીકાર છે, અને તે કોડ છે જેને ઘણી વાર ખોટા પાસવર્ડ તરીકે ખોટી રીતે વાંચવામાં આવે છે. ટનલ ઉપર છે, ગેટવેએ ઓળખ જોઈ અને તે ઓળખ નકારી. કારણ હજી પણ પાસવર્ડ ક્ષેત્રની બહાર હોઈ શકે છે.

પહેલા ડોમેન ક્ષેત્ર તપાસો, પછી પાસવર્ડમાંના ચોક્કસ અક્ષરો. જગ્યા, અવતરણ ચિહ્ન અથવા શેલ-વિશેષ અક્ષર ધરાવતો પાસવર્ડ સર્વર સુધી પહોંચતા પહેલા બગડી શકે છે; Linux પર, pppd સમાન અસ્વીકાર નોંધે છે જે E=691 અવતરણ ચિહ્ન વગરના મૂલ્ય અથવા ખૂટતા ડોમેન માટે. રહસ્યને પેસ્ટ કરવાને બદલે ફરી ટાઇપ કરો, અને જૂનું મૂલ્ય ધરાવી શકે તેવા કોઈપણ સાચવેલા ઓળખપત્રને સાફ કરો.

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

શાખાઓ અલગ કરવા માટે, સમાન વપરાશકર્તાનામ બીજી કામ કરતી VPN પ્રોફાઇલ અથવા RADIUS ટેસ્ટ ખાતા સામે ચકાસો. જો તે સફળ થાય, તો ઓળખપત્ર ઠીક છે અને સ્થાનિક ક્લાયન્ટ માર્ગ શંકાસ્પદ છે. જો તે એ જ રીતે નિષ્ફળ જાય, તો સમસ્યા ખાતું અથવા ગેટવે નીતિ છે.

દરેક પ્રયાસે એક સ્તર બદલો

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

દરેક પ્રયાસ પહેલા અને પછીના કોડનો, ક્લાયન્ટ બિલ્ડનો, અને સર્વર કે ક્લાયન્ટ બદલાયું કે નહીં તેનો ટૂંકો લોગ રાખો. 789, પછી 720, પછી 691 જેવો ક્રમ પ્રગતિનો નકશો છે; એ જ કોડ બે વાર આવવાનો અર્થ છે કે છેલ્લો ફેરફાર તે તબક્કાને સંબોધતો નથી. Windows ફરી ઇન્સ્ટોલ કરવાથી આ નકશો ભૂંસાઈ જાય છે અને ગેટવે પર રહેલી નિષ્ફળતા ભાગ્યે જ સુધરે છે.

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

સંબંધિત લેખો