જો તમે «VPN પ્રમાણપત્ર» બદલો તો કદાચ ખોટી સેવા બદલી શકો. RRAS ઓછામાં ઓછા ત્રણ પ્રમાણપત્ર નિયંત્રણો રાખે છે અને તેમાંથી દરેક જુદા પ્રોટોકોલ અને જુદી કનેક્શન ભૂમિકા સાથે સંબંધિત છે. પહેલાં પ્રોટોકોલનું નામ લેવું જોખમી અનુમાનને એક જ પાછું ફેરવી શકાય તેવા બાઇન્ડિંગ ફેરફારમાં બદલે છે. નીચેનું બધું તે જ એક વાક્ય પર આધારિત છે.

પ્રમાણપત્ર પહેલાં પ્રોટોકોલનું નામ આપો

SSTP શ્રોતા HTTPS જેવું વર્તન કરતા ક્લાયન્ટને TLS પ્રમાણપત્ર રજૂ કરે છે. આવતું સાઇટ-થી-સાઇટ IKEv2 કનેક્શન સર્વરની ઓળખ જાહેર કરે છે અને સાથીઓના પ્રમાણપત્રો વિશ્વસનીય મૂળ સામે ચકાસે છે. પ્રતિ ઇન્ટરફેસ સાઇટ-થી-સાઇટ વ્યાખ્યા પોતાની અલગ મશીન ઓળખ ધરાવે છે.

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

SSTP એ HTTPS બાઇન્ડિંગ છે

સમર્થિત Remote Access જમાવટોમાં Set-RemoteAccess તે SslCertificate પરિમાણ આપે છે જે SSTP કનેક્ટિવિટી અને HTTPS સંબંધિત DirectAccess ભૂમિકા માટે વપરાય છે.

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

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

આવતા IKEv2નું પોતાનું પરિમાણ છે

Set-VpnAuthProtocol આવતી સાઇટ-થી-સાઇટ IKEv2 પ્રમાણીકરણ રૂપરેખાંકિત કરે છે, અને CertificateAdvertised જ્યારે ટનલ પ્રમાણીકરણ મોડ તેનો ઉપયોગ કરે ત્યારે પ્રમાણપત્ર પૂરું પાડે છે. હોસ્ટ પર કોઈપણ સર્વર પ્રમાણપત્ર પસંદ કરવાનો આ સામાન્ય આદેશ નથી.

બે વસ્તુઓ અલગ રાખો: સર્વર પોતાની ઓળખ તરીકે રજૂ કરે તે પાન, અને સાથીઓના પ્રમાણપત્રો સ્વીકારવા માટે વાપરે તે મૂળ. કયા ઇશ્યુઅર પર ભરોસો કરવો તે પસંદ કરવાથી સર્વર કયું પાન રજૂ કરે છે તે વિશે કંઈ કહેતું નથી.

અલગ સાઇટ-થી-સાઇટ ઇન્ટરફેસની ઓળખ Set-VpnS2SInterface દ્વારા સેટ થાય છે. બંને એક જ મશીન પર એક જ સ્ટોરમાં હોય તો પણ તે આપોઆપ SSTP પ્રમાણપત્ર નથી.

પહેલાં ઉમેદવાર તપાસો

સ્થાનિક મશીનના સ્ટોરનું કેન્દ્રિત દૃશ્ય કંઈ ખાનગી નિકાસ કર્યા વિના જાહેર મેટાડેટા દર્શાવે છે:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

તે યાદી પ્રારંભ બિંદુ છે, યોગ્યતા કસોટી નથી. તમે જે પ્રોટોકોલ ગોઠવી રહ્યા છો તે માટે SAN નોંધ, વિસ્તૃત કી વપરાશ, શૃંખલા અને સેવા ખાતાની ખાનગી કી સુધીની પહોંચ તપાસો.

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

વર્તમાન બાઇન્ડિંગ નોંધો અને બદલતા પહેલાં ખાતરી કરો કે તમે હજી પણ હોસ્ટ સુધી બીજી રીતે પહોંચી શકો છો. પુનઃપ્રાપ્તિનો માર્ગ ફેરફારનો ભાગ છે, તેના પછી આવતી ઘટનાનો નહીં.

નવીકરણ સક્રિયકરણ નથી

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

સમર્થિત ફેરફાર યોગ્ય વિન્ડોમાં લાગુ કરો, જેમાં કોઈપણ દસ્તાવેજીકૃત પુનઃશરૂઆત સમાવિષ્ટ છે, પછી પ્રમાણપત્ર ઇચ્છિત પ્રોટોકોલના નવા કનેક્શનથી તપાસો. કેશ કરેલું ક્લાયન્ટ સત્ર હજી પણ જૂનું પાન દર્શાવી શકે છે અને સાચો ફેરફાર તૂટેલો દેખાડી શકે છે.

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

સંબંધિત લેખો