Windows NAT-T રજિસ્ટ્રી મૂલ્ય: પહેલા ટોપોલોજી તપાસો

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

મૂલ્ય ખરેખર શું પસંદ કરે છે

AssumeUDPEncapsulationContextOnSendRule નક્કી કરે છે કે Windows IPsec અમલીકરણ NAT ઉપકરણ પાછળના સહભાગી સાથે સંકળાયેલતા બનાવવાનો પ્રયાસ કરશે કે નહીં. દસ્તાવેજીકૃત ડિફોલ્ટ 0 એ કેસની પરવાનગી આપતું નથી, 1 તેને પરવાનગી આપે છે જ્યારે સર્વર NAT પાછળની બાજુ હોય, અને 2 બંને છેડા અનુવાદિત થવાનો કેસ આવરી લે છે. આ ટોપોલોજી વિશેનાં વિધાનો છે—કોણ ક્યાં છે.

ક્રમ તરીકે વાંચીએ તો સંખ્યાઓ વધતી વિશ્વસનીયતા નહીં, પરંતુ વધતો અનુવાદ વર્ણવે છે. જ્યાં કંઈ અનુવાદિત થતું નથી તેવા નેટવર્ક પર 2 સેટ કરવાથી કનેક્શન ઝડપી કે વધુ સ્થિર થતું નથી, અને પ્રમાણીકરણની નિષ્ફળતા પણ સુધરતી નથી. Microsoft ની L2TP/IPsec માટે NAT માર્ગદર્શિકા નીતિ અને તેના ઐતિહાસિક પ્લેટફોર્મ સંદર્ભનું દસ્તાવેજીકરણ કરે છે. તમે ખરેખર ચલાવો છો તે Windows આવૃત્તિ અને ભૂમિકા સામે એ સંદર્ભ તપાસો, કારણ કે ઘણી આવૃત્તિઓ ટકી રહેલું દસ્તાવેજ દરેક વર્તમાન બિલ્ડ વિશેનું વિધાન નથી.

સંખ્યા પહેલાં ટોપોલોજી મેળવો

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

વર્તમાન Windows Server આવૃત્તિઓ ફક્ત NAT traversal બંધ સાથે આવે છે એ દાવો કાર્ય કરવા માટે ઘણો વ્યાપક છે. મહત્વનું છે તમારી સિસ્ટમ પરની નીતિ, તેની સામેની ટોપોલોજી અને નિષ્ફળ ગયેલું આદાનપ્રદાન—એ જ ક્રમમાં. જો બંને છેડાનાં જાહેર સરનામાં હોય, તો સેટિંગ તમારી સમસ્યા નથી. તેના બદલે પ્રસ્તાવ, પ્રમાણપત્ર કે ખાતું જુઓ, અને રજિસ્ટ્રીને રહેવા દો.

પહેલા નિષ્ફળતાનો તબક્કો તપાસો

L2TP/IPsec ઓછામાં ઓછી ત્રણ અલગ નિષ્ફળતાઓ ઉત્પન્ન કરે છે: સહભાગી સુધી પહોંચી શકાતું નથી, IPsec રક્ષણ સ્થાપિત થઈ શકતું નથી, અને ટનલ અસ્તિત્વમાં આવ્યા પછી PPP વપરાશકર્તા પ્રમાણીકરણ નકારવામાં આવે છે. નકારેલું ખાતું NAT નીતિ બદલીને સુધારી શકાતું નથી, અને પ્રસ્તાવની અસંગતિ રીસ્ટાર્ટથી સુધારી શકાતી નથી.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

HTTPS પર SSTP અને મૂળ IKEv2 ના પોતાના લોગ અને પોતાના નિયંત્રણો છે. ફક્ત Windows પર ચાલવાને કારણે તેમાંથી કોઈ NAT-traversal કેસ બનતું નથી.

પાછા ફરવાનો માર્ગ રાખીને ફેરફાર કરો

જો દસ્તાવેજીકૃત નીતિ અને નિરીક્ષિત ટોપોલોજી બંને તેની માંગ કરે, તો અગાઉનું મૂલ્ય નોંધો, દરેક પ્રોફાઇલની સ્ક્રિપ્ટને બદલે સંચાલિત રૂપરેખાંકન દ્વારા ફેરફાર લાગુ કરો, અને રીસ્ટાર્ટનું આયોજન કરો. અન્ય વર્કલોડને ટેકો આપતા સર્વર પર આ નિર્દોષ ફેરફાર નથી.

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